What is DMARC, and how do the policies work?

What does a DMARC record look like, and what do the tags mean?

RFC 7489 defines DMARC as a TXT record published at _dmarc.domain, using the same tag=value style as SPF and DKIM. The tags that matter most:

• v=DMARC1 - the version tag, required and must come first.
• p= - the requested policy for the domain itself: none, quarantine or reject.
• sp= - an optional separate policy for subdomains; without it, subdomains inherit p=.
• pct= - the percentage of failing messages the policy applies to, from 0 to 100 (default 100).
• rua= - one or more mailto: addresses that receive daily aggregate reports summarizing what passed and failed.
• adkim= / aspf= - alignment mode for DKIM and SPF respectively, r for relaxed (the default) or s for strict.

What do the three policies actually do?

p=none asks receivers to take no special action on a failing message; it still gets delivered normally, but the domain owner starts receiving reports about what is failing and why. p=quarantine asks receivers to treat a failing message as suspicious, most commonly by routing it to a spam or junk folder rather than rejecting it outright. p=reject asks receivers to refuse the message during the SMTP transaction itself, so it never reaches a mailbox at all.

None of these are commands a receiving server is forced to obey; DMARC is a request the domain owner publishes, and how strictly an individual mailbox provider honors it is up to that provider. In practice, the large mailbox providers do enforce published DMARC policies closely, which is exactly why getting the record right before tightening it matters. The safe path is to start at p=none with rua pointed at an address someone reads, confirm every legitimate sending source is passing alignment, then move to quarantine and finally reject - often with pct ramped up gradually rather than jumped to 100 in one step.

What is alignment, and why can a message pass SPF yet still fail DMARC?

DMARC does not just ask "did SPF pass" or "did DKIM pass" in isolation. It requires that the domain in the visible From: header - the address a person reads - align with the domain that SPF or DKIM authenticated. RFC 7489 defines two alignment modes: relaxed, where the organizational domain has to match (so news.example.com aligns with example.com), and strict, where the domains must match exactly.

This is why a message can pass SPF and still fail DMARC. SPF checks the envelope sender domain, the address used in the SMTP transaction, which is often a different domain than the one shown in the visible From: header - many marketing platforms and forwarders use their own domain as the envelope sender while displaying the customer's domain in From:. SPF itself passes cleanly for that platform's own domain, but DMARC's alignment check compares that passing domain against the From: domain, finds no match, and fails. The same logic applies to DKIM: a validly signed message from an unrelated third-party domain does not help DMARC unless the signing domain (d=) aligns with From: too. A message needs at least one of SPF or DKIM to both pass and align with the visible sender domain for DMARC to pass overall.

What are aggregate reports for?

The rua tag names where receivers should send aggregate reports, XML documents summarizing, over roughly a day at a time, which sending sources sent mail claiming to be from the domain, and whether each one passed or failed SPF, DKIM and alignment. These reports are the practical tool for finding every legitimate sending source before tightening a policy: a domain often discovers a forgotten transactional-email service or an old marketing platform still sending mail that would fail alignment, well before that mail starts getting rejected. The XML format is built for parsing by a report-reading tool rather than reading by eye, so most domains route these reports through software that turns them into a readable summary rather than opening the raw files directly.

What does pct do, and why use it?

The pct tag limits the requested policy to only that percentage of messages that fail DMARC, chosen at random; the remaining failing messages are treated as if the policy were none. A record with p=quarantine; pct=25 only asks for quarantine on roughly a quarter of failing mail. This exists specifically for a cautious rollout: instead of moving straight from monitoring to enforcing on every message, a domain can apply the stricter policy to a slice of failing traffic, watch the effect, and raise the percentage in steps until it reaches 100.

How does the subdomain policy work?

The sp tag sets a policy specifically for subdomains, separate from the main p tag. Without sp, every subdomain inherits whatever p says. This matters because subdomains are a common spoofing target precisely because many domains never configured mail on them at all - a policy of p=reject; sp=reject closes that gap by rejecting mail claiming to be from any subdomain, even ones that were never set up to send mail in the first place. The tag only sets one blanket rule for all subdomains together; it cannot set a different policy for each subdomain individually.

A complete example

v=DMARC1; p=quarantine; sp=reject; pct=50; rua=mailto:[email protected]; adkim=r; aspf=r

This record quarantines half of the failing mail claiming to be from the domain itself while it phases toward full enforcement, rejects all failing mail claiming to be from any subdomain, uses relaxed alignment for both SPF and DKIM, and sends daily aggregate reports to the address given.

DMARC only makes sense once SPF and DKIM are already in place: see what an SPF record is and what DKIM is for those two records, and how to check all three for the commands that confirm each one is actually working. The free MX lookup tool lists a domain's mail servers from HostTracker's own network of checkpoints, useful alongside a DMARC check when reviewing a domain's full mail setup.

Frequently asked questions

Do I need SPF and DKIM set up before adding a DMARC record?

The DMARC record itself does not require them to exist, but without at least one working and aligned, essentially all mail from the domain fails DMARC. Set up SPF and DKIM first, then add DMARC at p=none to observe the results before requesting any enforcement.

What happens to a message that fails under a quarantine policy?

DMARC only carries the request; the receiving mail system decides how to act on it. Quarantine most commonly means the message lands in a spam or junk folder rather than the inbox, but the exact handling is the receiver's choice.

Can different subdomains have different DMARC policies?

Not through the DMARC record alone. The sp tag sets one policy that applies to every subdomain collectively; there is no per-subdomain override within DMARC itself.

Why do some domains stay at p=none indefinitely?

Usually because nobody went back to review the aggregate reports and tighten the policy after the initial setup. A record left at none collects data forever but never actually blocks a spoofed message, which is a common and avoidable gap covered in the next guide.

Does DMARC stop phishing that does not use the protected domain's name at all?

No. DMARC only governs mail that claims to come from the exact domain (or its subdomains) that published the record. A look-alike domain, such as one with a swapped character, is a different domain entirely and is unaffected by another domain's DMARC policy.