Resolving SPF “Softfail” vs. “Hardfail”

If your email headers display Received-SPF: softfail or outbound messages bounce with SPF authentication errors, your domain’s Sender Policy Framework (SPF) record is flagging the sending server as unauthorized. The difference comes down to a single character at the end of your DNS TXT record: ~all (Softfail) or -all (Hardfail). Understanding how receiving mail transfer agents treat these mechanisms is essential for securing your domain without accidentally dropping legitimate business email.

Quick Answer

Use ~all (Softfail) during testing or when third-party services send on your behalf without dedicated IPs; receiving servers usually accept the email but may mark it as suspicious. Use -all (Hardfail) once all legitimate sending IPs and includes are verified, instructing receiving servers to reject unauthorized mail outright.

---

What the Signal Means: Softfail vs. Hardfail

The SPF record published in your domain’s DNS tells receiving mail servers which IP addresses and hostnames are authorized to send email using your domain in the SMTP envelope (Return-Path or Mail From). The qualifier attached to the all mechanism at the end of the record determines the policy enforcement:

• Softfail (~all with a tilde): The domain owner asserts that the sending IP is likely not authorized, but the receiver should not outright drop the connection. The receiving mail server marks the authentication header as softfail. Depending on the receiver’s local spam scoring and your domain’s DMARC policy, the message is typically delivered to the recipient’s inbox or routed to the spam folder.
• Hardfail (all with a hyphen): The domain owner explicitly asserts that the sending IP is unauthorized. Receiving servers evaluate the message as fail. If the receiver enforces strict SPF rejection, the message is refused during the SMTP transaction with a permanent bounce error (typically 550 5.7.1).

How Mail Receivers (and DMARC) Treat the Result

Many administrators assume that switching from ~all to -all immediately stops spoofing, or that ~all provides full protection. In modern email ecosystems, SPF is rarely evaluated in isolation.

1. Under DMARC Evaluation:
   DMARC treats SPF softfail and SPF fail identically. Both are recorded as an SPF failure. If your domain has a DMARC policy of p=reject and the message also lacks an aligned passing DKIM signature, the email will be rejected regardless of whether you used ~all or all. For deeper troubleshooting on this interaction, see How to Resolve DMARC Policy Rejects: Reject vs. Quarantine.
2. Without DMARC Enforcement:
   If you do not publish a DMARC record, the receiving gateway relies entirely on its own spam filter heuristics. With ~all, gateways (including Gmail and Microsoft 365) accept the message and add points to its internal spam score. With all, aggressive gateways will drop the message during the initial SMTP handshake.
3. Email Forwarding:
   When a user forwards an email to an external account, the forwarding server’s IP address transmits the message. Because that IP is not in your SPF record, the forwarded message will produce an SPF Hardfail if you use all. If you use ~all, the message is more likely to reach the destination quarantine or inbox, provided DKIM survived the transit.

What Can Cause an Unexpected Softfail or Hardfail

When legitimate emails from your domain fail SPF validation, the root cause usually falls into one of three categories:

• Unlisted Third-Party Sender: A newly deployed marketing platform, CRM (such as HubSpot or Salesforce), ticketing tool, or transactional mailer sent an email before its sending IPs or include: mechanisms were added to your DNS.
• Split Route or Internal Relays: Outbound messages routed through an on-premises Exchange hybrid server, secondary gateway, or corporate scanner whose egress IP is absent from the primary domain record.
• Syntax and Lookup Limits: If your SPF record contains typos or exceeds the DNS lookup threshold, receivers treat the record as a permerror or drop through to the default mechanism. If you have nested includes, review Troubleshooting “Too many lookups” in SPF.

How to Diagnose the Failing Sender IP

To identify why an email triggered a softfail or hardfail, examine the raw headers of the delivered or bounced message.

1. Open the message in your mail client and view the original message headers. For step-by-step header inspection, see How to Read Gmail “Original Message” Headers.
2. Locate the Authentication-Results header and the Received-SPF header.
3. Identify the sending IP reported in the header: Received-SPF: softfail (google.com: domain of transitioning sender@example.com does not designate 198.51.100.24 as permitted sender) client-ip=198.51.100.24;
4. Check whether client-ip belongs to one of your known outbound relays, remote branch offices, or a third-party application sending on your behalf.

Technical Fix: Resolving the Failure

Once you have identified the IP address causing the error, take the appropriate corrective action based on your diagnostic findings.

       [Inspect Message Headers]
                   │
        Does sending IP belong to
         an authorized service?
        ┌──────────┴──────────┐
       YES                    NO
        │                     │
Add IP or "include:"      Legitimate rejection.
to existing SPF TXT.     Maintain -all or ~all.
Ensure single record.    Ensure DKIM alignment.

Step 1: Update Your DNS TXT Record

If the sending service is legitimate, add its designated include or IP block to your domain’s SPF record at your DNS provider.

• Incorrect (creating a second record):Note: Publishing multiple SPF records invalidates SPF entirely. See Multiple SPF Records Detected (One Record Rule). v=spf1 include:_spf.google.com ~all v=spf1 include:sendgrid.net ~all
• Correct (combining into a single string): v=spf1 include:_spf.google.com include:sendgrid.net ~all

Step 2: Configure Third-Party Alignment

If you use third-party platforms that send transactional or marketing messages, verify whether they support custom return paths (CNAME alignment) or DKIM signing. Configuring DKIM ensures that even if SPF fails due to forwarding, the message passes authentication. Learn how to set this up in How to Align SPF/DKIM for Third-Party Apps.

Step 3: Deciding When to Switch to all

Do not change your record to -all until you have confirmed:

1. All legitimate outbound mail streams (marketing, ERP, transactional, HR tools) have been identified and included.
2. DKIM signing is active and valid across all streams.
3. Your DMARC monitoring reports (rua) show zero legitimate traffic failing SPF.

Once verified, edit your DNS TXT record to terminate with -all:

v=spf1 include:_spf.google.com include:mailgun.org -all

If you manage a broader Google Workspace environment and encounter persistent authentication warnings during deployment, consult The Workspace Email Authentication Master Checklist.