SPF and DKIM are the two DNS records that let receiving mail servers check whether a message genuinely came from your domain. Both are free to set up — and easy to get subtly wrong.

Together they form the foundation that DMARC builds on: SPF says which servers may send for your domain, DKIM proves a message was signed by your domain and not altered on the way. This guide covers what each record does, what a correct record looks like, the limits you need to know about, and how to verify the result.

What SPF does

SPF (Sender Policy Framework) is a TXT record on your domain listing the servers allowed to send email on its behalf. When a mail server receives a message claiming to come from your domain, it looks up the record and checks whether the sending server's IP address is on the list. A typical record looks like this:

example.com.  TXT  "v=spf1 include:_spf.mailprovider.example ip4:203.0.113.10 -all"

Reading it left to right:

  • v=spf1 — identifies the record as SPF.
  • include:_spf.mailprovider.example — pulls in the sender list published by a third-party provider, such as your hosted email or newsletter platform. One include per provider that sends for you.
  • ip4:203.0.113.10 — authorises a specific server you run yourself, such as an application server sending transactional mail.
  • -all — says every sender not listed should fail the check. The alternative ~all (softfail) marks unlisted senders as suspicious rather than failing outright.

What DKIM does

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message. Your sending system signs the message with a private key; the matching public key is published in DNS, where any receiving server can fetch it and verify both that the message came from a system holding your key and that it was not modified in transit.

The public key lives in a TXT record under a selector — a name that lets one domain hold several keys, one per sending service:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…"

In practice you rarely generate this by hand. Your email provider generates the key pair, keeps the private key, and tells you exactly which record to publish — often as a CNAME pointing at a record the provider maintains, which lets them rotate keys without involving you. Each service that sends for you (mailbox provider, newsletter tool, CRM) gets its own selector, so one leaked or retired key never affects the others.

The 10-DNS-lookup SPF limit

SPF has a hard limit that catches many organisations: evaluating a record may trigger at most 10 DNS lookups. Mechanisms that require a lookup — include, a, mx, ptr, exists and redirect — all count, and crucially, nested includes count too. One include for a large provider can itself contain several more.

Exceed the limit and the check returns a permanent error (permerror), which many receivers treat as a failure — meaning your legitimate mail starts failing authentication precisely because you authorised too many services. If your record is near the limit: remove includes for services you no longer use, prefer ip4:/ip6: entries where addresses are stable (they cost no lookups), and drop ptr, which is deprecated anyway.

Common mistakes

  • Two SPF records. A domain must have exactly one SPF record. Publishing a second one — typically when adding a new tool — makes evaluation return an error, and both records stop working. Merge all mechanisms into a single record instead.
  • Confusing ~all and -all. ~all asks receivers to treat unlisted senders with suspicion; -all asks them to fail. During rollout, ~all is the forgiving choice; once your sender list is complete and DMARC provides the enforcement layer, the difference matters less than people expect — alignment and policy do the heavy lifting.
  • Ending with +all. This authorises the entire internet to send as your domain and makes the record worse than useless.
  • Forgetting a sender. Helpdesk, invoicing, CRM and marketing platforms all send as your domain. Any service missing from SPF and without its own DKIM selector will fail authentication — usually discovered when a customer says your invoices land in spam.
  • Broken copy-paste. DKIM keys are long, and DNS interfaces split TXT values over 255 characters differently. Stray quotes, spaces or a truncated key produce a record that looks right and never validates.
  • Set-and-forget. Providers change their sending infrastructure, keys should rotate, and tools get added and retired. Records that were correct last year quietly drift out of date.

How to verify your setup

Three checks, in increasing order of confidence:

  1. Look up the records. dig TXT example.com should return exactly one SPF record; dig TXT selector1._domainkey.example.com should return the DKIM key your provider gave you.
  2. Send a real message. Send an email to a mailbox you control at a major provider and view the raw headers. The Authentication-Results header shows the verdict: you want spf=pass and dkim=pass, each for your own domain.
  3. Watch the aggregate reports. One test message proves one path works. DMARC aggregate reports show whether every source sending as your domain passes, every day, including the services you forgot about — see what is DMARC for how those reports work.

Where MailControl fits

MailControl monitors SPF, DKIM, DMARC, MX, BIMI, MTA-STS and TLS-RPT for each of your domains in one mail-health view, so a record that breaks or drifts gets noticed before your deliverability does. Its DNS setup guide provides copy-ready records for the modern trio — DMARC, MTA-STS and TLS-RPT — and DMARC aggregate report ingestion shows whether your SPF and DKIM actually pass in the real world, sender by sender. And if your domain lands on a DNS blacklist, MailControl emails you urgently.

Can a domain have two SPF records?

No. A domain must publish exactly one SPF record; if a receiving server finds more than one, evaluation returns a permanent error and authentication fails. When adding a new sending service, merge its mechanism into your existing record rather than creating a second record.

Should SPF end with ~all or -all?

Use ~all (softfail) while you are still discovering which services send as your domain, and consider -all once the sender list is complete. If the domain also publishes an enforcing DMARC policy, the practical difference is small, because DMARC alignment and policy decide what happens to failing mail.

How do I check whether DKIM is working?

Send an email to a mailbox you control at a major provider and inspect the raw message headers. The Authentication-Results header should show dkim=pass with your domain. You can also confirm the public key is published by querying the selector record, for example selector1._domainkey.example.com, as a TXT lookup.

Does SPF break when email is forwarded?

Often, yes. When a message is forwarded, it arrives at the final destination from the forwarder's server, which is not in the original domain's SPF record, so the SPF check fails. DKIM usually survives forwarding because the signature travels with the message — one of the main reasons to deploy both mechanisms rather than relying on SPF alone.

Start free Explore MailControl