SPF, DKIM and DMARC: stop fake emails sent in your company's name

Anyone can send an email that appears to come from [email protected] — the email protocol doesn’t verify the sender by default. That is exactly what one of the most damaging scams relies on: the invoice with a changed bank account, sent “from you” to your own customers.

The defence has existed for years and is free: three DNS records — SPF, DKIM and DMARC — that tell mail servers around the world who is allowed to send on behalf of your domain and what to do with everything else. A far-from-small bonus: your legitimate email lands in Spam less often, and the big providers (Gmail, Yahoo) already require these records from senders.

What you need

• Access to your domain’s DNS management (at the registrar, or Cloudflare if the domain lives there)
• The list of services that send email on your domain’s behalf: your email platform (Microsoft 365 or Google Workspace), but also the newsletter tool, the CRM, the invoicing software — they all count
• An hour now, plus a few minutes per week during the monitoring period

Step 1: SPF — who is allowed to send

SPF is a TXT record on the root domain listing the servers authorised to send email for you.

1. Open your DNS management and look for the TXT record starting with v=spf1. There must be exactly one — two SPF records make SPF invalid.
2. If there isn’t one, create it. For Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all For Google Workspace: v=spf1 include:_spf.google.com ~all
3. For every additional service that sends email in your name, add the include from that service’s documentation to the same record (for example v=spf1 include:spf.protection.outlook.com include:your-newsletter-service.com ~all).

The trailing ~all means “anything not on the list is suspect”. There is also the stricter -all (“reject outright”) — move to it only after the DMARC reports below confirm you’ve caught every legitimate service.

Step 2: DKIM — the signature that can’t be forged

DKIM cryptographically signs every outgoing email, and the receiving server verifies the signature against a key published in your DNS.

On Microsoft 365:

1. Open security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
2. Select your domain. The portal shows you two CNAME records (selector1._domainkey and selector2._domainkey) — publish them in DNS exactly as displayed.
3. Once DNS has propagated (minutes to a few hours), come back and flip Sign messages for this domain with DKIM signatures on.

On Google Workspace:

1. In admin.google.com → Apps → Google Workspace → Gmail → Authenticate email, generate the key (choose 2048-bit).
2. Publish the TXT record shown (on the name google._domainkey) in DNS, then press Start authentication.

Third-party services (newsletter, invoicing) each have their own “authenticate your domain” page — enable DKIM there too, otherwise their emails will fail the DMARC check.

Step 3: DMARC — the policy and the reports

DMARC ties it all together: it tells servers what to do when an email fails SPF and DKIM, and sends you reports about who is sending email in your name.

1. Create a TXT record on the name _dmarc with the value: v=DMARC1; p=none; rua=mailto:[email protected]
2. p=none means “monitor only” — nothing gets blocked yet. Leave it for 2–4 weeks and read the reports arriving at the rua address: you’ll see which legitimate services you missed in steps 1–2.
3. When the reports look clean, raise the policy to p=quarantine (fake emails go to Spam), and after another quiet period, to p=reject (they are refused outright). Only p=reject truly stops the fake invoice.

Verify the result

1. Send an email from your domain to a Gmail address. Open it, click the three-dot menu → Show original: SPF, DKIM and DMARC should all show PASS.
2. Check the records directly: nslookup -type=TXT your-company.com and nslookup -type=TXT _dmarc.your-company.com (in any terminal).
3. Repeat the test from point 1 for the newsletter and any other service sending in your name.

Common mistakes

• Two SPF records. The standard allows exactly one; a second invalidates both. New services get added with include: inside the existing record.
• p=reject on day one. Without the monitoring period, you block your own newsletter or the invoices from your ERP. The 2–4 weeks of patience are part of the recipe.
• DMARC reports nobody reads. The rua address must exist and someone must look at it — that’s where you spot both the attacks and the forgotten legitimate services.
• DKIM enabled only on the main platform. The newsletter and invoicing tools also send “as you” — each needs its own setup.

For broader context on phishing — the most common way fake emails end up costing money — see how to spot a phishing attack.

---

Under NIS2? Protecting email communications falls under the law’s cyber-hygiene and communications-security measures.