Email errors

SPF fail: what spf=fail in a header or bounce means and how to fix it

What spf=fail means, which domain SPF checked (MAIL FROM or HELO, not From), how to read Received-SPF, and how to fix missing senders and forwarding.

By Updated Last verified

On this page
  1. What spf=fail means
  2. Which domain was checked
  3. How to read the header
  4. Received-SPF
  5. Authentication-Results
  6. Which server sent it
  7. What the receiver did with it
  8. Common causes and how to fix each
  9. A sender is missing from the record
  10. The record is on a different domain from the one checked
  11. Forwarding and mailing lists
  12. The result is correct
  13. Check your record
  14. Sources

spf=fail means the receiving server tested the server that sent the message against the Sender Policy Framework (SPF) (opens in a new tab) record of the domain in the envelope sender (the MAIL FROM) or the HELO name, and got an explicit statement that the server is not authorized to use that domain (RFC 7208 section 2.6.4 (opens in a new tab)). An SPF authorization of those identities gives no assurance about other identities, such as the From address the recipient sees (section 11.2 (opens in a new tab)). A sending IP address missing from the domain's SPF record is common after adding a new email service or a non-Microsoft relay (Microsoft (opens in a new tab)), so read the header for the domain that was checked and the sending IP, then fix the record that domain publishes.

What spf=fail means

SPF (opens in a new tab) lets a domain owner publish, in the Domain Name System (DNS) (opens in a new tab), which hosts may use its domain name in the MAIL FROM or HELO identity. Receivers use that record to test the server sending the mail during the mail transaction.

Four of the possible results are easy to mix up:

Result What it means
fail An explicit statement that the sending server is not authorized to use the domain in the identity checked (RFC 7208 section 2.6.4 (opens in a new tab))
softfail A weak statement that the server is probably not authorized (section 2.6.5 (opens in a new tab))
permerror The domain's published records could not be correctly interpreted (section 2.6.7 (opens in a new tab))
temperror A transient, generally DNS, error during the check (section 2.6.6 (opens in a new tab))

A permerror is a different problem from a fail. The SPF too many DNS lookups guide covers the PermError from going over the 10-lookup limit.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

Which domain was checked

SPF checks two identities, the MAIL FROM and the HELO (RFC 7208 section 2.2 (opens in a new tab)):

Receivers are recommended to check the HELO as well, and to check it first if they check both (section 2.3 (opens in a new tab)). They must check the MAIL FROM when no HELO check was done or it reached no definitive result (section 2.4 (opens in a new tab)). When the MAIL FROM is empty (a null reverse-path), the MAIL FROM identity becomes postmaster at the HELO name.

Neither is the From address. SPF results for the MAIL FROM and HELO give no assurance about other identities in the message, such as the From header (section 11.2 (opens in a new tab)).

DMARC (opens in a new tab) (Domain-based Message Authentication, Reporting, and Conformance) is what ties SPF to the From domain: a DMARC pass needs an SPF or DomainKeys Identified Mail (DKIM) (opens in a new tab) pass for a domain aligned with the From domain (RFC 9989 section 1 (opens in a new tab)). The DMARC fail guide covers alignment.

How to read the header

A receiver that accepts a message that failed SPF should record the result in a Received-SPF or Authentication-Results header (RFC 7208 section 8.4 (opens in a new tab)). Look for either one.

Received-SPF

Received-SPF should be prepended above the Received: line the receiver generates, and it must appear above every other Received-SPF field in the message (section 9.1 (opens in a new tab)). This is the standard's example of a fail:

Received-SPF: fail (mybox.example.org: domain of
              myname@example.com does not designate
              192.0.2.1 as permitted sender)
              identity=mailfrom; client-ip=192.0.2.1;
              envelope-from="myname@example.com";
Key What it holds
identity= The identity that was checked: mailfrom for the MAIL FROM, helo for the HELO
envelope-from= The envelope sender mailbox
helo= The host name given in the HELO or EHLO command
client-ip= The IP address of the SMTP client
mechanism= The mechanism that matched, or default if none matched
receiver= The host name of the SPF verifier

In the example, the receiver checked the MAIL FROM myname@example.com, and example.com does not designate 192.0.2.1 as a permitted sender.

Authentication-Results

Authentication-Results carries less information than Received-SPF (section 9.2 (opens in a new tab)). For SPF it names the identity as smtp.mailfrom or smtp.helo, and a server that sent EHLO is still reported as helo (RFC 8601 section 2.7.2 (opens in a new tab)). In the standard's example of a message relayed inbound by two servers, the first server reports spf=fail smtp.mailfrom=example.com: SPF failed for the MAIL FROM domain example.com (RFC 8601 appendix B.5 (opens in a new tab)).

For mail sent from your domain, Google's troubleshooting guide (opens in a new tab) gives the same step: find the part of the header that starts with Authentication-Results and note the text after the spf entry.

Which server sent it

client-ip= in Received-SPF is the IP address of the SMTP client (RFC 7208 section 9.1 (opens in a new tab)). SPF judges the IP address of the last server that sent it, so when a mailing list or a resender passes the message on, its address is checked, not the address of the server that sent the message to it (RFC 7208 section 10.3 (opens in a new tab)).

