SPF, DKIM and DMARC, explained without the DNS

The problem all three exist to solve

Email was designed in an era of mutual trust and it shows. The From address a recipient sees is simply a line of text the sender writes, and nothing in the original protocol checks it. Putting [email protected] in that field requires no access to your systems, no password, and no particular skill.

SPF, DKIM and DMARC are the retrofit. They let you publish, in DNS, a statement about who is allowed to send as your domain and what receiving servers should do about messages that fail the test. They are free, they are entirely within your control, and a surprising number of Australian businesses have all three configured in a way that does nothing.

SPF: which servers may send

A Sender Policy Framework record is a published list of the mail servers permitted to send on your domain's behalf. A receiving server compares the sending server against your list and forms an opinion.

Two things routinely go wrong. The first is the lookup limit: an SPF record may trigger no more than ten DNS lookups when evaluated, and each third-party service you add — the CRM, the accounting package, the marketing platform, the ticketing system — tends to add one or more. Exceed ten and the record does not merely lose the extra entries; it fails to evaluate, and can take your legitimate mail down with it. Organisations discover this by adding one more vendor and wondering why invoices stopped arriving.

The second is the ending. A record finishing in ~all (soft fail) says "treat anything else as suspicious", while -all (hard fail) says "reject anything else". Plenty of records end in ?all, which explicitly expresses no opinion and is functionally the same as having no record at all, while looking like a completed task on a checklist.

SPF also breaks on forwarding. When a message is forwarded, the forwarding server is not on your list, so the check fails through no fault of anyone. Which is why the second mechanism exists.

DKIM: a signature that survives the trip

DomainKeys Identified Mail signs outbound messages cryptographically. Your mail platform holds a private key; the matching public key is published in your DNS. A receiving server verifies the signature and knows two things: the message really did originate from a system holding your key, and the signed parts have not been altered in transit.

Because the signature travels with the message rather than depending on the connecting server, DKIM generally survives forwarding where SPF does not. This is why the two are complementary rather than alternatives, and why "we have SPF" is only ever half an answer.

The common failure here is quiet: DKIM enabled for the primary domain but not for the third-party services sending on your behalf, or keys generated once and never rotated. Both leave you signed in theory and unsigned in the cases that matter.

DMARC: the one that actually does something

SPF and DKIM produce results. On their own they do not tell a receiving server what to do with a failure — and by default, receiving servers mostly deliver anyway. DMARC is the record that turns those results into an instruction, and it is the reason the other two are worth configuring.

A DMARC policy has three possible settings:

• p=none — monitor only. Failures are delivered as normal, but you receive reports. This is the correct starting point and the wrong finishing point.
• p=quarantine — failures go to junk. A real control, with a safety net.
• p=reject — failures are refused outright. This is the setting that actually stops someone spoofing your domain.

A domain sitting at p=none has monitoring, not protection. It is a genuinely useful stage, and it is where the overwhelming majority of Australian small and mid-sized businesses have been parked for several years.

Alignment, the bit that catches everyone

Here is the concept that explains most "but we set it all up and it still fails" tickets.

DMARC does not simply ask whether SPF or DKIM passed. It asks whether they passed for the domain the recipient can see. A message can pass SPF perfectly for a marketing platform's own sending domain while displaying your company in the From field — SPF passes, alignment fails, DMARC fails.

That is the whole trick, and it is what makes DMARC meaningful rather than decorative. It also means every third-party service that sends as you needs to be configured for alignment, usually by setting up a custom sending subdomain and DKIM signing with your domain. Which brings us to why this stalls.

Why organisations stall at p=none for years

Nobody stalls because the DNS is hard. They stall because moving to enforcement means finding every system that sends email as the company, and no one has that list.

The realistic inventory is longer than anyone expects: the mail platform, the accounting package sending invoices, the CRM, the marketing platform, the e-signature tool, the recruitment system, the booking system, the survey tool, the payroll notifications, the monitoring alerts from a device in the comms room, and something a department signed up for with a credit card in 2023. Every one of them has to be aligned before enforcement, or its mail stops.

The fear is legitimate — turning on p=reject with an incomplete inventory means legitimate invoices silently vanish. The answer is not to stay at monitoring indefinitely. It is to use the reports, which is the step nearly everyone skips.

Getting to enforcement without losing invoices

• Publish p=none with a reporting address and point it at a service that parses the reports. Raw DMARC reports are XML and nobody reads them by hand; the parsing tools are inexpensive and turn the exercise into a readable list of who is sending as you.
• Watch for a full business cycle. Monthly invoicing, quarterly statements and the annual survey all need to appear in the data before you act on it.
• Align each legitimate sender one at a time — custom sending domain, DKIM signing with your domain, SPF entry if it fits within the lookup budget.
• Move to p=quarantine on a percentage first. DMARC supports applying the policy to a fraction of mail, so you can enforce against a slice and watch what breaks before committing.
• Then p=reject, and keep reading the reports afterwards. New systems get bought, and each one is a new sender.
• Do not forget domains you never send from. Parked and legacy domains should be locked down explicitly — they are attractive precisely because nobody is watching them.

What it does not stop

Getting to p=reject is worth doing and it is not a solution to email fraud. It stops one specific attack: someone sending mail that claims to come from your exact domain. It does nothing about the two techniques that actually empty the account.

A lookalike domain — yourcompany-au.com, or a Unicode character that renders almost identically — is a different domain, passes its own authentication perfectly, and looks right to a person reading quickly. And an attacker who has compromised a real mailbox is sending genuinely authenticated mail from the real domain; every check passes because nothing is being forged.

Which is the point worth ending on. Email authentication protects your domain's reputation and stops your customers being phished in your name. Stopping fraud against you still depends on strong authentication on the mailbox and a payment verification process that does not rely on email.

Questions