SPF, DKIM and DMARC: Stopping People Sending Email as Your Domain

Business email compromise does not usually begin with a hacked mailbox. It begins with an email that merely looks like it came from your finance director, because nothing in your DNS told the receiving server to reject it.

Three records fix this. They are free, they take an afternoon, and they are still missing or misconfigured on a large share of domains.

SPF: which servers may send for you

SPF is a DNS record listing the servers permitted to send mail using your domain. The receiving server checks the connecting address against that list.

Two things trip people up. First, SPF has a hard limit of ten DNS lookups; exceed it and the record fails entirely, usually silently. Every SaaS tool that sends on your behalf adds to that count, so audit it when you add a new one.

Second, and more important: SPF validates the hidden envelope sender, not the From address the recipient sees. A message can pass SPF and still display any From address at all. SPF alone does not stop spoofing, which is the single most common misunderstanding in this area.

DKIM: a signature proving nothing was altered

DKIM adds a cryptographic signature to outgoing mail. The receiver fetches your public key from DNS and verifies it. If the body or signed headers were modified in transit, verification fails.

DKIM survives forwarding better than SPF does, which matters because mailing lists and forwarding rules routinely break SPF for legitimate mail. Use a 2048-bit key and rotate it periodically.

On its own, DKIM also does not stop spoofing: an attacker simply sends unsigned mail, and without a policy the receiver has no instruction to care.

DMARC: the part that actually enforces

DMARC ties the other two to the visible From address — this is called alignment — and tells receivers what to do when neither passes in alignment.

It has three policies: none (monitor only), quarantine (send to spam) and reject (refuse delivery). Only reject genuinely prevents spoofing of your domain. A domain sitting at p=none is collecting reports, not defending anything — which is a reasonable place to start and a bad place to stay.

The deployment order that does not break your email

The danger is not the records themselves, it is that almost every organisation sends legitimate mail from systems nobody remembers — the billing platform, the CRM, an old monitoring script on a server. Move straight to reject and that mail disappears without a bounce anyone sees.

1. Publish SPF and DKIM for every sending service you know about.
2. Publish DMARC at p=none with a reporting address. Change nothing else.
3. Read the reports for several weeks. They will name senders you had forgotten. Each one either gets added to SPF and DKIM, or switched off.
4. Move to quarantine, initially on a percentage of mail using the pct tag. Watch for complaints.
5. Move to reject once reports are clean. This is the step that stops the attack.

Do this for every domain you own, including ones you never send from — unused domains are attractive precisely because nobody is watching them. A parked domain needs an SPF record permitting nothing and DMARC at reject.

What this does not solve

DMARC protects your domain. It does nothing about a lookalike domain — the attacker registers a near-identical spelling, configures perfect authentication on it, and passes every check. Defending against that needs user awareness, external-sender banners, and monitoring for newly registered similar domains.

It also does nothing once a real mailbox is compromised, because that mail is genuinely yours and will authenticate perfectly.

Frequently asked questions