Guide · Email
DMARC: p=none, quarantine and reject
What each policy asks receivers to do, how to test a change without treating reject as an automatic destination, and which errors put legitimate mail at risk.
Short answer
What do p=none, quarantine and reject actually do?
p=none asks receiving servers not to change their handling because of DMARC. p=quarantine asks them to treat failures with suspicion, often as spam, and p=reject asks for rejection. These are preferences published by the domain owner; the receiver keeps the final decision.
A move to enforcement comes after you have validated every sending source in aggregate reports. p=reject is not an automatic destination: the current standard advises against it for general-purpose email domains whose users participate in mailing lists.
Three records, three jobs
They work together, and none is enough on its own.
SPF declares which servers may send for your domain. It is a list of authorized addresses, published in your DNS zone.
DKIM adds a cryptographic signature to each message. The receiving server checks it against a key published in your DNS. If the message was altered in transit, the signature no longer matches.
DMARC connects those checks to the domain visible in the “From” field, publishes a handling preference for failures and can request reports. The receiver uses that signal with its own rules.
Worth remembering
SPF and DKIM authenticate technical domains. DMARC checks their alignment with the visible domain, expresses a preference and organizes aggregate reporting.
Alignment, the part that surprises people
This is what makes apparently correct configurations fail.
DMARC is not satisfied by an SPF or DKIM that passes. It requires the validated domain to match the one the recipient sees in the “From” field. A newsletter service may well sign with its own domain: SPF passes, DKIM passes, and DMARC still fails because nothing matches your domain.
That is why configuration is verified with reports rather than with one successful test send.
Technical detail
Two modes exist, set by adkim and aspf: strict, where the domains must be identical, and relaxed, where a subdomain is enough. Relaxed is the default and suits the large majority of organizations.
Only one of the two mechanisms has to align for DMARC to pass. DKIM often holds up better than SPF through simple forwarding, as long as the intermediary does not change signed parts of the message.
p=none is not a protection
Many domains stop here and believe they are covered. They are not.
p=none asks receiving servers not to alter their handling because of DMARC. If the record includes a reporting address and a receiver participates in reporting, it can send aggregate reports. The policy itself blocks no spoofed message.
Its value is observation: aggregate reports can reveal legitimate and unauthorized sources using the domain, although they do not guarantee a complete inventory.
Worth remembering
Staying on p=none for years means you installed a meter and believed you installed a lock.
Moving up, one step at a time
Each step is taken when the reports allow it, not when the calendar says so.
-
Publish p=none with a reporting address
The rua tag requests aggregate reports at the named address. Without it, no aggregate report is requested; receivers are not required to participate.
-
Read reports across a representative cycle
They arrive as XML and are designed for machine processing. The period needs to cover rare senders as well as daily ones.
-
Fix each legitimate source
Get SPF or DKIM to align for every one. This is the real work, and it takes most of the time.
-
Move to quarantine
Once the reports show no legitimate failures. Suspicious messages go to spam rather than being refused.
-
Decide whether reject is actually appropriate
For a tightly bounded sending domain, reports may justify that preference. For a domain used by people and mailing lists,
p=rejectcan break legitimate flows and should not be the default choice.
Careful
Before any enforcement policy, verify that every legitimate source aligns and analyze indirect mail flows. Even with p=reject, a receiving server must not reject a message on that signal alone.
Current test mode: t=y
The current DMARC standard, RFC 9989, removed the pct tag because receivers applied it inconsistently. A new record should therefore not propose pct=25 or another percentage rollout.
The t=y tag now signals a test of the declared policy. With p=quarantine; t=y, the expectation is handling at the none level. With p=reject; t=y, the expectation is handling at the quarantine level. Requested reports continue.
Technical detail
t=y remains a preference sent to the receiver, like the p, sp and np policies. It does not replace reporting, validation of legitimate mail flows or an explicit decision to remove test mode.
The tag has no effect on p=none. Its default is t=n, which asks receivers to apply the declared policy.
Subdomains, often forgotten
Your DMARC policy covers the domain and, by default, its subdomains. The sp tag lets you apply a different policy to them.
That is useful in one specific case: you want the main domain on reject while leaving a sending subdomain on quarantine long enough to fix it.
It is also a trap: a subdomain left on sp=none for years becomes an open door for spoofing again, precisely because nobody looks at it.
Worth remembering
Subdomains that never send email should be locked down explicitly, not left without a policy.
The mistakes that cost the most
Five come up constantly.
To avoid
- Multiple SPF records the standard forbids a check from selecting more than one record; this configuration can produce a permanent error.
- Moving to enforcement with no reports risks losing legitimate mail before you have inventoried the affected sources.
- Publishing DMARC with no rua address the preference may be used, but no aggregate reports are requested to show you the affected flows.
- Forgetting third-party services invoicing, recruiting, booking, e-signature. They send in your name and nobody listed them.
- Presenting p=none as protection it is a monitoring posture and requests no special handling of failures.
If you are unsure about the state of your records, they are public: anyone can read them, including you. A doubt about how to interpret them clears up in minutes with someone who reads them every day.
Common questions
How long does it take to reach reject?
There is no universal timeline, and reject may not suit the domain. The standard says analysis can take many months. For a domain used by people who participate in mailing lists, it recommends against publishing p=reject.
Does DMARC stop phishing from reaching me?
No. DMARC protects your domain against being spoofed by others. It does not filter what arrives in your own mailbox, which is your email provider’s job.
Do I need DKIM if SPF is in place?
Yes. Forwarding usually breaks SPF alignment. A valid DKIM signature can survive simple forwarding when the message is not changed, providing a second path to a DMARC pass.
The reports are unreadable. What now?
They are XML, meant to be processed by a tool. Several services aggregate them into readable tables, including at low volume. Without that, the observation step delivers nothing.
Unsure about your configuration?
Write to us with your domain. We will read your public records with you and tell you what they actually do, with no commitment.
Write to us What you can check yourself