SPF, DKIM and DMARC — reaching p=reject without losing mail

A domain without these three records is open: anyone can send a message signed with your address and stands a fair chance of reaching the inbox. No server break-in required, no password needed. A mail server of their own and a “from” field filled in with somebody else’s address is enough.

The configuration itself is three DNS entries. The difficulty is not in writing them but in the order you switch them on — and that is the only part worth reading carefully.

What each of the three does

SPF states which servers may send mail from your domain. A TXT record on the apex:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

DKIM is a cryptographic signature attached to every message by the sending server. The recipient checks it against a public key in DNS:

selector._domainkey.yourcompany.com   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBg..."

DMARC ties the two together and says what to do when a check fails. A TXT record at _dmarc.yourcompany.com:

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

The thing most guides leave out

“SPF passes” is not enough on its own. What counts is alignment.

SPF checks the domain in the message envelope (MAIL FROM), while the person reading their mail sees an entirely different field: the From header. These are two separate things and they can hold two different domains. DMARC requires that the domain a human sees matches the one that passed the check.

This is why a message sent through a service that substitutes its own envelope domain can have a perfectly valid SPF result and still fail DMARC. It is the most common source of confusion when the first reports arrive.

The practical conclusion: DKIM matters more than SPF. A DKIM signature survives forwarding; SPF does not, because after a forward the sending server is somebody else. If you have to perfect one of them before tightening the policy, make it DKIM.

The rollout, in four stages

The whole difficulty is that you do not know who sends mail on your company’s behalf. Not because anyone is hiding it — systems were simply added over the years and nobody kept a list.

Stage 1: listen, no consequences

Start with a policy that blocks nothing:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

p=none means “check and report, but reject nothing”. From that moment receiving servers start sending daily aggregate reports about who is sending mail from your domain.

Leave it for two to four weeks. Anything shorter will not do — monthly processes such as invoice or report runs will not show up within a week.

Stage 2: reading the reports

Reports arrive as XML inside a ZIP archive and are unreadable in raw form. There is no point opening them by hand — several free tools turn them into a table.

You are looking for the answer to one question: which sources send your mail and are they legitimate. In a small company the list usually turns out longer than anyone assumed:

• the company mail server — expected,
• the invoicing system sending documents to customers,
• the shop or the form on the website,
• a CRM or a quoting tool,
• monitoring sending alerts,
• the multifunction printer with scan-to-mail,
• somebody’s personal mail client configured two years ago on a trip.

Every legitimate source has to be brought into alignment — added to SPF or, better, given DKIM. Most serious services let you sign messages with your own domain; you only have to add a selector record.

Stage 3: partial tightening

Once reports have shown nothing but known sources for a week, move to quarantine — but not on everything at once:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

pct=25 applies the policy to a quarter of messages. If something was missed, you find out at a quarter of your traffic rather than all of it. Raise it in steps: 25 → 50 → 100.

Stage 4: rejection

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

From here a message impersonating your domain is rejected rather than filed in spam. That is the goal — but getting here realistically takes a month or two and cannot be shortened without risk.

The traps that cost most

Ten DNS lookups in SPF. The SPF record has a hard limit of ten DNS lookups and every include: counts together with whatever it contains. After the fourth or fifth service the limit can be crossed — and then SPF stops working entirely, quietly. Check the record with a tool that counts lookups rather than by eye.

-all versus ~all. Hard -all says “reject everything not on the list”, soft ~all says “mark as suspicious”. With DMARC properly configured, -all is the right choice. Before DMARC is ready, ~all is safer.

Mail forwarding. If somebody in the company forwards to a personal address, SPF will stop passing along the way. That is normal and not a fault — which is exactly why DKIM has to work before you switch on p=reject.

The reports mailbox. The address in rua= will receive dozens of messages a day. Create a separate mailbox or alias rather than using your main one — otherwise you stop looking after a week, and that is the only place where you can see whether the rollout is going well.

Subdomains. By default the policy covers subdomains. If some service sends from notifications.yourcompany.com, the same p=reject applies to it. You can separate them with the sp= parameter, but first you have to know such sending exists at all.

How long this really takes

Writing the three records: fifteen minutes. Reaching p=reject without losses: four to eight weeks, most of it spent waiting for reports.

If somebody offers to switch on p=reject the same day, then either the company has no mail-sending systems beyond a single server, or in two weeks somebody will notice that invoices stopped reaching customers.

Checking what you have now

dig TXT yourcompany.com +short          # SPF
dig TXT _dmarc.yourcompany.com +short   # DMARC

No answer to the second command means there is no DMARC and nobody is telling you about impersonation attempts. It is the most common starting state and at the same time the cheapest thing to fix — the first stage carries no risk at all, because it blocks nothing.