Microsoft's (opens in a new tab) troubleshooting steps include identifying the sending IP address in the message headers, then verifying that it's included in the domain's SPF record. In Google Workspace, Email Log Search (ELS) includes the source IP address of incoming messages (Google (opens in a new tab)).

What the receiver did with it

Each receiver decides. The standard sets no required handling for any particular SPF result (RFC 7208 section 2.6 (opens in a new tab)), and what happens to a fail is a matter of local policy (section 8.4 (opens in a new tab)).

A fail can be the reason to reject a message during the SMTP transaction, based on the MAIL FROM or the HELO result. It can instead be one input among several that marks the message negatively, for example delivery to a special spam folder or a changed subject line (appendix G.2 (opens in a new tab)).

When authentication fails, Microsoft (opens in a new tab) lists legitimate messages being quarantined, rejected or routed to the Junk Email folder.

What -all (fail) and ~all (softfail) each ask receivers to do, and which ending to choose, are covered in SPF record with a hard fail.

Common causes and how to fix each

For a neutral, softfail or fail result, Google (opens in a new tab) lists three possible causes: a legitimate sender whose IP address isn't in your SPF record, a message intentionally sent from an unverified IP address, or an unauthorized sender, in which case the SPF result is correct.

A sender is missing from the record

Microsoft (opens in a new tab) lists a sending IP address that isn't included in the domain's SPF record, and says this is common after adding a new email service or a non-Microsoft relay. Google's troubleshooting guide adds that if your record doesn't reference all of the services that send mail for your domain, messages from those senders might fail SPF and be rejected or sent to spam.

Your record should include the domains or IP addresses of all servers that send email for your domain, including services that send automatic email such as contact forms, and any third-party service that sends for you (Google (opens in a new tab)). Microsoft's fix is to add the new service's SPF include to your record.

Add the missing service to the TXT record on your domain that starts with v=spf1, and remove domains or IP addresses you no longer use for sending. Change that record rather than adding a second one: Microsoft notes that only one SPF record is allowed per domain or subdomain, and multiple records cause a permerror (see multiple SPF records). DemiSignal's SPF record generator builds a full record from the services you pick, and says changes usually show within an hour, with some providers taking up to 48 hours.

The record is on a different domain from the one checked

A record on example.com doesn't cover marketing.example.com; each subdomain that sends email needs its own SPF record (Microsoft (opens in a new tab)).

Bounces can have an empty MAIL FROM, and then the HELO name is the only identity SPF can check, and SPF works better when administrators set the HELO name correctly and give it an appropriate SPF record (RFC 7208 section 10.1.3 (opens in a new tab)).

Forwarding and mailing lists

Google's troubleshooting guide notes that forwarded messages can fail SPF even when your domain's SPF is set up correctly, usually because of the way the forwarding server forwards them. Microsoft calls the cause, a forwarding server's IP address missing from the original sender's record, expected. If a mailing list or resender keeps the original MAIL FROM and the original message had an associated SPF record, SPF evaluation fails unless mitigations are used (RFC 7208 section 10.3 (opens in a new tab)).

  • Rewrite the MAIL FROM. A forwarder can rewrite the MAIL FROM to its own domain (appendix D.2 (opens in a new tab)). Google (opens in a new tab) asks administrators who forward mail to change the envelope sender to reference the forwarding domain.
  • Ask the forwarder. Google's troubleshooting guide treats a spam report from someone who isn't the original recipient as a sign the message was likely forwarded, and suggests contacting the third party that forwarded it to find out whether they can change how they forward.
  • Sign with DKIM. Forwarded messages often fail SPF, which is why Google recommends setting up DKIM along with SPF. The DMARC fail guide covers alignment for forwarded mail.

The result is correct

An unauthorized sender is the third of Google's causes, and in that case the SPF result is correct. Keep your record to the servers and senders that currently send email for your domain.

Check your record

DemiSignal's check reads the public DNS records of the domain you enter, including its SPF record, with no account needed. A DNS finding shows how your domain is set up; it does not show where a particular message landed. To confirm a fix, send a new message through the sender that failed and read its header.

The SPF lookup reads public DNS only and counts the record's DNS lookups against the limit of 10.

Sources

Tools for this

Frequently asked questions

What does spf=fail mean in an email header?

The receiving server checked the sending server against the SPF record of the MAIL FROM (envelope sender) domain or the HELO name, and the result is an explicit statement that the server is not authorized to use that domain.

Does SPF check the From address?

No. SPF checks the MAIL FROM and HELO identities, and its result gives no assurance about other identities in the message, such as the From header. DMARC ties SPF to the From domain through alignment.

Why does forwarded mail fail SPF?

SPF judges the IP address of the last server that sent the message, which is the forwarder. If the forwarder keeps the original MAIL FROM, its address is checked against the original sender's record and SPF fails unless mitigations are used. The forwarder can rewrite the MAIL FROM to its own domain, and Google recommends DKIM along with SPF.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account