Skip to content
NoBounch

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

RecordWhat it answersWhere it lives
SPFWhich servers may send mail for this domain?A TXT record on your domain
DKIMWas this message signed by the domain, and was it changed on the way?A TXT record under selector._domainkey
DMARCWhat 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=spf1 marks it as an SPF record.
  • Each include: adds the servers of one service. Your provider tells you the exact value to use.
  • ~all means "anything else is probably not us" (a soft fail). -all is 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=none means "do nothing yet, just report". It is where everyone should start.
  • p=quarantine asks receivers to put failing mail in spam.
  • p=reject asks 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:

  1. List every service that sends as your domain. Mailbox provider, newsletter platform, help desk, billing, website contact forms.
  2. Set up SPF with all of those services in one record.
  3. Set up DKIM for each service, using the records they give you.
  4. Publish DMARC with p=none and a rua address. Nothing is blocked at this stage.
  5. Read the reports for a few weeks. Look for legitimate services that fail SPF or DKIM alignment and fix them.
  6. Move to p=quarantine. You can start with part of your mail, for example pct=25, and raise it as you gain confidence.
  7. Move to p=reject once 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.