What DMARC Does: Alignment, Policies and Reports

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the piece that makes SPF and DKIM protect the address people actually see in the From line of an email. It lets a domain owner say "mail using my domain must authenticate in a way that lines up with that domain, and here is what to do with mail that does not," and it gives the owner reports on who is sending mail in their name. It is defined in RFC 7489.

The gap DMARC closes

SPF and DKIM each authenticate a domain, but not necessarily the one in the visible From header:

• SPF checks the envelope sender (the return-path address used for bounces). See What SPF does.
• DKIM verifies a cryptographic signature made by whichever domain appears in the signature's d= tag.

An attacker can send a message that passes SPF for their own bounce domain, or carries a valid DKIM signature from their own domain, while showing From: [email protected]. Neither check alone objects. DMARC adds the missing requirement: the authenticated domain must align with the From domain.

Alignment

A message passes DMARC if at least one of these is true:

• SPF passes and the envelope sender's domain aligns with the From domain; or
• DKIM passes and the signing domain (d=) aligns with the From domain.

Alignment comes in two modes, set separately for SPF (aspf) and DKIM (adkim):

• Relaxed (r, the default): the domains must share the same organizational domain. Mail from news.example.com with a DKIM signature from example.com aligns.
• Strict (s): the domains must match exactly.

Because DKIM signatures usually survive forwarding while SPF often does not, making sure every legitimate sender signs with an aligned DKIM key is the most reliable way to pass DMARC.

The DMARC record

DMARC is published as a TXT record at the _dmarc subdomain of the From domain:

_dmarc.example.com.   3600   IN   TXT   "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"

The main tags:

• v=DMARC1 – required, and must come first.
• p= – the policy for the domain: none, quarantine or reject. Required.
• sp= – an optional separate policy for subdomains.
• pct= – the percentage of failing mail the policy applies to, from 0 to 100. The default is 100.
• rua= – where to send aggregate reports.
• ruf= – where to send failure (forensic) reports.
• adkim= and aspf= – alignment modes, r or s.
• fo= – options controlling when failure reports are generated.

Policies

• p=none: monitor only. Receivers take no DMARC-based action, but send reports. This is the starting point.
• p=quarantine: treat failing mail as suspicious, typically by delivering it to spam or junk.
• p=reject: refuse failing mail during the SMTP conversation.

Receivers make the final decision and may apply their own local rules, but a published reject or quarantine policy is widely respected.

The pct tag

pct lets you apply a stricter policy to only part of your failing mail while you gain confidence. With p=quarantine; pct=25, roughly a quarter of failing messages are quarantined and the rest are handled as if the next less strict policy applied. It is a ramp, not a long-term setting.

Reports

Aggregate reports (rua)

Aggregate reports are XML files, usually sent daily by participating receivers, summarizing the mail they saw claiming to be from your domain: source IP addresses, message counts, and SPF, DKIM and DMARC results. They contain no message content. These reports are the main reason to deploy DMARC at p=none first, because they reveal every system sending as your domain, including ones you had forgotten about.

Raw XML is hard to read at volume, so most people feed reports into a parser or a reporting service.

Failure reports (ruf)

Failure reports describe individual failing messages and can include headers or content. Because of privacy concerns, many receivers do not send them at all, so do not rely on them.

Sending reports to another domain

If rua points to an address at a different domain, that domain must publish a record authorizing it, for example:

example.com._report._dmarc.example.net.   3600   IN   TXT   "v=DMARC1"

Without it, receivers should not send reports there.

Organizational domain fallback

A receiver first looks for a DMARC record at _dmarc under the exact From domain. If there is none, it looks at the organizational domain, usually the registrable domain as determined using the Public Suffix List. For mail from alerts.shop.example.com, a receiver would check _dmarc.alerts.shop.example.com and then fall back to _dmarc.example.com. When applying a policy found this way, the receiver uses sp= if it is present, otherwise p=.

This means a single record at your main domain protects all subdomains, including ones that do not exist. Setting sp=reject is a useful way to stop attackers from inventing subdomains to spoof.

DKIM selectors cannot be discovered

DKIM public keys live at selector._domainkey.example.com, where the selector is chosen by whoever set up the signing. The selector appears in the s= tag of each signature, so it is easy to find from a received message. It cannot, however, be reliably discovered from DNS alone: there is no index of selectors, and many DNS servers do not answer queries for _domainkey.example.com in a way that reveals the names beneath it.

In practice, a checker can test common selector names or ones you provide, but "no DKIM found" from a DNS-only check does not prove a domain lacks DKIM. The dependable method is to send yourself a message and read the DKIM-Signature header.

A sensible rollout path

1. Inventory your senders. List everything that sends mail as your domain: your mail platform, marketing tools, billing and support systems, website forms, printers and scanners.
2. Configure SPF and DKIM for each so that at least one aligned method passes. DKIM with your own domain in d= is the most robust choice.
3. Publish p=none with rua and collect reports for a few weeks, or longer for domains with irregular senders.
4. Fix what the reports show. Legitimate sources that fail need aligned DKIM or SPF, and sources you do not recognize need investigating.
5. Move to p=quarantine, optionally starting with a low pct and raising it in steps.
6. Move to p=reject once failures are consistently limited to mail you do not want.
7. Keep reading reports. New services get added and configurations drift.

For domains that never send email, you can skip straight to p=reject, alongside an SPF record of v=spf1 -all.

Check it yourself

• DMARC Checker finds your record, including any organizational-domain fallback, and explains each tag and common mistakes.
• SPF Checker validates the SPF side of alignment and counts DNS lookups.
• DKIM Checker looks up the public key for a selector you provide and checks that it is well formed.