← All guides

SPF, DKIM and DMARC: email authentication explained

SPF, DKIM and DMARC are three DNS records that let receiving mail servers check that a message claiming to come from your domain is genuine. Without them your own mail lands in spam more often, and it is easier for others to send mail in your name.

Updated

SPF: which servers may send mail for the domain

SPF is a TXT record on the domain that lists the servers and services allowed to send mail for it, such as your email provider, a newsletter tool and the web server that sends order confirmations. The record starts with v=spf1, refers to each service's own list with include:, and ends with an instruction for everything else, usually ~all or -all. The receiving server checks the address in the envelope, the return path, not the From address the recipient sees. That is why SPF on its own does not stop anyone forging the visible sender.

DKIM: a signature on every message

DKIM signs each outgoing message with a private key held by the sending service. The matching public key is published in DNS under a selector, in a record named along the lines of selector._domainkey.example.com. The receiver fetches the key, checks the signature and can tell whether the message was changed on the way. Every service that sends for you should sign with your domain rather than its own, which usually means adding one or more records the service gives you. DKIM survives forwarding better than SPF, because the signature travels with the message.

DMARC: a policy that ties them together

DMARC is a TXT record at _dmarc.example.com. It tells receivers what to do with mail that fails the checks and asks them to send reports. A message passes DMARC when SPF or DKIM passes for a domain that matches the From address the recipient sees, which is called alignment. That closes the gap SPF leaves open. The policy is p=none, p=quarantine or p=reject, and the rua tag gives an address for daily aggregate reports showing who sends mail in the domain's name and whether it passes. These terms are also explained in the glossary.

The order to set them up, from p=none to p=reject

Start by listing every service that sends mail for the domain, including the ones that tend to be forgotten: the invoicing system, the CRM and the contact form on the website. Publish one SPF record that covers them all and turn on DKIM in each service. Then publish DMARC with p=none and an address for reports, and read the reports for a few weeks. When all legitimate mail passes, move on to p=quarantine and then to p=reject. Keep reading the reports afterwards, since new tools keep being added.

Sending machine mail from a subdomain

Mail sent by systems, such as order confirmations, password resets and newsletters, is best sent from a subdomain like mail.example.com or news.example.com rather than from the main domain. The subdomain gets its own SPF, its own DKIM and, if needed, its own DMARC record, and its reputation is kept apart from the staff's everyday mail. If a newsletter draws complaints, it does not drag down the delivery of invoices and personal replies. The main domain's DMARC policy applies to its subdomains unless they have a record of their own or the sp tag says otherwise.

What Gmail and Yahoo require since 2024

Since February 2024, Google and Yahoo require everyone sending to their users to have SPF or DKIM in place. Bulk senders, which Google defines as those sending more than 5,000 messages a day to Gmail addresses, must have SPF, DKIM and DMARC, with the From domain aligned with SPF or DKIM. DMARC may be set to p=none. Marketing mail must also offer one-click unsubscribe, and the spam complaint rate must be kept low, with Google naming 0.3 percent as a level never to reach. Mail that does not meet the requirements is delayed, marked as spam or rejected.

Common mistakes with SPF and DMARC

A common mistake is two SPF records on the same domain, often because the instructions for a new service said to add one. A domain may only have one, and with two, SPF returns an error; the services have to be merged into a single record. Another is the limit of ten DNS lookups: every include, a, mx and redirect counts, including those nested inside other services' records, and above ten SPF fails. Others are leaving DMARC at p=none for good, forgetting DKIM for one of the sending services, and domains that send no mail at all but lack a record saying so. InfraHarbour flags domains missing SPF, DKIM or DMARC, and support and operations is about keeping it in order over time.

Want us to look at your email setup?

Contact us