SPF, DKIM and DMARC Explained: Set Them Up, Check Them and Avoid the Common Mistakes

SPF, DKIM and DMARC are three DNS-based checks that let a receiving mail server decide whether a message really came from the domain it claims. SPF is a list of servers permitted to send for your domain. DKIM is a digital signature added to each message, which the receiver verifies against a public key in your DNS. DMARC sits above both: it tells receivers what to do with a message that fails, and it asks them to send you reports.

A helpful analogy, offered as an illustration and not as a technical definition: SPF is the guest list at the door, DKIM is the sealed wax stamp on the letter, and DMARC is your instruction to the doorman about what to do with a guest who is not on the list and a letter with a broken seal. DMARC also checks alignment, meaning the domain a person sees in the From address must match the domain that passed SPF or DKIM. A message can pass SPF for some other domain entirely and still fail DMARC.

SPF is a TXT record at your domain beginning v=spf1. Google's help page shows the shape: an include for each sending service, then an ending that says what to do with others. Its example for a Google Workspace domain is v=spf1 include:_spf.google.com ~all, and it recommends the ~all ending. Step one is to list every service that sends mail as you: your mailbox provider, your newsletter tool, your CRM, your invoicing system and the contact form on your website.

Two rules cause most SPF failures. First, a domain should publish only one SPF record, so add new services to the existing line instead of creating a second record. Second, the specification, RFC 7208, limits SPF evaluation to ten DNS lookups, and each include counts toward it, which is why a record stuffed with every tool you have ever trialled can break. Remove the services you no longer use and test after each change.

DKIM works by publishing a public key in DNS and having your sending system sign every message with the matching private key. Most email providers generate the key for you and give you a record to paste into your DNS, usually a CNAME or TXT record with a name that includes a selector. Google's guidance says that sending to personal Gmail accounts needs a key of 1024 bits or longer, and recommends 2048 bits where your provider supports it.

Every service that sends for your domain needs its own DKIM setup, or the signature will carry the provider's domain instead of yours and will not align for DMARC. That is the usual reason a newsletter tool passes DKIM yet fails DMARC. The setup step in the tool is often called 'authenticate your domain' or 'connect your sending domain'. HubSpot's guidance, for instance, tells users to work with their IT team to connect their email sending domain by adding records to their DNS.

A DMARC record is a TXT record at _dmarc.yourdomain with at least a version and a policy. Google's help page says to start with the policy set to none, learn how your mail is being authenticated, then move to quarantine and in time reject. The p=none stage delivers mail as normal and sends you reports at the address in the rua tag. Google also advises allowing about 48 hours after setting up SPF or DKIM before you add DMARC.

Plan the progression around evidence. Read the reports for a few weeks, identify each legitimate sender that fails, fix its SPF or DKIM setup, and only then raise the policy. Moving to reject before you have found all your senders can bounce your own invoices and password resets. Reports arrive as XML from many receivers, so most small organisations use a DMARC reporting service or a dedicated mailbox rather than reading them by hand.

Google's sender guidelines say that since 1 February 2024 every sender to personal Gmail accounts must set up SPF or DKIM, keep spam rates in Postmaster Tools below 0.3 percent, use TLS and have valid forward and reverse DNS. Senders of more than 5,000 messages a day to Gmail must have SPF, DKIM and DMARC, with the From domain aligned to the SPF or DKIM domain, and must support one-click unsubscribe for marketing messages. Google says the DMARC policy may be set to none.

Yahoo's published requirements follow a similar pattern: SPF or DKIM at a minimum for all senders, both plus a valid DMARC policy of at least p=none for bulk senders, alignment, a functioning list-unsubscribe header with a visible unsubscribe link, unsubscribes honoured within 2 days, and a spam rate below 0.3 percent. A small business sending a few hundred emails a week is under the bulk threshold, but the sensible course is to publish all three anyway: the work is the same, and it protects your domain from being forged.

The usual faults are two SPF records, an SPF record that is over the lookup limit, a third-party tool that sends under its own domain without DKIM alignment, a DMARC record sitting on the wrong host name, and a reject policy applied before every sender was fixed. Another is forgetting subdomains: mail from news.example.com may need its own records or an explicit subdomain policy. Google's guidance also warns that enabling DMARC without SPF or DKIM in place will probably cause delivery problems.

To test, send a message from each tool to a personal Gmail address and use 'Show original' to read the SPF, DKIM and DMARC results in the headers. Check that the domain in the passing result matches the From domain. Then look up your records with a free DNS or DMARC checker and compare what they show with what you intended. Use the table below to decide your next move.

Everyone who sends email from a domain they own needs at least SPF and DKIM, and in practice all three, because a domain with no DMARC policy is easy to forge and gives you no reports about who is trying. The people who feel it most are those who send marketing email or invoices from several tools at once. A business with only a free webmail address and no domain of its own has nothing to configure, though it also has no control over its reputation.

The risk of getting it wrong runs in two directions. Too lax, and criminals can send messages that look as if they come from you, which damages your customers' trust and your own deliverability. Too strict, too soon, and your own legitimate mail is rejected: a reject policy applied while your billing system still sends unsigned mail means unpaid invoices that nobody saw. That asymmetry is the reason for the staged DMARC rollout, and why we recommend a reporting period before enforcement even though it feels slow.

If this is beyond what you want to handle yourself, the work is small enough to hand to an IT contractor or your email provider's support in an afternoon. Ask for a written list of every sender found, the final SPF, DKIM and DMARC records, and the date by which the policy will be reviewed. Keep access to your DNS in your own account, so the setup does not depend on one person staying at the company.