The short version

SPF (Sender Policy Framework) is a TXT record listing the servers that may send mail for a domain. A receiver looks up the record for the domain in the message’s envelope sender and checks the sending server is on the list.

What an SPF record looks like

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
  • v=spf1 says it’s an SPF record. A domain may have only one.
  • include: adds another domain’s list, usually a provider’s.
  • ip4: and ip6: list addresses directly.
  • a and mx allow the domain’s own web and mail servers.
  • ~all at the end says what to do with anything not listed: ~all (softfail) while you’re checking your senders, -all (fail) once you’re sure. Never +all, which lets anyone pass.

The two limits that break it

  • 10 DNS lookups. Each include:, a, mx, ptr, exists: and redirect= costs a lookup, including the ones inside includes. Past 10, SPF fails for every message. Adding services over the years is the usual way a record goes over.
  • One record. Two v=spf1 records make SPF fail too.

The SPF Check expands every include and counts.

What SPF checks, and what it doesn’t

SPF checks the envelope sender, the bounce address in the SMTP conversation, not the From address people see. Many services send with their own bounce address, so SPF passes for their domain, not yours. For DMARC that pass counts only when the envelope sender’s domain matches your From domain (alignment).

SPF also breaks when mail is forwarded: the forwarding server isn’t on your list. That’s why DKIM, which survives forwarding, matters more for DMARC.

Next steps

  1. Check your record with the SPF Check.
  2. Find the services sending as your domain in your DMARC reports.
  3. For each, set up DKIM with your domain; see the setup guides.