SPF Record Analyzer

SPF (Sender Policy Framework, RFC 7208) is a DNS-based email authentication system. You publish a TXT record at your domain listing which IP addresses or hostnames are allowed to send email for your domain. When a receiving mail server gets an email from your domain, it checks your SPF record to verify the sender is authorized. If the IP isn't listed and your SPF ends with -all (hardfail), the email is rejected. SPF works with DKIM and DMARC to form a complete email authentication stack.

RFC 7208 specifies that SPF evaluation must not exceed 10 DNS lookups. Each include, a, mx, ptr, and exists mechanism counts as one lookup. The includes you pull in may themselves contain more includes, adding to the count. If a lookup triggers more than 10 total DNS queries, the result is PermError (permanent failure), which can cause email to be rejected or not authenticated. Common causes of exceeding the limit: using multiple ESPs (Mailchimp + Salesforce + SendGrid), each adding their own include. Use SPF flattening tools to convert include chains to direct IP4 lists.

-all (hardfail): emails from unauthorized senders should be rejected. This is the strictest setting and what you want for domains that never send email from unknown sources. ~all (softfail): unauthorized senders are marked (usually moved to spam) but not rejected. This is more permissive and is the safe default when first deploying SPF. ?all (neutral): no policy stated — treat unauthorized senders as normal. +all: explicitly allow all senders — essentially disables SPF protection. Recommendation: start with ~all, monitor DMARC reports for a few weeks, then switch to -all.

Solutions: (1) SPF Flattening: replace include: mechanisms with the actual IP4 ranges they resolve to. Services like MXToolbox or AutoSPF can automate this. (2) Consolidate ESPs: if you send from multiple services, check if they all need their own SPF include. Some services allow adding your domain to their SPF rather than the reverse. (3) Remove unused includes: if you stopped using an ESP, remove its include. (4) Use an SPF macro instead of include for services that support it. Note: flattened SPF records break if the ESP changes their IP ranges — use a managed SPF service for critical domains.

SPF alone has a critical limitation: it only checks the envelope sender (MAIL FROM), not the From: header that users see. Attackers can send email with a legitimate envelope sender but a spoofed From: header. SPF + DKIM + DMARC together close this gap: DMARC requires "alignment" between the SPF/DKIM domain and the visible From: header, ensuring what the user sees matches what was authenticated. Without DMARC, passing SPF alone doesn't prevent display name spoofing attacks.