Getting a domain to p=reject without losing mail

Look up the DMARC record of almost any company and you will find p=none, published two or three years ago by someone who had just read an article about it. That record does one thing: it asks receiving mail servers to send you reports. It does not stop anybody sending mail as you, and a great many people believe it does. The gap between publishing a DMARC record and being protected by one is where most domains have been sitting since 2019.

The reason nobody closes it is obvious once you have tried. The failure mode of tightening too early is that your own invoices, your own password resets and your own recruitment emails stop arriving, silently, and you find out from a customer. So the sequence below is built around one idea: never change the policy until a specific check has passed, and never make a change you cannot reverse in five minutes.

What you are actually doing

DMARC asks two questions about an incoming message claiming to be from your domain. Did SPF pass, and was the domain it passed for the same as the visible From domain. Did DKIM verify, and was the signing domain the same as the visible From domain. If either pair holds, the message is aligned and DMARC passes. If neither does, your policy decides what happens.

That word "aligned" is where the surprises live. A mail platform can pass SPF perfectly well on its own envelope domain and still fail DMARC for you, because the alignment is what is being tested, not the authentication.

Step one: collect before you touch anything

Publish a monitoring record with a reporting address and then leave it alone.

v=DMARC1; p=none; rua=mailto:reports@example.com; fo=1

Wait at least one full month. Not two weeks. A month, because payroll, month-end invoicing, the quarterly newsletter and the annual insurance renewal all go out on days that a fortnight will miss, and those are exactly the senders nobody remembers to tell you about.

While you wait, write down every system you believe sends mail as your domain. Finance software, the CRM, the helpdesk, the marketing tool, the recruitment platform, the office printer that scans to email. Then compare that list against the reports. The difference between the two lists is the actual scope of the project.

Check before moving on: you have a month of aggregate reports and every sending IP with meaningful volume has a name against it.

Step two: read the reports, and know which failures matter

Aggregate reports are XML, one per receiving provider per day, and they group messages by sending IP with pass and fail counts. Four shapes account for nearly all of it.

What you see	Usual cause	What to do
SPF passes, DKIM absent, DMARC fails	A platform sending on its own envelope domain	Turn on DKIM signing at that platform
SPF fails, DKIM passes, DMARC passes	Forwarding, mailing lists, alias chains	Nothing. This is DKIM doing its job
Both fail, IP you recognise	A sender nobody told you about	Authenticate it or stop it sending as you
Both fail, IP you do not recognise	Spoofing, or a tool abandoned years ago	Identify it, then let it keep failing

The last row is the point of the exercise. Those messages are the ones enforcement will stop.

One thing worth being paranoid about: reports arrive by email, and anyone can send an email. A forged report can make a dashboard say your mail is healthy when it is not. Our own ingest only accepts reports from an operator-reviewed list of exact sender addresses and DKIM signing identities, which means a new reporting provider has to be added by hand. That is a small permanent cost in exchange for numbers you are willing to act on.

Step three: fix DKIM before you fix SPF

If you only do one thing, do DKIM everywhere. DKIM is a signature over the message, so it survives forwarding. SPF is a check on the connecting IP, so it does not. A domain authenticated only by SPF will produce a steady trickle of failures from perfectly legitimate mail that happened to pass through a forwarder, and you will never be comfortable enforcing.

Check before moving on: every sender in your inventory signs with DKIM, using a selector under your domain, and the reports confirm it.

Step four: the ten lookup limit

SPF evaluation is allowed ten DNS lookups. Each include: costs at least one, and the providers you include have includes of their own. Any company with a CRM, a helpdesk, a marketing tool and two mail providers is close to the limit and often already over it, in which case SPF returns permerror and quietly stops working for everybody.

You cannot fix this by being careful once, because the count changes when a provider edits their own records with no notice to you. It has to be checked on a schedule. Flattening the record, resolving the includes down to IP ranges and republishing, keeps you inside the limit, but it means the record now goes stale unless something keeps republishing it.

Check before moving on: the record evaluates in under ten lookups today, and something is watching it that is not a person's memory.

Step five: quarantine a slice

Now tighten, in the smallest increment the protocol offers.

v=DMARC1; p=quarantine; pct=10; rua=mailto:reports@example.com; fo=1

Leave it for a week. Then 25, then 50, then 100, a week apart, reading the reports each time and watching your own support inbox for the phrase "did you get my email". The percentage tag is a blunt instrument and receiver support for it is uneven, so treat it as a way to reduce blast radius rather than a precise dial.

Check before moving on: two weeks at p=quarantine; pct=100 with no legitimate sender failing.

Step six: subdomains, then reject

Subdomains inherit the organisational policy unless you say otherwise, and they are usually where the forgotten mail lives. If you know nothing legitimate sends from a subdomain, enforce there first with sp=reject while the parent is still at quarantine. It is a free test of your own understanding.

v=DMARC1; p=quarantine; sp=reject; rua=mailto:reports@example.com
v=DMARC1; p=reject; sp=reject; rua=mailto:reports@example.com

What still breaks after p=reject

Mailing lists that rewrite the subject line or append a footer invalidate the DKIM signature. Well-behaved lists rewrite the From header to their own domain and the problem disappears. Badly behaved ones do not, and members of those lists will lose your messages.

Automatic forwarding from an old address to a new one usually survives on DKIM alone, which is the second reason step three matters.

And the policy can be undone by anybody with access to the DNS zone. The most common way a domain regresses is not an attack, it is a well-meaning change made during an unrelated migration. Whatever you use, make sure something notices when the record changes and tells a human. Keeping the records somewhere that a single CNAME delegates to, rather than in a zone that five teams edit, removes most of that risk by removing most of the opportunities.

The whole sequence takes about three months for a company with real mail flow. There is no honest way to make it two weeks, and the ones who try are the ones who end up back at p=none after an incident.

Further reading on the tooling behind this: DMARC Engine.