What the three policies mean in operational terms
DMARC has three policy states and they are not a difficulty ladder so much as a description of how much you know about your own sending. The monitor state says you are still finding out. The intermediate state says you are confident about most senders. The final state says you are confident about all of them.
p=none requests no DMARC enforcement for failing mail. Receivers still apply their own acceptance and spam rules; delivery and report receipt are not guaranteed. This is not a weak version of the policy; it is the measurement phase, and its whole value is the inventory of senders that the reports contain.
p=quarantine requests suspicious handling of DMARC failures. A spam-folder result is one possible receiver action; actual disposition and recovery depend on that receiver.
p=reject requests refusal of DMARC failures, subject to receiver handling. A configuration mistake can disrupt legitimate mail; inspect SMTP responses, sender logs and reports rather than assuming silent loss.
The reason the order is fixed is that a strict policy applied before the inventory is complete does not protect anything — it just breaks the senders you have not found yet.
Alignment is usually where rollouts break
Most understanding of DMARC stops at “SPF or DKIM must pass”. The requirement is stronger than that: the domain that passes must align with the domain in the From header, which is the address the recipient actually sees.
The distinction matters because of how sending platforms work. A mailing platform frequently sends on your behalf using its own domain in the envelope sender, so SPF passes for the platform’s domain rather than yours. The authentication succeeded, and DMARC still fails, because the visible From domain is yours and the authenticated domain is not. This is the single most common reason a rollout to a strict policy starts losing campaign mail.
Two comparison rules exist, relaxed and strict, for each of the two mechanisms. Relaxed alignment treats subdomains of the organisational domain as matching, and strict requires an exact match. The record can set each separately. Understanding which rule is in force is what determines whether mail from mail.example.com aligns with a policy published for example.com.
The practical remedy for a platform that cannot be configured to sign with your domain is to move that traffic to the platform’s own domain in the From header, rather than to weaken the policy for everything. Isolation by subdomain is the other approach: a separate policy for the sending subdomain lets you keep the organisational policy strict.
Reading aggregate reports without over-reading them
Aggregate reports arrive as XML attachments summarising one reporting period, grouped by the sending address and the evaluation result. They answer a narrow question: which addresses sent mail claiming to be your domain, and did they pass.
What they do not contain is whether the message was legitimate. A report showing failures from an address nobody in your organisation recognises is the normal signature of spoofing. A report showing failures from your own customer support system is a configuration gap. The two look the same in the data and are entirely different problems.
A practical approach is to sort by volume and work down. The addresses sending at scale are the ones whose failure will be noticed, and the long tail of low-volume senders can usually be triaged to a subdomain policy or accepted as unknown. Recording the decision for each source matters more than resolving it quickly, because the same address will appear again in the next period.
One further habit is worth building: check the report for sources you did not know existed, rather than only for sources that are failing. A platform sending on your behalf that happens to pass authentication is invisible in a list of failures, and it becomes visible the moment its configuration changes. The inventory is the deliverable of the monitoring phase; the policy is only the switch that follows it.
The checks to run before tightening
Before moving from monitoring to enforcement, each of the following should be true. Inspect receiving routes separately with the MX record check; DNS does not prove that a host is reachable and receiving MX is not a general prerequisite for sending authentication. The sending hosts are declared, which is what the SPF checker reads, and the record does not exceed the ten-lookup limit once includes are expanded. A signing key is published and reachable, checked by the DKIM checker. Confirm that requested reports actually arrive and that real message headers support the expected alignment; a rua tag alone does not verify either.
The combined view is what the email deliverability test produces, and it is the faster way to see which of the four is missing. For a domain whose mail is being refused before any of this matters, the IP blacklist check covers the possibility that the sending addresses are listed.
What a strict policy does not solve
It does not stop mail that passes. A strict policy requests handling of DMARC failures; it has nothing to say about a message that authenticates correctly and is unwanted. Spoofing inside a subdomain that inherits the policy is covered, and a sophisticated attacker using a lookalike domain entirely outside your control is not.
It does not improve placement. Passing DMARC removes a reason for suspicion and does not create a reason for trust. Where a message lands after authentication is decided by reputation and engagement, which is the subject of why legitimate email goes to spam.
It does not undo a damaged history, and it does not answer which individual observations a reputation provider has recorded — those are listed separately on the IP reputation check, with the source named for each one. What it does is remove an entire class of problem from the list, which is a smaller claim than it is often presented as and a more useful one.
Current protocol reference and a change record
Reviewed against RFC 9989 on 20 October 2026. The current standard removes historical pct, rf and ri tags. DMARC test mode t=y requests one level less strict handling; it is not a DKIM testing flag. Older implementations may differ, so a rollout needs observations rather than assumptions about uniform enforcement.
Before changing DNS, save the exact previous TXT value, its TTL, the sender inventory and the reason for the change. For a hypothetical support-platform rollout, test a normal reply, an automated ticket update and a forwarded example separately. A single successful personal message does not cover these workflows. Agree on who watches errors and how to restore the previous record. After the change, compare the same message types and reporting periods; no fixed waiting period proves that every legitimate sender has been found.