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 instructs receivers to take no action on failing mail. Every message is delivered, and the only output is the reports you asked for. 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 instructs receivers to treat failing messages as suspicious. In practice most large receivers implement this as delivery to a spam folder rather than a refusal, which means the failure is recoverable but the mail is effectively lost for practical purposes.
p=reject instructs receivers to refuse failing messages outright. This is the state that actually prevents spoofing, and it is also the state in which a configuration mistake causes silent, permanent loss of legitimate mail.
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. Mail has somewhere to go — a route exists and a host is reachable, which the MX record check shows. 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. Reporting is on, because a policy that has never been reported on has never been evaluated.
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 refuses messages that fail authentication; 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.