Module 4 · 4.1

English

Nederlands English Deutsch

SPF, DKIM and DMARC: how to stop fake mail sent in your name

Module 4: Email, website and domain · Reading time: 9 minutes

Learning objective: After this lesson, you can explain how SPF, DKIM and DMARC work together to prevent misuse of your domain, where their limits lie, and you can check and assess the state of your own domain.
Key concepts: spoofing, SPF, DKIM, DMARC, alignment, policy none / quarantine / reject, DMARC reports, null MX, lookalike domain

Why this is a security topic

In module 1 you saw how invoice fraud works: a customer gets an email "from" factuur@example.com with a new IBAN. If your domain isn't protected, a scammer doesn't need to hack anything to do this. Email was designed in the 1980s without any check on the sender. Any mail server in the world can send a message with your address in the "From:" field. This is called spoofing.

The victim isn't you, but your customer or supplier. Even so, it's your name that gets damaged, and often your phone that rings. That's why protecting your mail domain belongs in a security course, not just under "making sure mail arrives".

Three DNS records work together to let recipients recognise and reject fake mail sent in your name: SPF, DKIM and DMARC. In this lesson you'll learn what they do together, what they don't do, and how to assess your own domain. The technical details (the structure of each record, the pitfalls when setting them up) are covered in the DNS course, lessons 4.3, 4.4 and 4.5, and soon in the Email in order course (in development).

Three checks, one question

Record	What it says	Where it's located	What the recipient checks
SPF	"These servers are allowed to send mail on my behalf."	TXT record on `example.com`, starts with `v=spf1`	Does the mail come from a server on the list? This looks at the technical envelope address (Return-Path), not the "From:" address.
DKIM	"Genuine mail from me carries this signature."	TXT or CNAME record on `<selector>._domainkey.example.com`	Is the digital signature correct, and was the mail unchanged in transit?
DMARC	"Does the successful check belong to my domain? If not, do this."	TXT record on `_dmarc.example.com`, starts with `v=DMARC1`	Does SPF or DKIM pass for the domain in the "From:" address? This is called alignment.

The key insight: SPF and DKIM alone aren't enough. A scammer can send mail that passes SPF neatly for their own domain and is neatly signed by their own domain, while the "From:" field shows info@example.com. Only DMARC links this to the address your customer actually sees. And only DMARC tells the recipient what to do if it doesn't match.

A recipient records the outcome in the mail's header lines. In lesson 3.3 you learned how to read these. Fake mail sent in your name might look like this to a recipient:

From: "Bakkerij Example" <factuur@example.com>
Authentication-Results: mx.leverancier.example;
  spf=pass smtp.mailfrom=bounce.goedkopemailer.example;
  dkim=pass header.d=goedkopemailer.example;
  dmarc=fail (p=reject) header.from=example.com

SPF and DKIM pass, but for a different domain. DMARC fails, and because the policy for example.com is set to reject, the recipient rejects the mail.

The three DMARC policy settings

Policy	What recipients do with mail that doesn't match	What it gives you
`p=none`	Nothing, the mail is simply delivered.	Reports (if you fill in `rua=`) and visibility into who's sending mail on your behalf. No protection yet.
`p=quarantine`	Into the spam folder.	Fake mail stands out less, but it's still there.
`p=reject`	Rejected.	The best protection against misuse of your domain.

Many businesses stay on p=none for years. That's understandable, since it's safe for your own mail, but it's not an end point. With p=none you have an alarm system that goes off but doesn't lock the door.

The right order

A policy that's too strict on a domain where not all senders are known will make your own invoices or newsletters disappear. A policy that's too loose lets scammers carry on. The order that works for almost everyone:

