Email DNS Check

SPF IP Not Authorized

SPF IP not authorized means the server that sent your email is not listed in your SPF record. SPF checks the connecting IP address against the mechanisms in your policy. If the IP does not match any include, ip4, ip6, mx, or a mechanism, SPF fails. This often happens when a new sending service was added without updating SPF, when a relay or gateway changed its outbound IPs, or when the wrong IP range was published in DNS.

One-Minute Fix

Identify the actual sending IP from your message headers, then add that IP or the correct provider include to your SPF record.

SPF authorizing an IP range
DNS TXT
v=spf1 ip4:198.51.100.0/24 include:_spf.google.com ~all

Use the exact IP or range published by your provider. Do not guess. Check your provider's documentation or use a header analyzer to get the real connecting IP.

Re-check

Wrong vs correct setup

Missing sender IP

Missing sender IP
DNS TXT
v=spf1 include:_spf.google.com -all

If your mail goes through a relay or gateway that uses different IPs than Google's include, those IPs are not authorized and SPF will fail.

Including relay IPs

Including relay IPs
DNS TXT
v=spf1 ip4:198.51.100.10 include:_spf.google.com ~all

Adding the actual sending IP or the provider include that covers it ensures SPF passes for your legitimate traffic.

Why this happens

SPF evaluates the connecting IP, not the From address. When you add a new ESP, change relays, or move to a different outbound path, the IP that connects to the receiving server may no longer be covered by your existing SPF record.

Why this is a problem

  • Legitimate mail fails SPF even though it comes from your approved systems.
  • DMARC may fail when SPF was expected to provide alignment.
  • Receivers may treat the message as unauthenticated or spoofed.
  • Troubleshooting is confusing if you assume your SPF record covers all senders.

How this affects deliverability

When SPF fails because the IP is not authorized, mailbox providers see authentication failure. That can lead to spam placement, rejection, or inconsistent filtering. Fixing the SPF record to include the real sending IPs restores authentication and improves deliverability.

Common causes

  • A new email provider or relay was added without updating SPF.
  • The provider changed its outbound IP ranges and the include or IP list was not updated.
  • Mail goes through a secure gateway or third-party relay with different IPs.
  • The wrong IP range was copied from documentation or a generic example.

What we checked

We compared the connecting IP from your mail flow against the mechanisms in your SPF record. If the IP does not match any authorized mechanism, we report SPF IP not authorized.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

How do I find the IP that is failing SPF?

Look at the Received headers or use a header analyzer. The IP in the final receiving server's Received line is the one SPF checks.

Should I add the IP directly or use an include?

Prefer an include when the provider maintains the IP list. Add ip4 or ip6 only when you have a fixed, provider-published range and no include is available.

Can multiple IPs cause SPF to fail?

Yes. If your mail can originate from several IPs (e.g. load-balanced relays), each must be covered by your SPF record.

Next steps

  • Extract the actual connecting IP from a recent message's headers.
  • Check whether your provider has an include that covers that IP.
  • Add the include or the correct ip4/ip6 mechanism to your SPF record.
  • Remove obsolete IP ranges that no longer send mail.
  • Re-send a test message and verify SPF passes in the headers.
  • Review the full troubleshooting guidance in the SPF Hub.
  • Check signing and selector issues in the DKIM Hub.
  • Review alignment and policy issues in the DMARC Hub.

Related fixes

Explore more issues