DMARC Policy: None, Quarantine, Reject and When to Switch

A DMARC policy is the p= tag in your domain's DMARC (Domain-based Message Authentication, Reporting and Conformance) record. It tells receiving servers what to do with email that uses your domain but fails authentication.

There are three values. none delivers failing mail as usual, quarantine sends it to spam and reject refuses it.

So p=none watches and blocks nothing. If an architecture practice in Lincoln sits at p=none, a fake invoice sent from its domain can still reach a client. You can tighten the DMARC policy safely once your reports show every real sender passing.

What none, quarantine and reject do

Each value asks receivers to handle failing mail in one way. Mail that passes DMARC is left alone by all three.

A message passes when SPF or DKIM passes for a domain matching the From address. Both need to work before any policy above none (SPF, DKIM and DMARC setup).

Policy	What you ask receivers to do	Gmail	Microsoft 365
p=none	Nothing: deliver failing mail and report on it	Delivers it and logs it in the daily report	No DMARC action; other filters still apply
p=quarantine	Treat failing mail as suspicious	Sends it to the spam folder	Junk Email folder
p=reject	Refuse failing mail	Rejects it, usually with a bounce	Rejected during delivery (550 5.7.1)

Gmail's column comes from Google's Set up DMARC page, updated 22 October 2026. Microsoft's assumes the recommended Honor DMARC record policy setting is on (Microsoft Learn, July 2026).

Receivers treat each DMARC policy as a request, and they have the last word. The Request for Comments (RFC) that now defines DMARC, RFC 9989 from May 2026, asks receivers to weigh other signals before rejecting.

Yahoo states its own side plainly. On a p=reject domain, mail with neither a proper DKIM signature nor SPF alignment is rejected (Yahoo Sender Hub).

What "DMARC policy not enabled" means

The warning means your record says p=none: receivers still deliver failing mail, which RFC 9989 calls monitoring mode when reports reach you.

MXToolbox, a popular checker, words it "DMARC Quarantine/Reject policy not enabled". The record works; it simply asks for no action.

A checker would flag mailgraf.com too. Its DMARC record, a TXT (text) entry at _dmarc.mailgraf.com, returned this on 25 October 2026:

$ dig +short TXT _dmarc.mailgraf.com
"v=DMARC1; p=none; rua=mailto:[email protected]"

It holds three tags: the version, a none policy and a rua address for aggregate reports. Every other tag takes its default, so alignment is relaxed and subdomains without their own record inherit none.

To read yours, run the same command in Terminal and swap our domain for yours. On Windows, use nslookup -type=TXT _dmarc.example.co.uk.

Is p=none enough for Gmail, Yahoo and Microsoft?

Yes. The bulk-sender rules of Google, Yahoo and Microsoft all accept p=none, as long as a record is published and your From domain aligns with SPF or DKIM.

Gmail says your DMARC "enforcement policy can be set to none" (Gmail sender guidelines). Yahoo asks for "at least p=none" and strongly recommends a rua tag (Yahoo Sender Hub).

Outlook.com has rejected non-compliant mail since 5 May 2025, with error 550 5.7.515, from domains sending over 5,000 messages a day (Microsoft).

What they penalise is a missing record. Gmail rate-limits bulk mail with code 4.7.31 when a domain has no DMARC record, or one without a policy (Gmail sender FAQ).

Logos are where none falls short. BIMI (Brand Indicators for Message Identification) shows your logo beside your emails, and its first requirement is quarantine or reject applied to all failing mail.

What each tag in a DMARC record means

A DMARC record is one TXT entry at _dmarc on your domain, made of tag=value pairs separated by semicolons.

v must come first. Always write p too: the standard reads a record without it as none, and Gmail treats it as having no policy.

Tag	What it says	If you leave it out
v=DMARC1	This is a DMARC record	The record is ignored
p	Policy for the domain: none, quarantine or reject	Treated as none
sp	Policy for subdomains that exist	Subdomains follow p
np	Policy for subdomains that do not exist (in the core standard since 2026)	Follows sp, then p
rua	Address for daily aggregate reports	No aggregate reports are sent
ruf	Address for reports on single failed messages	No failure reports are sent
fo	When to send failure reports	Only when SPF and DKIM both fail to align
adkim	DKIM alignment: r relaxed or s strict	Relaxed
aspf	SPF alignment: r relaxed or s strict	Relaxed
pct	Share of failing mail the policy covers (retired in 2026)	100
t	Test mode: y asks for one level below p (added in 2026)	n, the policy applies as written

Aggregate reports are XML (Extensible Markup Language) files that large receivers send daily or more often (RFC 9990). Google suggests a group, a dedicated mailbox or a report-processing service, not your own inbox.

A report address on another domain needs that domain's permission. It must publish a record such as example.co.uk._report._dmarc.reports.example.net.

Failure reports via ruf are rarer than the tag suggests. Gmail does not support it (Google), and Microsoft has no plans to send them from Outlook.com (Microsoft).

Relaxed alignment lets a subdomain stand in for your domain. A bounce address on your bounce subdomain aligns with mail from your main domain by default, but not under aspf=s.

