Guides · 2026-09-30 · By VSNARY | Emmanuel Orta · 0 views

DMARC p=none to p=quarantine without losing mail: a guide

The sequence for tightening DMARC safely: inventory every sender, prove alignment from received headers, create the report mailbox first, then raise the policy in stages.

A DMARC record with p=none is a monitoring instruction: it asks receiving mail servers to report what they see and to deliver everything anyway. Most domains that have a record at all stop there, because the next step, p=quarantine, is the one that can put your own legitimate mail into spam folders if anything is misconfigured. This guide is the sequence for making that move safely, written from doing it on crawlcheck.io in September 2026, where the domain had two separate sending systems that both had to pass before the policy could tighten.

What DMARC actually evaluates #

DMARC does not authenticate anything itself. It asks two questions of results that SPF and DKIM already produced, and one question about alignment. Did SPF pass, and is the domain SPF checked (the envelope sender) the same organisational domain as the visible From address? Did DKIM pass, and is the d= domain in the signature the same organisational domain as the From address? If either pair passes and aligns, DMARC passes. If neither does, the policy in the record applies: none delivers, quarantine asks the receiver to treat the message as suspicious, reject asks it to refuse. The single most common cause of legitimate mail failing under quarantine is a sender that passes SPF or DKIM on a domain that does not align: a marketing platform that signs with its own domain, or a form tool that uses its own envelope sender.

Step one: inventory every sender #

Before touching the policy, list every system that sends mail with your domain in the From address. Mailboxes are the obvious one. The rest hide: a transactional sender inside your web application, a form tool, a CRM, a support desk, a newsletter platform, a monitoring service that emails alerts, a billing provider. On crawlcheck.io there were two: the Google Workspace mailboxes, and the Cloudflare Worker that sends scan alerts, lead notifications and watch reports through Cloudflare's send-email binding. The two use different SPF includes and different DKIM selectors, and both had to align independently.

Step two: prove each one passes, from a received message #

The reliable proof is not the DNS record; it is the Authentication-Results header on a message each sender actually delivered. Send one message from each system to a mailbox you control, open the raw source, and read the line. It names three results and the domains they were evaluated against. For the Worker on crawlcheck.io the line read dkim=pass header.d=crawlcheck.io header.s=cf-bounce with SPF passing on the cf-bounce subdomain, which aligns at the organisational level, so dmarc=pass. For the Workspace mailboxes the same line initially showed SPF passing and no DKIM at all, because the Workspace DKIM key had never been generated. That is a pass today and a single point of failure: SPF breaks on any forwarding hop, and then there is nothing left to align.

Step three: give the reports somewhere to land #

A DMARC record names a rua= address for aggregate reports. Receivers send one XML report per day per receiver naming every source IP that sent as your domain and how each fared. This is the only view you have of senders you forgot in step one. The address has to exist. On crawlcheck.io the record pointed reports at dmarc@crawlcheck.io before that alias had been created on the Workspace user, which meant the reports were bouncing for the whole period they were most needed. Create the mailbox or alias first, send a test to it, and only then publish the record that names it.

Step four: move the policy in stages #

The record supports a percentage: pct=25 applies the policy to a quarter of failing messages. Publish p=quarantine; pct=25, read a week of aggregate reports, and look for any source you recognise landing in the failed column. Raise to 50, then 100. The subdomain policy sp= deserves its own decision; leaving it unset means subdomains inherit p, and a subdomain that sends mail through some other system will start failing when the parent tightens. The record crawlcheck.io settled on reads v=DMARC1; p=quarantine; sp=quarantine; pct=100 with the aggregate address, after both senders had aligned DKIM.

What quarantine will not fix #

DMARC governs the visible From domain only. A phishing message that uses a lookalike domain, or your brand name in the display name over a different address, passes DMARC because it is not claiming your domain. What tightening does is remove the exact-domain forgery, which is the one that most reliably defeats a reader, and it removes your domain from the pool of spoofable senders that receivers score against. The neighbouring pieces, an MTA-STS policy to stop transport downgrade and a TLS-RPT address to hear about it, are described on the trust center; the single-character bounce that started this work is in its own post.

Checklist #

One: list every sender. Two: read Authentication-Results on a real message from each, and get DKIM aligned on all of them, not just SPF. Three: create the report mailbox and confirm it receives. Four: publish p=quarantine at pct=25, read the reports, raise in steps. Five: set sp= deliberately. A scan on crawlcheck.io reads the SPF and DMARC records as published and reports what policy is in force; it cannot see your senders, which is why step two is done by hand.

Questions this post answers

What does p=none do?

It asks receivers to deliver everything and send reports. It is a monitoring setting, not a protection; forged mail using the exact domain is delivered normally under p=none.

What is DMARC alignment?

The domain that passed SPF or DKIM must match the organisational domain in the visible From address. A sender can pass SPF or DKIM on its own domain and still fail DMARC because nothing aligned.

Why does SPF alone fail when mail is forwarded?

A forwarding server re-sends the message from its own IP, which is not in your SPF record, so SPF fails at the final receiver. A DKIM signature survives forwarding because it is computed over the message content, which is why aligned DKIM is what makes quarantine safe.

Where do DMARC aggregate reports go?

To the address in the record's rua tag, one XML report per receiver per day. The address must exist before the record names it; reports sent to a non-existent mailbox bounce and are lost.

Should I go straight to p=reject?

Only after quarantine at pct=100 has run long enough for the reports to show no legitimate source failing. Reject refuses the message outright, so a sender you forgot loses mail rather than landing in spam.

Does DMARC stop lookalike-domain phishing?

No. It governs only mail claiming your exact domain. A lookalike domain or a display-name forgery over a different address is outside its scope.

Related findings

Comments

Comments are read before they appear. Nothing is published automatically, and no account is needed.

Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.

All guides · The dataset · How the dataset works