Getting to a DMARC reject policy without losing legitimate mail
An invoice arrives from your own domain, addressed to your own customer, with different bank details. Nobody was hacked. The attacker simply sent mail claiming to be you, and nothing on the internet stopped them — because the three records that would have stopped them are either absent, incomplete, or sitting in a mode that reports the problem and permits it anyway.
The short version
Three mechanisms, one policy, and a staged path. SPF says which servers may send for your domain. DKIM lets a receiver verify that a message was signed by your domain and has not been altered. DMARC ties both to the address a human actually sees and tells receivers what to do when neither lines up — and it sends you reports so you can find out before you enforce.
The staged path is: inventory every sender, publish records, start in monitoring mode, read the reports, fix the senders that fail, then move to quarantine and finally to reject. Skipping the middle is how organizations lose legitimate mail and then roll the whole thing back.
What each mechanism does
- SPF — RFC 7208. A DNS record authorizing the hosts allowed to use your domain name. The problem it addresses is stated plainly in the specification: existing protocols place no restriction on what a sending host can use as the envelope sender of a message or as the domain given in the SMTP greeting.
- DKIM — RFC 6376. A cryptographic signature that lets the owner of a signing domain claim some responsibility for a message by associating the domain with it. A receiver verifies the signature against a public key in your DNS.
- DMARC — RFC 9989. The policy layer. It requires that an authenticated identifier align with the author domain — the one in the From header — and it tells receivers your handling preference when that fails.
One note on references, because it trips people up. Most published DMARC guidance cites RFC 7489. That document was informational and is now obsolete: RFC 9989 replaces it on the standards track, with aggregate reporting split into RFC 9990 and failure reporting into RFC 9991. If a supplier’s documentation still points only at 7489, it has not been revised recently.
Why SPF alone does not stop spoofing
SPF alone does not stop spoofing of the address a human reads, because it validates the envelope sender and the server’s greeting rather than the From header shown in the mail client. A message can pass SPF perfectly — because the attacker’s own domain authorized their own server — while displaying your company’s address in the From line. The recipient sees your name. The check that passed was about a different field.
DMARC is what closes that. It requires alignment between the author domain and an authenticated identifier, so a message carrying your domain in the visible From has to be genuinely authorized by your domain. That is the whole reason the third record exists, and the reason a domain with SPF and DKIM but no DMARC policy is still spoofable.
Step one: inventory every sender
This is the step organizations skip, and skipping it is the single cause of broken mail later. Before publishing anything, list every system that sends as your domain.
The ones routinely forgotten: the marketing platform; the invoicing and accounting system; the applicant tracking or human resources system; the helpdesk; the appointment reminder service; the customer relationship platform; the monitoring and alerting stack; the application itself, sending password resets; the print or mail-merge supplier; and a server in a cupboard that has sent a nightly report since 2014.
Ask finance and marketing directly rather than inferring from technology. They know about systems the technology team has never heard of, and those are precisely the ones that will fail after enforcement.
Step two: publish and start in monitoring mode
Publish an SPF record naming the authorized senders. Enable DKIM signing on every platform that supports it, which by now is nearly all of them. Then publish a DMARC record with the policy set to take no action, and with an address to receive aggregate reports.
Monitoring mode is a defined state, not a half-measure: receivers apply the checks and report the outcome while delivering the mail as they otherwise would. Nothing can break at this stage, which is exactly why there is no reason to delay it.
Keep the SPF record lean. It is evaluated with a limited budget of DNS lookups, and an estate that has accumulated a decade of third-party include statements can exceed it — at which point the record fails for everybody, including you.
Step three: read the reports and fix what fails
Aggregate reports arrive as compressed XML, one per receiver per day, summarizing what was seen and how it authenticated. What you are looking for is a small number of sources that consistently fail and that you recognize — those are your own unconfigured senders. The long tail of unfamiliar sources failing occasionally is generally the spoofing you are trying to stop, and it needs no action beyond eventually being rejected.
A paid reporting tool is a convenience, not a requirement. Aggregate reports arrive as compressed XML and can be read without one, though anybody staging a large or unfamiliar estate will find a parser worth the trouble. Whichever route you take, the work is the same: for each recognized failing sender, either authorize it properly or stop it sending as your domain.
Alignment has two modes — relaxed, which is the default and permits a subdomain relationship, and strict, which requires an exact match. Relaxed is the right starting point. Moving to strict is a later hardening decision, not part of getting to enforcement.
Step four: quarantine, then reject
When the recognized senders pass consistently, move the policy to quarantine. Failing mail goes to junk rather than disappearing, which is recoverable, and a sender you missed announces itself as a complaint rather than as a lost invoice. Hold there long enough to cover a full business cycle, then move to reject.
Reject is the point of the exercise. Until the policy is at reject, a receiver honouring your preference is still delivering forged mail somewhere. The specification is explicit that enforcement means the policy for the organizational domain and every subdomain below it is not the take-no-action value — which brings us to the gap that leaves most estates half-done.
Subdomains: the gap that leaves enforcement half-done
A policy on your organizational domain does not by itself settle what happens to mail from its subdomains, and an attacker reads your DNS as carefully as you do. Two tags exist for this, and both are worth setting explicitly rather than relying on inheritance.
- The subdomain policy tag states the handling preference for mail using an existing subdomain of your organizational domain that does not pass validation.
- The non-existent subdomain tag does the same for subdomains that do not exist in your DNS at all — which is the category an attacker invents, because a subdomain nobody uses is a subdomain nobody has configured.
Set both. An organization at reject on its main domain and silent on non-existent subdomains has left the easiest door open, and it is the one business-email-compromise operators try.
Third-party senders and alignment
The recurring problem is a platform that sends on your behalf using its own envelope domain and signs with its own key. SPF passes, DKIM passes, and DMARC still fails, because neither authenticated identifier aligns with the domain in the From header.
The fix is a custom sending domain: a subdomain of yours, delegated to the platform, with DKIM keys published under it. Every serious platform supports this and documents it. A platform that does not is a platform you cannot bring to enforcement, and that is a procurement fact worth knowing before renewal rather than after.
Enforcement breaks marketing email only when a sending platform was never authorized properly, and monitoring mode exists precisely so you find that out before any message is rejected. That is the argument for doing the inventory and the monitoring stage properly, rather than the argument some suppliers make for not enforcing at all.
Where BIMI fits
Brand Indicators for Message Identification displays your logo beside authenticated mail in participating clients. It requires DMARC at enforcement as a precondition, which makes it a reasonable internal argument for finishing the work: the marketing benefit is visible in a way the security benefit never is. Treat it as a reward for enforcement, not a reason for it.
A short checklist
- Every sending system listed, with an owner.
- SPF published and within its lookup budget.
- DKIM signing enabled everywhere it is available, with a key rotation plan.
- DMARC published in monitoring mode with an aggregate report address.
- Reports read for a full business cycle; recognized senders fixed.
- Policy moved to quarantine, then to reject.
- Subdomain and non-existent-subdomain policies set explicitly.
- Parked and brand-protection domains given a reject policy and no sending authorization at all.
Plan on weeks rather than days: long enough to see a full billing cycle, a payroll run and a quarterly mailing, because the senders that surprise you are the ones that only fire occasionally. None of this stops a genuine account takeover, which is what multi-factor authentication is for — the way insurers read that question is in MFA and insurance, and the account side of the problem sits with identity and workplace security. Nor does it stop a convincing voice or video on a call, which is the subject of deepfake fraud controls. Email authentication closes one specific door, completely.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Will DMARC enforcement break our marketing email?
Enforcement breaks marketing email only when a sending platform was never authorized properly, and monitoring mode exists precisely so you find that out before any message is rejected.
How long does the staged path take?
Plan on weeks rather than days: long enough to see a full billing cycle, a payroll run and a quarterly mailing, because the senders that surprise you are the ones that only fire occasionally.
Do we need a paid DMARC reporting tool?
A paid reporting tool is a convenience, not a requirement. Aggregate reports arrive as compressed XML and can be read without one, though anybody staging a large or unfamiliar estate will find a parser worth the trouble.
Why is SPF on its own not enough?
SPF alone does not stop spoofing of the address a human reads, because it validates the envelope sender and the server’s greeting rather than the From header shown in the mail client.
Getting to enforcement
Send your domain and we will say what is published today and what the staged path looks like from there. The rest of what we do is under services, and our writing is indexed at writing. If the spoofing has already worked, start with incident response readiness.