DMARC Policies Explained

SPF and DKIM each check a different, narrower thing, and neither says anything about what a receiving server should actually do when a message fails. DMARC, short for Domain based Message Authentication, Reporting and Conformance, closes that gap. It ties the result of SPF and DKIM checks to the address a person actually sees in their inbox, and tells receiving servers exactly what to do with mail that does not line up: let it through, treat it as suspicious, or reject it outright.

v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=100

• v=DMARC1 marks this as a DMARC record and must come first.
• p sets the policy for the domain itself: none, quarantine or reject.
• sp, when present, sets a separate policy for subdomains, useful when a business wants a strict policy on its main domain while still figuring out subdomains individually.
• rua gives an address to receive daily aggregate reports summarizing pass and fail counts from mail claiming to be from this domain.
• pct limits the policy to a percentage of mail, letting a domain roll out enforcement gradually rather than all at once.

• none takes no enforcement action at all. Failing mail is delivered exactly as it would be without DMARC in place, but the domain still receives reports, making this the safe starting point for anyone rolling DMARC out for the first time.
• quarantine asks receiving mail servers to treat failing mail as suspicious, typically routing it to a spam or junk folder rather than the inbox.
• reject is the strictest setting and asks receiving servers to refuse failing mail outright, before it reaches a mailbox at all.

DMARC does not just check whether SPF or DKIM passed somewhere, it checks whether the domain that passed actually matches the domain in the visible from address, a concept called alignment. Strict alignment requires an exact match, while relaxed alignment allows a matching parent domain, so mail from news.example.com can still align with a policy published on example.com. This distinction rarely needs adjusting from its defaults, but it explains why a message can technically pass SPF against one domain while still failing DMARC because that domain does not align with the one shown to the recipient.

The rua address receives regular aggregate reports, typically daily, summarizing every source that sent mail claiming to be from the domain during that period, along with whether each one passed or failed SPF and DKIM alignment. These reports are how a domain owner discovers sending sources they did not know about, an old marketing tool nobody decommissioned, a shared mailbox forwarding through a third party service, before deciding whether each one is legitimate and needs to be added to SPF, or is actually a spoofing attempt worth blocking.

1. Publish a record with p=none first and start collecting reports, changing nothing about how mail is actually delivered.
2. Read the reports over a few weeks and identify every legitimate source currently failing alignment.
3. Fix SPF and DKIM for each legitimate source until reports show them passing consistently.
4. Move to p=quarantine, optionally starting at a lower pct value, and keep monitoring.
5. Only move to p=reject once reports show no legitimate mail is failing, since this setting has no room for a delivery failure caused by a missed sending source.