Make a list of everything that sends mail on behalf of your domain. Your mail provider, but also your website (contact form, online shop), your accounting software, your newsletter service, your booking system. This is what people forget most often.
Get SPF in order: exactly one record, all senders included, ending in ~all (safe default) or -all (if you're sure the list is complete). Never +all.
Turn on DKIM for every service that supports it, with exactly the records the service provides.
Start DMARC with p=none and a report address (rua=mailto:dmarc@example.com). Check the reports for a few weeks to see which services pass and which don't.
Move to p=quarantine and then to p=reject once you no longer see your own mail failing.

A domain that never sends mail (a brand name you've only registered, an old domain) can be secured strictly straight away. Scammers specifically look for domains like these, because nobody keeps an eye on them:

example.net.          MX   0 .
example.net.          TXT  "v=spf1 -all"
_dmarc.example.net.   TXT  "v=DMARC1; p=reject"

The null MX (0 .) says "no mail arrives here", -all says "nobody is allowed to send mail on behalf of this domain", and p=reject asks recipients to reject everything.

What it doesn't stop

SPF, DKIM and DMARC protect your exact domain name. They're not a phishing filter. Three things they don't stop:

Lookalike domains. A scammer registers examp1e.example or example-facturen.example and sets up SPF, DKIM and DMARC properly there themselves. That mail passes everywhere. Only reading the domain carefully (lesson 3.2) helps, along with possibly registering the most obvious variants of your own name.
Just the display name. Mail from bakkerij.example.factuur@gratismail.example with the display name "Bakkerij Example" has nothing to do with your domain. DMARC looks at the address, not the name.
A hacked mailbox. If an attacker logs in to info@example.com, they send mail through your genuine server. That mail passes SPF, DKIM and DMARC, because technically it's genuine. Strong passwords and two-factor authentication (2FA) protect against this (module 2).

SPF, DKIM and DMARC prove that an email comes from the domain. They don't prove that the domain can be trusted, nor that the sender is who they claim to be.

What it gives you and your customers

Protection for your customers. With p=reject, fake invoices sent in your exact name are rejected by the major mail providers before your customer sees them.
Better delivery. Since February 2024, Gmail and Yahoo have required SPF, DKIM and DMARC (at least p=none) from anyone sending more than around 5,000 emails a day; Microsoft has applied this requirement since May 2025 for Outlook.com and Hotmail. Even for small senders, well-authenticated mail ends up in spam less often.
Visibility into misuse. DMARC reports show if someone is trying to use your domain. Use a separate address for this; you'll soon get several reports a day.

DMARC was revised in May 2026 as RFC 9989, which replaces RFC 7489. Existing records with v=DMARC1 continue to work as normal.

In practice: what it looks like

You can check the status of any domain without installing anything. Independently, you can use the mail test on internet.nl. The public email check and domain health check from WebOké also show SPF, DMARC and MX with a green, orange or red dot. If your domain is with WebOké, the same check appears as a card on the domain page in My WebOké, with a button to add a missing DMARC record with p=none. With other providers it works in a similar way: look for "email authentication" or your domain's DNS settings.

Pay attention to what "green" means in each tool. Some tools already show green at p=none, because the record is valid. From a security point of view, p=none is orange: the record is fine, the protection isn't there yet.

Summary

Without protection, anyone can send mail with your address in the "From:" field (spoofing).
SPF says which servers may send mail, DKIM adds a signature, DMARC checks whether either one passes for the domain your customer sees and says what should happen if it doesn't.
Order: list your senders, SPF, DKIM, DMARC p=none with reports, then quarantine and reject. Lock down domains that don't send mail straight away.
They don't protect against lookalike domains, misleading display names or a hacked mailbox.
p=none is a starting point, not protection.

Quiz

Exercise

Exercise A4.1: Assessing your domain's email protection. Enter your own domain name (if you don't have one, use sidn.nl). The tool looks up MX, SPF and DMARC and shows green, orange or red for each part with an explanation. Then fill in which DMARC policy is set and what your next step would be.

Exercise A4.1: Assessing your domain's email protection

Enter your own domain name (if you don't have one, use sidn.nl). The tool looks up MX, SPF and DMARC (and DKIM if you enter a selector) and gives each part a green, amber or red rating. Then answer the two questions. The colour of your domain doesn't determine whether you pass the exercise: the answers do.

Your domain name

DKIM selector (s= from the DKIM-Signature of an email of your own) (optional)

Which DMARC policy is currently set?

What's your next step?

What you enter and what we find isn't stored. Your browser remembers your answers and whether you've passed the exercise. If you're signed in, we only save that you got the exercise (almost) right in My courses; you can delete that there too.

Exercise D4.1: Who sends mail on behalf of your domain? Make a list of all the services that send mail using an address from your domain: mail provider, website, online shop, accounting, newsletter, booking system. For each service, tick whether it's in your SPF record and whether it uses DKIM with your own domain. Write down which DMARC policy you want to have in three months' time, and what still needs to happen to get there.

Exercise D4.1: Who sends mail on behalf of your domain?

How to tackle it: (1) Write down all services that send mail using an address on your domain: mail provider, website and contact form, webshop, accounting and invoices, newsletter, booking or scheduling system, CRM, printer or scanner that emails. (2) Look up in the settings or documentation of each service how it handles SPF and DKIM for your domain. (3) Send a test email from each service to yourself and check the Authentication-Results header in the message source (lesson 3.3). (4) Note down for each service: spf=, dkim= with header.d=, dmarc=.

list of senders complete, including website and accounting
checked a test email from each sender
every sender passes DMARC (SPF or DKIM aligned)
there is a report address (rua=) and someone checks it
domains that don't send mail have null MX, v=spf1 -all and p=reject.

Which service wasn't on your list before you started looking?

What DMARC policy do you want to have in three months' time, and what still needs to happen for that?

Who in your business owns the mail settings when you take on a new service?

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing