SPF explained: authorising your senders (and the 10-lookup limit)

SPF (Sender Policy Framework) is a DNS TXT record that lists which servers are allowed to send email for your domain. When a receiver gets a message, it checks whether the sending server's IP appears in your SPF record. If it does, SPF passes.

What an SPF record looks like

SPF is a single TXT record published at your domain root:

yourdomain.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"

Reading it left to right:

• v=spf1 — the version tag (required).
• include: — pulls in another domain's SPF record, used by providers such as Google Workspace, Microsoft 365, SendGrid and Mailgun.
• ip4: / ip6: — authorise specific IP addresses or ranges.
• -all — the policy at the end. -all (hard fail) means "anything not listed is unauthorised"; ~all (soft fail) is a softer signal. Use -all once you are confident every legitimate sender is included.

SPF pass vs SPF alignment

This distinction is essential for DMARC:

• SPF pass means the sending IP is authorised by some SPF record — but that record belongs to the envelope sender (the Return-Path / MAIL FROM domain), which is often a provider's bounce domain, not yours.
• SPF alignment means the SPF (envelope) domain matches the From: domain your recipients actually see.

DMARC cares about alignment, not just a pass. A message can pass SPF against a vendor's bounce domain yet be unaligned with your From: domain — and so contribute nothing towards DMARC. The fix is usually to configure the vendor to use a custom return-path on your domain, or to rely on DKIM alignment instead.

Alignment can be relaxed (the default — a subdomain match is fine) or strict (aspf=s requires an exact match), set in your DMARC record.

The 10-DNS-lookup limit

SPF has a hard rule that catches many organisations out: an SPF record may trigger no more than 10 DNS lookups during evaluation. Each include:, a, mx, ptr and exists mechanism costs at least one lookup, and includes nest — a single provider include can pull in several more behind the scenes.

If evaluation exceeds 10 lookups, the result is permerror, and many receivers treat that as SPF fail — even though every server in your list is legitimate. Adding "just one more" vendor include is a classic way to silently break a previously working record.

How Blankitt DMARC helps

On the Domain detail page, SPF flattening expands your record's full recursive include tree so you can see exactly how many lookups it costs, and produces a flattened list of ip4/ip6 ranges that stays under the limit. Blankitt also runs SPF drift detection, re-checked automatically every day, so if a provider quietly changes the IPs behind their include you are alerted rather than surprised by a sudden delivery failure.

SPF on its own is not enough

SPF breaks when mail is forwarded — the forwarding server isn't in your record, so SPF fails on the second hop. This is exactly why DMARC accepts either aligned SPF or aligned DKIM: DKIM signatures survive forwarding, so the two mechanisms complement each other. Aim to have both aligned for every legitimate sender before you tighten your DMARC policy.