A familiar company name in an email’s From line is not proof that the company sent it. Domain-based Message Authentication, Reporting, and Conformance, or DMARC, gives mail systems a way to test whether a message is authorized to use the domain in that visible address. It combines two older mechanisms, SPF and DKIM, with a check called alignment.
That can make direct impersonation of a domain much harder. It cannot tell you whether an authenticated message is honest, whether an account has been compromised, or whether a similar-looking domain belongs to the organization you think it does. Understanding that boundary is especially useful now that the IETF’s 2026 DMARC specification has replaced the older RFC 7489.
What SPF and DKIM actually authenticate
SPF lets a domain publish which sending systems are allowed to send mail using a particular SMTP envelope identity. That identity, called MAIL FROM, is not necessarily the address a reader sees in the From line. A successful SPF check for an unrelated domain therefore does not, by itself, prove the visible sender’s domain is authorized.
DKIM uses a cryptographic signature attached to the message. The receiving system can check that signature against a public key published in DNS. A valid signature links the message to the signing domain, but that domain can also differ from the one displayed to the recipient.
The IETF DMARC standard joins these pieces to the visible From domain. It does not authenticate the person named before the address, the mailbox’s local part, or the contents of the message. This is a domain-level control, not a universal identity certificate.
Alignment is the missing link
Suppose a message visibly says it comes from news.example.com. An SPF pass for an unrelated mailing service’s own domain would not satisfy DMARC just because that service is legitimately allowed to use its own servers. The authenticated domain must also align with the visible From domain. The same idea applies to DKIM’s signing domain.
DMARC can pass when either SPF or DKIM both passes authentication and aligns with the From domain. It does not require both paths to pass every time. Under relaxed alignment, related subdomains can share the same organizational domain; strict alignment demands an exact domain match. Domain owners can specify which alignment mode they want.
That distinction explains a common troubleshooting puzzle: a message may show a valid SPF result and still fail DMARC because the SPF-authenticated domain belongs to the service provider rather than to the sender’s visible domain. The relevant comparison is between authenticated identities and the domain in the From address, not between the display names a user sees.
Policies express a preference, not absolute control
A domain owner publishes DMARC information as a DNS TXT record at a name beginning with _dmarc. Its policy can request no special handling of failures (p=none), suspicious treatment such as quarantine (p=quarantine), or rejection (p=reject). The difference matters: p=none is useful for observing mail streams, but it is not an instruction to block spoofs.
The receiver still makes the final delivery decision. The new IETF standard says a DMARC pass is not a safety verdict, and even a published reject policy must be weighed with other information by a receiving system. Legitimate mail can fail authentication in some indirect delivery paths. Conversely, a malicious message from an authenticated account can pass.
There is another DNS distinction worth keeping clear. Publishing a DMARC TXT record does not make the entire connection secure. Our DNSSEC explainer describes a separate mechanism for authenticating DNS data and its own limits.
Reports turn a policy into an operational process
Domain owners can request aggregate feedback reports about messages claiming to use their domain. The reporting format is defined in RFC 9990. Those reports summarize observed sending sources, authentication outcomes and receiver handling, helping owners find legitimate systems that have been forgotten as well as apparent abuse.
Reports are not an infallible census. Participating receivers are not obliged to send every requested report, and the resulting data may require interpretation. A familiar third-party sender can fail alignment because of configuration, while an unfamiliar source may need investigation before anyone labels it malicious. The reporting specification also discusses privacy implications when an outside service processes this metadata.
A careful rollout inventories ordinary mail, newsletters, account notifications and services that send on the organization’s behalf. It starts by monitoring and fixing legitimate failures, then evaluates whether quarantine or reject is appropriate. The IETF specification calls for a long observation period before reject for domains whose users may post to mailing lists; Google’s rollout guide likewise recommends reviewing reports and moving gradually from monitoring to enforcement. The right duration depends on actual mail flows, not a universal countdown.
Forwarding and mailing lists complicate the picture
Mail that is forwarded can arrive from a server that the original sender did not authorize in SPF. A DKIM signature may still survive if the message is not changed, but a mailing list that edits the body or headers can invalidate it. This is why a sudden switch to p=reject can disrupt legitimate conversations even when direct mail appears healthy.
The 2026 specification’s interoperability discussion explicitly warns about forwarded mail, aliases and mailing lists. It advises domain owners not to rely on SPF alone when considering reject. In practical terms, the sending setup and its indirect routes need testing; a neat DNS record is only one part of the job.
Major mail providers have their own sender rules as well. Gmail’s current sender guidelines require SPF or DKIM for all senders to Gmail accounts and SPF, DKIM and DMARC for senders above its bulk-sender threshold. These delivery requirements are not the same thing as a guarantee that every authenticated message will reach the inbox.
What DMARC leaves for other defenses
An attacker can register a visually similar domain and authenticate mail for that domain. They can also put a trusted organization’s name in the human-readable display-name field while using a different address. DMARC was designed to address unauthorized use of the exact From domain, not these lookalike or display-name attacks. It does not inspect links or attachments for harm.
Nor does a DMARC pass guarantee that the sender’s account was used with permission. The domain may have authorized its mail service perfectly while an account on that service is compromised. The meaningful lesson for readers is to treat authentication as evidence about domain use, then judge unusual requests through other channels. Passkeys and account recovery address another part of the identity problem, but they do not replace email-domain authentication.
What to watch next
RFC 9989 and its separate aggregate-reporting specification give operators an updated reference, but publication of a standard does not mean every mail system instantly changes behavior. Watch how receivers handle indirect mail, whether services make aligned signing easier, and whether reporting tools turn aggregate data into reliable operational decisions without obscuring its limits.
For everyday readers, the enduring distinction is simpler. DMARC helps answer whether a domain authorized its appearance in an email’s From address. It does not answer whether the message deserves your trust. This article explains standards and vendor guidance; it does not claim to have tested a particular mail provider or domain configuration.
Primary and authoritative sources
- IETF RFC 9989: DMARC protocol, 2026
- IETF RFC 9990: DMARC aggregate reporting
- Google: Email sender guidelines
- Google Workspace: Recommended DMARC rollout
Featured image is an AI-generated editorial metaphor, not a photograph of an actual email filtering device.
Leave a Reply