Moving DMARC from p=none to p=reject without losing mail

Almost every marketing team we have spoken to this year now has a DMARC record. Very few of them have a policy stronger than p=none. The record went up in the first quarter, the mailbox providers stopped complaining, and the project closed.

The reason it stops there is rarely technical. A policy of none asks receivers to report and to do nothing else, so nothing can break. Move to quarantine or reject and something might break, and the something is usually unglamorous: the invoicing platform, the HR system, a warehouse notification script written by someone who left in 2016.

Nobody wants to be the person who blocked the invoices. So the record sits at none, the domain stays spoofable, and the daily reports arrive in a mailbox nobody opens. The way out is staged, it takes a few weeks of patience rather than a big-bang change, and it starts with reading those reports.

Read ninety days of aggregate reports before you touch anything

Your DMARC record carries a reporting address, the rua tag. Receivers send an XML summary there, usually once a day, describing every message they saw claiming to come from your domain. Point that address at a report parser rather than a human inbox. Reading raw XML by hand is a false economy.

Give it ninety days before you draw conclusions. Some systems send monthly, some quarterly, and a thirty-day window will miss them. That is exactly how teams discover a payroll notification the week after it stops being delivered.

What the reports give you, per sending IP: volume, whether SPF passed, whether DKIM passed, and whether either of them aligned with the domain in the From header. Sort by volume and work down.

Then split the list in two. On one side, legitimate senders you had forgotten about. On the other, everything else, most of which is background spoofing and forwarding noise rather than a targeted attack.

The rule we hold to: do not change the policy until you can name a human owner for every source above a small volume threshold. If a source is unexplained and sending real volume, it is not yet safe to reject.

Build the sender inventory from the finance system, not from memory

The reports tell you which IPs are sending. They do not tell you which internal team commissioned them. For that, ask finance for the list of SaaS subscriptions. It is usually the most complete inventory of senders anyone in the business holds.

Places we reliably find forgotten senders:

• The helpdesk or ticketing tool, which replies as your support address.
• Billing and invoicing, often a separate platform from the shop.
• Recruitment and HR systems sending offers and onboarding mail.
• Survey, NPS and review-request tools, frequently bought by a single team.
• Event and webinar platforms, with their own reminder sequences.
• Internal scripts on application servers, sending as a no-reply address.
• Agency partners sending on your behalf from their own infrastructure.

Every one of those needs an entry on a list with a named owner and a note on whether it can authenticate properly. That list, not the DNS record, is the actual deliverable of this project.

Fix alignment, not just authentication

A message can pass SPF and still fail DMARC. This trips up more teams than anything else in the process, so it is worth being precise.

SPF is evaluated against the return-path domain, which is the address bounces go to, not the address the recipient sees. Many platforms use their own bounce domain by default. SPF passes for that domain, the From header shows yours, the two do not align, and DMARC fails the check.

DKIM alignment works on the signing domain in the d tag. If the platform signs with its own domain, the signature is valid and still not aligned. The fix is to publish a key on your own domain and have the platform sign with it.

So the per-system work is usually two changes: set a custom return-path on a subdomain of yours, and set up DKIM signing with your own domain key. On mature platforms both are self-service. On cheaper tools they are a support ticket, and on some they are impossible.

Tools that cannot align need a decision. Either they move to a subdomain you deliberately leave at a looser policy, or they move off your domain entirely. Keeping them on the main domain means the main domain can never reach reject.

One more thing to watch while you edit records: SPF allows ten DNS lookups per evaluation, and each include statement consumes at least one. Chains of includes overflow that limit quietly, and the result is a permanent error rather than a pass.

Tighten in stages, starting with the domains you do not send from

Work in this order. Each step is smaller than it looks, and each one is reversible within a DNS TTL.

1. Parked and legacy domains first. Any domain you own and do not send from gets a policy of reject, an SPF record that authorises nothing, and no MX. There is no mail to break, so there is no risk, and you remove a favourite target for spoofing.
2. Subdomains individually. Publish a record on each sending subdomain and tighten them one at a time. A dedicated record on a subdomain overrides the organisational policy, so you can move the marketing stream without touching transactional mail.
3. Quarantine on the main domain, at a fraction. The pct tag applies the policy to a share of failing mail. Start low, watch the reports, then raise it in steps to 100.
4. Reject. By this point the reports should show nothing failing except forwarders and noise.

Hold each step for at least two weeks. The whole point of a staged rollout is to let a low-frequency sender appear before the policy hardens around it.

Expect a residual tail of failures you cannot eliminate. Forwarding breaks SPF because the forwarding server is not in your record. DKIM usually survives a plain forward but not a mailing list that rewrites the subject or appends a footer. ARC exists to help receivers reason about that chain, and it is applied by the receiver, not by you. Accept the tail rather than delaying reject for it.

What reject buys you, and what it leaves untouched

A policy of reject stops direct spoofing of your exact domain. That is genuinely valuable and it is also narrower than most people assume.

It does nothing about lookalike domains with a swapped character, and nothing about display-name spoofing, where the From address is a free webmail account and the display name is your brand. Those need brand monitoring and user training, not DNS.

It also does nothing for deliverability in the sense that most CRM teams care about. Authentication gets you considered. Engagement decides where you land. A disciplined suppression routine will do more for inbox placement than any record you can publish, and the two pieces of work are independent.

Where reject does pay off beyond security is as a prerequisite. BIMI requires a policy of quarantine or reject before a logo will display, so the DNS work has to come first regardless. The same applies to the ongoing obligations in the bulk sender requirements: authentication is the entry condition, not the finish line.

What to do this week

• Point your DMARC reporting address at a report parser and set a calendar reminder to review the output every Friday for the next three months.
• Ask finance for the SaaS subscription list and turn it into a sender inventory with a named owner per row.
• Publish a reject policy on every parked domain you own today, since none of them carry mail and none of them can break.