550 5.7.1 SPF Check Failed: How to Fix It

Why this bounce happens

A 550 5.7.1 SPF check failed bounce means a receiver did not accept the message because the sending server was not allowed by the SPF policy it checked.

SPF checks the domain used in SMTP, usually the return-path or MAIL FROM domain. Some receivers also check the HELO name. That is why the domain in the bounce can be different from the visible From address your recipient sees.

The fix is a DNS and sender setup problem. You need one valid SPF record for the domain being checked, DKIM signing for each service that sends mail, and DMARC alignment with the visible From domain. Gmail says authenticated messages are less likely to be rejected or marked as spam, and Microsoft documents SPF as a check against the MAIL FROM domain. Authentication helps delivery, but it does not override reputation, complaints, bad lists, or receiver policy.

Fix SPF first

Start with the exact domain named in the bounce or shown in the return-path. Edit that domain before you change the visible From domain.

• Find all TXT records for the domain. There should be one record that starts with v=spf1. More than one SPF record returns a permanent SPF error.
• List every service that sends mail for the domain, including Google Workspace, Microsoft 365, your help desk, CRM, billing app, newsletter tool, and product email provider.
• Add only the include values or IP ranges published by those providers. For Google Workspace, a common value is include:_spf.google.com. For Microsoft 365, a common value is include:spf.protection.outlook.com. Always use the provider's current setup guide.
• Merge senders into one SPF record. Do not publish separate SPF records for separate tools.
• Remove old senders. Stale includes can authorize mail you no longer send and can push the record over the SPF DNS lookup limit.
• Keep SPF under 10 DNS lookups. RFC 7208 says include, a, mx, ptr, exists, and redirect count toward the limit. If evaluation needs more than 10, SPF returns permerror. ip4, ip6, and all do not add DNS lookups.
• Avoid ptr in SPF. RFC 7208 marks it as a mechanism not to use.

Use ~all while you are still finding senders. It means softfail for unknown senders. Move to -all only after every real sender is covered. It means fail for unknown senders, but each receiver still decides whether to reject, junk, or handle the message another way.

Check DKIM and DMARC next

SPF alone breaks easily when mail is forwarded. DKIM gives receivers a second authentication path that can survive forwarding.

Turn on DKIM in every service that sends mail as your domain. The service gives you a selector, such as selector1._domainkey, and a public key to publish in DNS. After that, the service signs messages. Receivers use the selector and DNS key to verify the signature.

Publish DMARC at _dmarc.yourdomain. A safe starter record is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain. DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the visible From domain. rua asks receivers for aggregate reports, though not every receiver sends them.

Use p=none to watch results while you find all legitimate senders. Move to p=quarantine or p=reject after reports show that real mail is passing and aligned. Those policies apply to mail that fails DMARC, but receiver handling is still receiver-defined.

The base specs are RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. For current receiver rules, check the Google sender guidelines and Microsoft email authentication guidance.

Read the bounce text

The words near 550 5.7.1 tell you which part failed.

• spf check failed: the sending IP was not allowed by the SPF record for the checked MAIL FROM or HELO domain.
• spf permerror: the SPF record is malformed, duplicated, or over the 10 DNS lookup limit.
• domain does not designate IP as permitted sender: send through an authorized server or add the sender using the provider's SPF instructions.
• dmarc fail: SPF or DKIM may have passed for another domain, but neither passed in alignment with the visible From domain.
• blocked, spam policy, or reputation: SPF may be only one factor. Check DKIM, DMARC, reverse DNS, complaint rate, list quality, sending volume changes, and blocklists.

MX records are different. They control where your domain receives mail. Broken MX will not usually cause an SPF check failed bounce for outbound mail, but it can break replies, verification mail, and some domain checks.

If you want a quick outside read, run the domain through the free InboxRadar scorecard. It checks live SPF, DKIM, DMARC, and MX records and points to the record most likely to cause the bounce.

Example repair

Say your company sends normal mail from Microsoft 365 and product mail from SendGrid. Your old SPF record only includes Microsoft.

Old record: v=spf1 include:spf.protection.outlook.com ~all

SendGrid mail can fail SPF because SendGrid is missing from the checked domain's SPF record. The repair is to merge both senders into one SPF record, using the values published by each provider.

New record: v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

Then turn on DKIM in Microsoft 365 and SendGrid. If SendGrid uses your domain in the return-path or signs with your domain, DMARC has a path to pass because SPF or DKIM can align with the visible From domain.