SPF, DKIM and DMARC explained: stop your emails landing in spam

Your emails land in spam, or don't arrive at all, and nothing is obviously broken. Nine times out of ten, the cause is missing or misconfigured email authentication: SPF, DKIM and DMARC. Since 2024, Gmail and Yahoo require them for anyone sending in bulk, and every major mailbox provider uses them to decide what reaches the inbox.

Here's what each one does, in plain language, and how to set them up without breaking the email you already send.

The short version

All three are TXT records in your DNS. You don't install anything on your servers to publish them.

SPF: the list of allowed senders

SPF (Sender Policy Framework) is a list of the servers and services allowed to send email that claims to be from your domain. A typical record for a company that uses Google Workspace and a newsletter tool:

yourdomain.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

• include: pulls in a provider's list of servers. Each email service you use tells you its include.
• ~all (soft fail) means “anything else is suspicious”; -all (hard fail) means “anything else isn't us”. Start with ~all and tighten once DMARC reports show everything legitimate passes.

The SPF mistakes that break delivery

• Two SPF records. A domain must have exactly one record starting with v=spf1. With two, SPF fails for every message. Merge them into one.
• More than 10 DNS lookups. Each include, a, mx and redirect costs a lookup, including the ones nested inside providers' includes. Above 10, SPF returns an error. Remove services you no longer use.
• Forgetting a sender. Your CRM, help desk, invoicing tool and website contact form may all send as your domain. Each needs to be in SPF, or better, sign with DKIM.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The sending service signs with a private key; you publish the matching public key in DNS so receivers can check that the message really came from your domain and wasn't changed on the way.

You don't write DKIM records by hand. Each sending service (Google Workspace, Microsoft 365, your newsletter or transactional email provider) gives you a record to add, under a name called a selector:

google._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Turn on DKIM for every service that sends as your domain. DKIM survives forwarding better than SPF, which is why it carries most of the weight in DMARC.

DMARC: the policy and the reports

DMARC ties the other two together. It tells receivers what to do with mail that fails, and asks them to send you reports. A safe first record:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none: deliver as normal, but report. It changes nothing for your mail; it just turns the lights on.
• p=quarantine: send failing mail to spam.
• p=reject: refuse failing mail outright. This is what actually stops people from spoofing your domain.
• rua=: where daily aggregate reports go. They list every server sending as your domain and whether it passed.

Rolling it out safely

1. List every service that sends email as your domain. Ask finance, sales and support too.
2. Publish one SPF record that includes them all, ending in ~all.
3. Turn on DKIM in every one of those services.
4. Publish DMARC with p=none and a reporting address. Read the reports for two to four weeks.
5. Fix every legitimate sender that fails, until the reports show only spoofers failing.
6. Move to p=quarantine, then to p=reject. You can phase it in with pct=, e.g. pct=25 applies the policy to a quarter of failing mail first.

What Gmail and Yahoo require

Since February 2024, Google and Yahoo require:

• Everyone: SPF or DKIM, valid forward and reverse DNS for sending servers, and a low spam-complaint rate.
• Bulk senders (around 5,000 messages a day to Gmail): SPF and DKIM, a DMARC record (p=none is enough), alignment with the From domain, and one-click unsubscribe for marketing mail.

If you send newsletters or product email at any scale, treat all three records as required.

Don't forget the basics

Authentication only matters if mail can be delivered at all. Check that your MX records point at the right mail servers, especially after changing email providers. Mail to a domain with broken MX records simply bounces.

DNS records also change by accident, in a provider migration or a cleanup. A DNS monitor can alert you the moment your MX or TXT records stop matching what they should be, before email quietly stops working.