Skip to content
All articles

Email security · · 8 min read

SPF, DKIM and DMARC explained – how to protect your company's email from spoofing

Three DNS records decide whether someone can send email in your name. How they work and in which order to introduce them.

Värn

Editorial team

Colleagues reviewing a screen together in an office

Email is still the most common way in for fraud against businesses. A message that appears to come from your finance manager, with new bank details for a supplier payment – that is all it takes. The good news is that three DNS records make it much harder to spoof your domain in particular.

SPF – which servers may send?

Sender Policy Framework (RFC 7208) is a TXT record on your domain that lists which servers may send email for it.

example.com.  TXT  "v=spf1 include:spf.protection.outlook.com -all"
  • include: adds another domain's list, for example Microsoft 365 (spf.protection.outlook.com) or Google Workspace (_spf.google.com).
  • The ending decides what happens to everyone else: -all (reject), ~all (mark as suspicious) or ?all (neutral). +all means anyone may send – never use it.

Three common mistakes:

  1. Several SPF records. There may only be one. Two records make the SPF check fail completely.
  2. Too many lookups. SPF allows at most ten DNS lookups. Every include counts, and services that include other services quickly use up the quota.
  3. Forgotten senders. Newsletters, invoicing systems and CRMs often send in your name. Add them before you tighten the policy.

DKIM – is the message genuine?

DomainKeys Identified Mail signs every message cryptographically. The recipient fetches the public key from DNS and checks that the message has not been changed and really comes from you.

The key is published under a so-called selector, for example selector1._domainkey.example.com in Microsoft 365 or google._domainkey.example.com in Google Workspace. You turn it on in your email provider's admin console – it creates the keys and shows which DNS records to add.

DMARC – what should happen when something does not add up?

DMARC (RFC 7489) ties SPF and DKIM to the sender name the recipient actually sees, and tells receiving servers what to do with messages that fail the check.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
PolicyEffect
p=noneNothing happens – you only get reports. Good as a start.
p=quarantineMessages that fail end up in the spam folder.
p=rejectMessages that fail are rejected.

DMARC only really protects you when the policy is quarantine or reject. p=none is a measuring mode, not protection.

Large email providers require it

Since 2024, Google and Yahoo among others require bulk senders to have SPF, DKIM and DMARC. Even for smaller senders, correct configuration improves delivery.

In which order?

  1. Take stock of every service that sends email in your name.
  2. Publish one SPF record that covers them and ends with ~all or -all.
  3. Turn on DKIM for every sending service.
  4. Publish DMARC with p=none and a reporting address. Read the reports for a couple of weeks.
  5. When all legitimate senders pass the check – raise it to p=quarantine and then p=reject.

Do not forget domains that do not send email

Domains you own but do not use for email can be spoofed too. Protect them with:

parked.example.         TXT  "v=spf1 -all"
_dmarc.parked.example.  TXT  "v=DMARC1; p=reject"

How Värn checks your email

Värn checks SPF (including the number of lookups and the final policy), the DMARC policy and whether DKIM keys exist under common selectors. Because DKIM selectors cannot be listed from the outside, a missing match is reported as not detectable – not as a shortcoming. Changes to SPF and DMARC are notified automatically.

More articles