How can you debug SPF failures?

SPF failures show up in a few different ways: a hard bounce with "550 SPF check failed," a deferral, or an email that lands in spam with SPF: FAIL stamped in the header. The debugging path is the same regardless of which one you're seeing.

Step 1: Read the email header

Every delivered (or failed) email carries authentication results in its header. Look for the "Authentication-Results" or "Received-SPF" field. It'll tell you whether SPF passed, failed, softfailed, or returned a permerror, plus the IP that attempted delivery and the envelope from domain it was evaluated against.

Paste the full header into our email header analyzer if you'd rather not read raw text.

Step 2: Check whether the sending IP is listed

Now you have the IP. Paste your domain into our SPF checker and compare. If that IP isn't covered by any of your includes or ip4: ranges, that's the break. Usually it's one of these:

• A new sending service wasn't added to the record yet
• Your ESP updated their sending IPs and your record is stale
• The record is over 10 lookups and returning permerror before it finishes evaluating

Step 3: Make sure you're checking the right domain

SPF checks the Return-Path (envelope from), not the visible "From:" address. If your visible from is hello@yourdomain.com but your Return-Path is bounce@esp-subdomain.com, SPF is evaluating esp-subdomain.com's record, not yours. Check both domains if you're not sure which one is failing.

Step 4: Test after the fix

Send a test email to a Gmail or Outlook account you control. Open the original message and check Authentication-Results. If SPF still fails after your change, give DNS 15 to 60 minutes to propagate, then check again with dig TXT yourdomain.com +short to confirm the new record is live.

If the header shows permerror specifically, that's a lookup count problem. The SPF checker will flag which includes are eating the budget. If you're stuck after all this, the SOS hotline is free.