Understanding DMARC
What DMARC does, how SPF and DKIM fit in, and why alignment matters.
Three checks, three different jobs
Email has more than one place to put a sender’s identity. The address a person sees in their inbox is not necessarily the domain checked by the receiving mail server. That is why an authentication result can look healthy while a message still fails DMARC.
SPF lets a domain publish which servers may send mail using that domain in the SMTP envelope. DKIM adds a cryptographic signature that a receiver checks against a public key in DNS. DMARC connects a successful authentication result to the domain in the visible From address. This connection is called alignment.
What a DMARC pass means
A message passes DMARC when at least one of these paths succeeds:
- SPF passes and its authenticated domain aligns with the visible From domain.
- A DKIM signature passes and its signing domain aligns with the visible From domain.
Both paths do not have to pass for DMARC itself to pass. However, mailbox providers can require senders to configure both SPF and DKIM, and doing so gives legitimate messages more opportunities to authenticate.
For a typical domain such as example.com, relaxed alignment can allow a subdomain such as mail.example.com to align with example.com. Strict alignment requires an exact domain match. Organisational-domain discovery has more detail than this example; consult the current specification for edge cases.
A policy describes a preference
A DMARC record is published in DNS, typically at _dmarc.example.com. Its policy requests how a receiver should handle messages that fail DMARC:
| Policy | Requested treatment of DMARC failures |
|---|---|
p=none |
Take no special delivery action because of the DMARC failure. Useful for gathering visibility. |
p=quarantine |
Treat failures as suspicious, such as placing them in spam. |
p=reject |
Reject messages that fail DMARC. |
Receivers can apply their own local policies. A published reject policy is therefore not a guarantee about every receiver’s behaviour.
Reports turn policy into visibility
The optional rua setting requests aggregate reports. These summarise observations from participating receivers, including sending IPs, message counts, and authentication results. They help you investigate legitimate services that need fixing and unauthorised use of your domain.
Reports are not a complete list of every message sent. Not every receiver reports, and delivery, timing, and coverage vary. Failure reports are a separate mechanism and can contain more sensitive information.
What DMARC cannot promise
DMARC does not encrypt email, guarantee inbox placement, or prevent all phishing. An attacker can still use a lookalike domain or a misleading display name. It also cannot make a compromised, correctly authenticated sender trustworthy.
Treat it as one part of your email security controls. Start by understanding your legitimate sending services, then use reports and real-message tests to guide policy changes.
Ready to put it into practice? Follow the deployment checklist, or browse tools for checking your setup.
Sources
Sources reviewed .