SPF, DKIM and DMARC Explained in Plain English
· 5 min read
SPF, DKIM and DMARC are three DNS records that prove email from your domain really comes from you. Mailbox providers check them on every message. Without them, your mail is more likely to land in spam or be rejected, and anyone can send email that pretends to be from your domain. Large providers such as Gmail, Yahoo and Outlook.com now require them for bulk senders.
This guide explains each record in plain English, shows an example of each, and gives a safe order to roll them out.
The short version
| Record | What it answers | Where it lives |
|---|---|---|
| SPF | Which servers may send mail for this domain? | A TXT record on your domain |
| DKIM | Was this message signed by the domain, and was it changed on the way? | A TXT record under selector._domainkey |
| DMARC | What should happen when SPF and DKIM fail, and where should reports go? | A TXT record on _dmarc |
SPF: who is allowed to send
SPF (Sender Policy Framework) is a list of the servers that are allowed to send email for your domain. When a message arrives, the receiving server checks whether the server that delivered it is on the list.
Example, for a domain that sends through Google Workspace and one email service:
example.com. TXT "v=spf1 include:_spf.google.com include:spf.your-email-service.example ~all"
v=spf1marks it as an SPF record.- Each
include:adds the servers of one service. Your provider tells you the exact value to use. ~allmeans "anything else is probably not us" (a soft fail).-allis the strict version.
Two rules catch people out. A domain must have only one SPF record, so add every service to the same record instead of creating a second one. And SPF allows at most 10 DNS lookups; each include counts, and so do the includes inside it. Too many services in one record can break SPF entirely.
DKIM: a signature on every message
DKIM (DomainKeys Identified Mail) adds a digital signature to each email. Your sending service signs the message with a private key, and you publish the matching public key in DNS. The receiving server uses the public key to check the signature. If the message was changed on the way, or was not signed by your domain, the check fails.
The record lives under a selector, a name your provider chooses so that a domain can have several keys:
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
You do not write this record yourself. Each sending service (your mailbox provider, newsletter platform or transactional email service) gives you its own DKIM record, or asks you to add a CNAME that points to one it manages. Set up DKIM for every service that sends as your domain, and use keys of at least 1024 bits; 2048 bits is the common recommendation today.
DMARC: the policy that ties them together
DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do when a message claiming to be from your domain fails authentication. It also asks them to send you reports, so you can see who is sending as your domain.
DMARC adds one important idea: alignment. A message passes DMARC only if SPF or DKIM passes and the domain that passed matches the domain in the visible From address. That is what stops someone from passing SPF on their own domain while showing your domain to the reader.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
p=nonemeans "do nothing yet, just report". It is where everyone should start.p=quarantineasks receivers to put failing mail in spam.p=rejectasks receivers to refuse failing mail completely.rua=is where daily aggregate reports are sent. They arrive as XML files, so most people use a free or paid DMARC report reader to make sense of them.
A safe rollout order
Moving straight to a strict policy can block your own legitimate mail, for example invoices sent by a billing tool you forgot about. Roll out in stages:
- List every service that sends as your domain. Mailbox provider, newsletter platform, help desk, billing, website contact forms.
- Set up SPF with all of those services in one record.
- Set up DKIM for each service, using the records they give you.
- Publish DMARC with
p=noneand aruaaddress. Nothing is blocked at this stage. - Read the reports for a few weeks. Look for legitimate services that fail SPF or DKIM alignment and fix them.
- Move to
p=quarantine. You can start with part of your mail, for examplepct=25, and raise it as you gain confidence. - Move to
p=rejectonce reports show that only unauthorised mail is failing.
The first four steps are what the big mailbox providers ask of bulk senders today. See Gmail, Yahoo and Outlook bulk sender requirements for the details.
Authentication is not the whole story
SPF, DKIM and DMARC prove who you are. They do not make mailbox providers like your mail. If you send to addresses that bounce, your reputation still suffers. Keep your list clean as well: check addresses at signup with the email verification API, and run older lists through bulk email verification before you send. For the rest of the checklist, read how to reduce your email bounce rate.