A general explanation checked against Google’s sender guidance and the DMARC standard on September 7, 2026. It does not diagnose a particular domain.
A message can reach spam, bounce, or fail to arrive for several reasons. Authentication is one place to look; sender reputation, unwanted mail reports, message content, and the receiving service’s rules also matter. Changing a subject line or adding a domain record without understanding the evidence can miss the actual problem.
Three checks that answer different questions
- SPF: is this server authorized?Sender Policy Framework checks whether the sending server is allowed to send for a domain used in the mail delivery process. That domain is not necessarily the one a reader sees in the From line.
- DKIM: does the signature verify?DomainKeys Identified Mail adds a digital signature. The receiver uses a public key to check the signature and the signed parts of the message. A valid signature links those parts to a signing domain; it does not establish that the message is safe or wanted.
- DMARC: does the domain line up?DMARC connects authentication to the domain in the visible From address. A message passes when at least one passing SPF or DKIM result uses a domain that aligns with it. Both do not have to pass for DMARC to pass, although providers may require both to be configured.
A DMARC policy also expresses how the domain owner would like failing messages handled and can request reports. The receiving service still makes its own filtering decision. A pass is not an inbox guarantee, and a failure does not automatically mean a message is fraudulent.
Begin with the evidence
- List the services that send messages for the business, including billing and marketing tools.
- Identify a specific missing message and its outcome: a bounce, a spam placement, or an unknown result.
- Review the message headers and authentication results with the person responsible for the domain.
- Compare the sending service’s setup instructions with the receiving provider’s current requirements.
This is an investigation checklist, not a ready-to-paste DNS recipe. The responsible administrator needs to understand legitimate senders and how a proposed change affects them. A policy that rejects messages deserves careful review before it is applied.
Ask for a finding you can understand
A useful explanation identifies the observed problem, the evidence for the cause, the proposed change, and how to verify it. “The records exist” answers less than “this message passed these checks, and here is what happened at the receiving service.”