Data Intelligence guide
SPF, DKIM and DMARC in plain English
Three short records in your domain decide how hard it is for someone to send email that looks like it came from you. Here is what each one does, in plain words, and how to tighten them without stopping your own email.
By Rudi Myers, founder of Bondstone
Why they matter
Anyone can type your address into the From line of an email. Without these records, the servers that receive it have no reliable way to tell your real email from a fake, so a fake invoice, a change of bank details or a password reset can go out in your name.
They also decide whether your own email arrives. Google's email sender guidelines ask every sender to have SPF or DKIM, and anyone sending more than 5,000 messages a day to Gmail accounts to have all three.
SPF: who may send as you
SPF is a list, published in your domain's DNS, of the services allowed to send email as you: your email provider, and anything else that sends for you, such as invoicing software or a newsletter tool. A receiving server checks where a message came from against the list.
v=spf1 include:spf.protection.outlook.com ~all
v=spf1- This is an SPF record.
include:spf.protection.outlook.com- Microsoft 365 may send as this domain. Google Workspace's is
include:_spf.google.com. ~all- Treat mail from anywhere else as suspect.
-allsays refuse it, and+alllets anyone send as you, which you never want.
An invented example, for a domain whose email is on Microsoft 365.
Two rules catch people out. A domain has one SPF record, never two. And a record may need at most ten lookups: every include counts, and a record that needs more stops working.
SPF checks the return address the sending servers use, not the From address you see. That gap is what DMARC closes.
DKIM: a signature on every message
DKIM adds a signature to every message a service sends for you. The key to check it is published in your DNS under a name called a selector. If the signature checks out, the receiver knows the message came from a service holding your key and wasn't changed on the way.
You switch DKIM on in each service that sends for you. In Microsoft 365 it's in the Microsoft Defender portal, which gives you two records to publish, selector1 and selector2. In Google Workspace it's in the Admin console, under Gmail's setting for authenticating email, and the usual selector is google.
A domain's DKIM keys can't be listed from outside, because you have to know the selector to look one up. So a check that doesn't find one hasn't proved there isn't one.
DMARC: what to do when a message fails
DMARC ties the other two to the address people actually see. It asks receivers to check that a message passed SPF or DKIM for the same domain as its From address, says what to do with one that didn't, and says where to send reports.
v=DMARC1; p=none; rua=mailto:[email protected]
v=DMARC1- This is a DMARC record. It lives at
_dmarc.example.co.uk. p=none- The policy:
nonedelivers it and reports it,quarantineputs it in junk, andrejectturns it away. rua=mailto:[email protected]- Where receivers send their daily summary reports.
An invented example. The domain and the address are made up.
How to read your own
Your records are public, so you can read them in a minute. From a Mac or Linux terminal, with your own domain:
dig +short TXT yourdomain.co.uk
dig +short TXT _dmarc.yourdomain.co.ukLook for one line starting v=spf1 in the first answer, and one starting v=DMARC1 in the second. Our free email check gives the same lookups for Windows, says what each answer means, and gives the fix for anything missing.
Why p=none protects nothing yet
p=none is the right place to start, but it isn't protection. It tells receivers to take no action against a message that fails, only to report it, so a fake invoice in your name is still delivered unless the receiver's own spam filter catches it.
Its job is to show you, through the reports, everything that sends email as you, so you can tighten the policy without stopping your own mail. A record with no rua= address sends its reports nowhere, and then nobody learns anything.
The safe order to tighten it
- List everything that sends email as you: your email provider, your website's forms, invoicing, payroll, your CRM, newsletters, booking systems.
- Put them all in one SPF record, at ten lookups or fewer.
- Switch DKIM on in each of them.
- Publish DMARC at p=none with a reporting address somebody reads, or a reporting service that turns the reports into something readable.
- Read the reports for four to eight weeks. Anything real that fails gets fixed where it is sent from.
- Move to p=quarantine, and keep reading the reports for a few weeks more.
- Move to p=reject. Fakes in your name are now turned away.
Domains you never send email from need protecting too, or they're the easy ones to fake. Publish v=spf1 -all and a DMARC record at p=reject on each, and receivers that check will turn away anything sent in their name.
What they don't stop
DMARC protects your own domain, not names that look like it. It doesn't stop a lookalike such as yourfirm-uk.com, and it doesn't stop someone who has got into a real mailbox. Two-step login on every mailbox makes the second far harder, and staff who ring to check before changing anyone's bank details help with the first.