SPF, DKIM and DMARC: three locks on one door

Why this is needed

Email was designed at a time when the participants knew each other. There is therefore no check at all on who sends a message. The sender line is simply a field in the message, and you fill that field in yourself — much as you can write whatever you like on an envelope.

What follows from that is the fraud we see most often in practice, and it is not the stray phishing mail full of spelling mistakes. It is the tidy note from a supplier saying the bank details have changed. Or the mail from the director to the finance team, short and with some urgency in it, about a payment that has to go out today.

Both work because the recipient has no reason to doubt: there is a familiar address at the top. And both can be prevented at the receiving server, provided you have recorded who is allowed to send on behalf of your domain.

There is another reason to do this that has nothing to do with security: arriving at all. The large mail providers began requiring these records in 2024 from parties who send in volume. A domain without DMARC lands in the junk folder more often, and you notice that in your invoices and your newsletter long before you notice it in an incident.

SPF: who may send on your behalf

SPF is a list. In your DNS you put one line stating which servers are allowed to send mail with your domain as the sender. The receiving server looks at where the message came from, reads your list, and establishes whether that matches.

It sounds simpler than it is, because that list is almost never just your own mail server. There is an accounting package that sends invoices, a newsletter service, a recruitment system, a ticketing system that sends confirmations, and sometimes an old server nobody recognises. Every party that mails on your behalf has to be in it.

Two things go wrong here as a matter of course:

• The ten-lookup limit. An SPF record may cost at most ten DNS lookups. Every service you add counts towards it, and an organisation with a handful of suppliers goes over it easily. Once you are over, the answer is not "invalid" but "failed" — and that can hit your own mail.
• The tail of the record. If it ends in ~all, your domain says "the rest is suspicious, but deliver it anyway". If it ends in -all, it says "the rest is not ours". The latter is the intent, and it is also what creates the risk when your list is incomplete.

Where SPF breaks regardless is forwarding. If someone forwards your mail to another address, their server sends it, and that server is not on your list. That is not a fault you can fix; it is the reason SPF alone is not enough.

DKIM: a signature that survives forwarding

DKIM solves exactly that. Instead of looking at where a message came from, you put a signature on it. Your mail server signs outgoing messages with a private key; the matching public key sits in your DNS. The recipient fetches it and checks whether the signature matches the content.

The advantage is that the signature is attached to the message rather than to the server. Forward the mail and the signature travels with it and still checks out. Alter the content in transit and it no longer does — which is precisely what you want to know.

What to keep an eye on here:

• Every sending party signs separately. Your newsletter service has its own key under its own selector. A single DKIM record covering everything does not exist.
• Key length. Some older setups are still on 1024 bits. New keys go to 2048.
• Replacement is part of it. A key that has been sitting there for ten years is a key nobody manages any more. That is the same reasoning as under key management.

SPF and DKIM together cover nearly every case. What neither of them does is say what should happen when it goes wrong. They hand down a verdict and leave the recipient to guess.

DMARC: the record that actually does something

DMARC is the layer on top, and it is the only one of the three from which a receiving server takes an instruction. It says two things: what you want done with mail that fails SPF or DKIM, and where the reporting should go.

There are three settings, and they belong in this order:

• Monitor. Do nothing, but send me a daily overview of who has been sending on behalf of my domain. This is where you start and it cannot do harm.
• Quarantine. What fails goes to the junk folder. The mail still arrives, just not in the inbox.
• Reject. What fails is refused and arrives nowhere. This is the goal, and it is also the setting in which a forgotten supplier becomes visible by its mail disappearing.

There is one subtlety here that is often missed. DMARC checks not only whether SPF or DKIM passes, but also whether the domain that passes is the same as the domain the reader sees. A newsletter service that sends and signs with its own domain passes SPF and DKIM and still fails DMARC. That is why such services have to be set to send from your domain — nearly every supplier has a setting for it.

The daily reports you get back are XML and not readable by hand. There are services that turn them into a legible overview, and that is worth the money: without those reports you take the final step blind.

The order in which you switch it on

Most write-ups on this are about the records. The real work is in the weeks in between, and that is also where it goes wrong when someone wants to finish it in one afternoon.

This is how we do it:

• Week one: inventory and monitor. Put SPF and DKIM in place for the parties you know about, DMARC on monitoring. Nothing changes about delivery yet.
• Weeks two to four: read the reports. This is where the list surfaces of what else is sending on your behalf. It is always more than anyone thought: an old webshop, the time-registration package, a marketing service from a campaign two years ago.
• Week four: clean up and connect. What you want to keep gets connected properly to your domain. What nobody recognises gets switched off — usually about half of it.
• Week five: quarantine. Move to the middle setting and keep reading the reports. Whatever you missed announces itself now, in the form of a colleague saying their confirmation mails are in spam.
• Only then: reject. If nothing new has appeared in the reports for two weeks, this is a non-event. Do it earlier and it is not.

Reckon on six to eight weeks from start to finish, most of which is waiting and reading. That is not slow; it is what separates a domain that is closed from a domain whose invoices no longer arrive.

And set a reminder afterwards. Every new service that starts mailing on your behalf — a new HR system, a different newsletter provider — has to be added, and the day someone forgets is the day their mail does not arrive.