Email Security: SPF, DKIM & DMARC

The threat

How spoofing and invoice fraud work

Invoice fraud, often called business email compromise, usually takes one of three routes:

1. Exact-domain spoofing. The email shows your real address in the From line, even though it came from a criminal’s server. Email was designed with no check on this, so without DMARC the receiving system has to guess whether it’s genuine. This is the route DMARC closes.
2. Lookalike domains. The criminal registers a domain one letter away from yours, or with a different ending, and sends from that. DMARC on your domain can’t help, because it isn’t your domain. Filtering and careful reading do.
3. Compromised mailboxes. The criminal steals a password, gets into a real mailbox and sends from it. Those emails pass SPF, DKIM and DMARC, because they really are from you. Multi-factor authentication and passkeys are the defence.

The pattern is the same each time: a supplier invoice or a client payment is due, and an email arrives with “updated” bank details. The NCSC advises confirming payment requests through a second channel, such as a phone call to a number you already hold. That habit protects you whichever route the criminal takes.

Why it matters

It protects your clients

DMARC mainly protects the people you email. Without it, a criminal can send your clients an invoice that appears to come from your accounts address, and the first you hear of it is when they ask why the money hasn’t arrived. That’s why we pay particular attention to email for law firms and accountancy practices, where large payments follow predictable emails.

The big mailbox providers now expect it too. Gmail has required every sender to use SPF or DKIM since February 2024, and senders of more than 5,000 messages a day to Gmail addresses need SPF, DKIM and a DMARC record. Outlook.com brought in similar rules for high-volume senders in May 2025. Most small businesses never reach those volumes, and p=none is the minimum those rules ask for, not the goal.

The rollout

From p=none to p=reject, safely

Jumping straight to p=reject is the classic mistake: the first invoice run from an accounts package nobody remembered gets rejected by every client. A safe rollout goes in stages.

1. Find every sender. Microsoft 365, plus anything else that sends as you: accounting and invoicing software, website contact forms, your CRM, newsletters, scanners and booking systems.
2. Fix SPF and DKIM. One tidy SPF record, and DKIM signing switched on for Microsoft 365 and every other service that supports it.
3. Publish p=none with reporting. Nothing is blocked yet. The reports show who is sending as your domain and whether each genuine service passes.
4. Move to p=quarantine. Once your genuine mail is passing, failing mail is treated as suspicious, usually landing in junk folders. Keep reading the reports.
5. Move to p=reject. Failing mail is refused outright. This is the setting that properly stops exact-domain spoofing, and the goal for every domain you send from.

Don’t forget

Parked domains and reports

Domains you own but never send email from are easy to spoof. Give each one an SPF record of v=spf1 -all and a DMARC record of v=DMARC1; p=reject;, which tells the world no genuine email ever comes from them. Microsoft recommends the same DMARC record for your organisation’s .onmicrosoft.com domain if you don’t send email from it.

How long the rollout takes depends on how many systems send as you. A business that only sends from Microsoft 365 can move quickly. One with several other services needs longer at each stage, because some only send monthly, such as statement runs.

Aggregate reports arrive as compressed XML files, typically one a day from each receiving service, and they’re hard to read by hand. A DMARC reporting service turns them into a readable list of senders, which is how a forgotten system gets spotted before p=reject blocks it.