Google suggests strict alignment mainly when someone else runs your subdomains.

Is pct still a safe way to phase in a DMARC policy?

No. pct=10 once asked receivers to apply the policy to a tenth of failing mail, and RFC 9989 moved it to historic in May 2026.

The RFC says receivers applied values other than 0 and 100 inaccurately. Current implementations are not expected to read it at all.

A receiver that ignores pct applies p=quarantine; pct=10 to all failing mail. Google's and Microsoft's help pages, both updated in 2026, still show pct steps, and Google's BIMI rules still ask for pct=100 or no pct at all.

So do not count on pct below 100; move a whole level at a time.

The replacement, t=y, asks for one level below your policy: reject is handled as quarantine, and quarantine as none.

Receivers built on the 2015 standard, RFC 7489, ignore tags they do not know. Until they update, t=y is no safety net.

How to move your DMARC policy from none to reject

Move up one level at a time, and only when the reports show every service that sends as your domain passing DMARC.

Google, the NCSC (the UK's National Cyber Security Centre) and RFC 9989 agree on that order. They disagree on how long each stage should take.

Source	At none	At quarantine	At reject
Google, 2026	At least a week	Start small, then cover all failing mail	Allowed in place of quarantine
NCSC, 2019	Reports for 2 weeks or more; many move on after 6 to 8 weeks	At least 4 weeks at 100%; reject after about 3 months	Watch reports closely for 2 weeks
RFC 9989, 2026, for domains whose users join mailing lists	At least a month	Just as long	Only if users accept mailing list problems

For a small business, the RFC timing is the safe one. Invoices, statements and renewal reminders often go out monthly, and a week of reports can miss them.

DKIM carries most of the weight because it survives forwarding. If a client forwards your invoice to a new address, SPF fails at the second hop while the DKIM signature usually holds.

RFC 9989 requires DKIM on every domain at reject for this reason.

These are the records for each stage, using a report mailbox you would create:

v=DMARC1; p=none; rua=mailto:[email protected]
v=DMARC1; p=quarantine; rua=mailto:[email protected]
v=DMARC1; p=reject; rua=mailto:[email protected]

If a real sender starts failing, step back one level, fix it and wait for clean reports again. The NCSC's reject stage advises the same.

Reject has one known cost. RFC 9989 says domains whose users post to internet mailing lists should not publish it.

List software has largely adapted by rewriting the From line, the RFC adds. Still, if your team uses work addresses on mailing lists, quarantine is a reasonable place to stop.

What UK councils and universities publish

Most of the UK public bodies we checked already enforce their DMARC policy, and none uses pct to soften it.

On 25 October 2026 we read the _dmarc TXT record on each body's main domain. The sample: the 32 London borough councils, the City of London Corporation and the 24 Russell Group universities.

Record	London councils (33)	Russell Group universities (24)
p=reject	28	9
p=quarantine	5	9
p=none	0	6
pct below 100	0	0
t tag	0	0
No rua address	0	2
rua still sending to NCSC Mail Check	28	6

For public bodies, a government email standard (March 2024) sets the direction: start at none, then rise to quarantine or reject.

Universities, whose staff and students post to mailing lists, are the case RFC 9989 warns about. A quarter of them remain at none.

The last row is a reason to reread your own record. The NCSC retired Mail Check on 31 March 2026, yet 34 of the 57 records still list its address, which that government standard still uses in its example. For 3 of them it is the only report address.

The address still exists in DNS, but the NCSC no longer passes findings to users. Make sure every rua address in your record still reaches someone who reads the reports.

For a free outside view, the same NCSC post recommends its Check your cyber security service, which tests a domain's email anti-spoofing.

DMARC on a MailGraf sending domain

The connection type you picked in Settings > Senders decides who writes the record behind your DMARC policy (Add a sending domain).

Connection	Who writes _dmarc	What it says	How to tighten it
Your root domain, such as example.co.uk	You, at your DNS provider	Whatever you publish; the help article suggests v=DMARC1; p=none if you have none	Follow the stages above
Your subdomain, such as news.example.co.uk	MailGraf, through the delegated nameservers	v=DMARC1; p=none; on our own news.mailgraf.com, 25 October 2026	Not from your DNS; send from your root domain instead
MailGraf domain, such as yourbrand.postgraf.net	MailGraf	Set by MailGraf	Not open to change

That subdomain record has no rua tag, so no reports are sent for it. Because receivers apply the record closest to the From address, it also overrides your root domain's p and sp values. If you want campaign mail at quarantine or reject, send it from your root domain.

Adding the root domain as a second sending domain may hit your account's limit, in which case MailGraf asks you to contact us to add more.

On the root domain option, the CNAME (alias) records you add point to the DKIM keys MailGraf signs with, and each signature names your own domain. That is the aligned pass DMARC looks for, at none and at reject alike.

Bounces normally return to the bounce subdomain set up by the MX (mail exchange) and TXT records (Return-Path). Whatever the Return-Path, the DKIM signature on your domain carries the DMARC pass.

The Review & send step shows whether a DMARC record was found on your sending domain (checks before you send).