Does 550 5.7.1 always mean an SPF problem?

No — and assuming it does will send you down the wrong path. 5.7.1 is the enhanced status code (RFC 3463) for 'delivery not authorized, message refused': a permanent rejection on policy grounds. SPF failure is the most common reason a receiver emits it, but the same code covers DMARC reject, a recipient's own block rules, relay-access-denied, and assorted reputation blocks. The deciding detail is the human-readable text the server appends after the numbers. 'SPF check failed' or 'does not designate as permitted sender' is SPF. 'rejected due to DMARC policy' is DMARC. 'relay access denied' is something else entirely. Read the words, not just the code.

My SPF record looks fine and the From address is my domain, so why does SPF fail?

Because SPF doesn't check the From address you see in your mail client. SPF (RFC 7208) authenticates the envelope sender — the MAIL FROM / Return-Path domain — against the IP that actually connected. Those two domains are often different. A marketing platform, helpdesk, or invoicing app sends 'as you' in the visible From header but uses its own bounce domain in MAIL FROM, and SPF is evaluated against that bounce domain, not yours. If a receiver is failing your mail on SPF, check which domain is in the Return-Path of a bounced message and confirm the connecting IP is authorized in that domain's SPF record.

Why did mail that always worked suddenly start bouncing with 550 5.7.1?

Three changes account for most sudden SPF bounces. First, you started sending through a new service — a CRM, ticketing system, or ESP — whose IP ranges were never added to your SPF record. Second, your SPF record hit the 10-DNS-lookup limit (RFC 7208 §4.6.4): every 'include' chains more lookups, and once you cross ten the record returns PermError and strict receivers reject. Third, the mail was forwarded — plain forwarding relays from the forwarder's IP, which your SPF doesn't list, so SPF fails at the final hop. Match the symptom to which one changed: a new tool, a bloated record, or a forwarding setup.

Views: 9

550 5.7.1: Fix SPF and Policy Rejection Bounces

550 5.7.1 means the receiver permanently refused your mail on policy — usually SPF. Pin down which of 4 causes in 5 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Your mail bounces back with a 550 5.7.1 and a line like “Email rejected per SPF policy” or ” is not allowed to send mail from .” The message never reached the inbox — it was refused at the door, permanently, before delivery. The receiver isn’t telling you the mail is spam. It’s telling you the connecting server isn’t on the list of machines your domain says are allowed to send for it.

Symptoms

Bounce reads 550 5.7.1 followed by text mentioning SPF, “not permitted sender,” or “policy.”
Mail from your own server gets through, but mail from a new app/service bounces.
It started after adding a marketing tool, helpdesk, or invoicing system.
Forwarded copies of your mail bounce while the originals deliver fine.
DMARC reports show SPF fail for legitimate sources you forgot about.

What 550 5.7.1 Actually Means

Split the code in two. The 550 is the basic SMTP reply (RFC 5321): a permanent failure. The receiver will not accept this message and retrying unchanged won’t help — that’s the difference from a 4xx temporary deferral, which says “try again later.” The 5.7.1 is the enhanced status code (RFC 3463), and it means specifically “delivery not authorized, message refused.” Not “mailbox full,” not “user unknown” — refused on policy. The server made a decision.

SPF is the most common policy behind that decision. SPF (RFC 7208) lets a domain publish, in a DNS TXT record, the list of IP addresses authorized to send mail on its behalf, ending with a qualifier: -all means “anything not listed should hard-fail,” ~all means “softfail — suspicious but accept.” When a receiver evaluates SPF, it checks the IP that actually connected against that list — and crucially, it checks it against the envelope sender’s domain (the MAIL FROM / Return-Path), not the From header you see in your mail client. A hard fail on a domain that publishes -all is the textbook trigger for 550 5.7.1. But because the code is generic, you have to read the accompanying text to confirm SPF is really the cause and not DMARC or a local block wearing the same number.

Top 3 Causes

A new sending service isn’t in your SPF record. You started routing mail through a CRM, ticketing platform, or email service provider, and its IP ranges were never added to your v=spf1 record. The service sends legitimately as your domain, the receiver checks SPF, the IP isn’t authorized, and -all turns that into a hard reject. The tell: your own mail server delivers fine, only mail from the new tool bounces.
The wrong domain is being checked — envelope vs. header confusion. The visible From is your domain, but the MAIL FROM / Return-Path is a different domain (a vendor’s bounce domain), and SPF is evaluated against that. Either the vendor’s SPF is broken, or you assumed your own SPF covered mail it doesn’t. The tell: your SPF looks perfect, yet SPF still fails — because the receiver never checked your record at all.
SPF returns PermError or breaks on forwarding. Too many chained include: statements push the record past the RFC 7208 §4.6.4 limit of 10 DNS lookups, so SPF returns PermError and strict receivers reject. Or the mail was forwarded: forwarding resends from the forwarder’s IP, which your SPF doesn’t list, so SPF fails at the last hop even though the original was perfectly authorized. The tell: PermError in the bounce text, or bounces only on forwarded mail.

Diagnose with DechoNet

Email Check parses your domain’s SPF record, counts the DNS lookups it triggers, and flags an over-limit record (PermError waiting to happen), a missing -all/~all qualifier, or includes that don’t resolve — so you can see whether the record itself is the problem before you chase individual senders.
Email Header Analyzer reads the Authentication-Results and Return-Path from a bounced or received message, showing the exact SPF result, the domain that was actually evaluated, and the connecting IP — which is how you confirm whether SPF checked your domain or a vendor’s, and which IP it rejected.

Resolution Checklist

Read the full bounce text after 550 5.7.1. Confirm it names SPF — if it says DMARC, relay, or reputation, this is the wrong guide.
Find the real evaluated domain: check the Return-Path / MAIL FROM of the bounced message, not the visible From. SPF is checked against that domain’s record.
Pull the connecting IP from the bounce (“does not designate …”) and confirm whether it’s authorized in the relevant SPF record.
If a new service is sending, add its published include: or IP range to your v=spf1 record — use the include the vendor documents, don’t hand-copy IPs that change.
Count your SPF DNS lookups; if you’re near or over 10, flatten or consolidate includes to clear the RFC 7208 §4.6.4 PermError.
If the failure is only on forwarded mail, that’s expected SPF behavior — rely on DKIM (which survives forwarding) and DMARC alignment instead of trying to authorize every forwarder.

When to Escalate

If SPF is failing on a vendor’s bounce domain rather than yours, the fix is on the vendor’s side — their SPF must authorize their own sending IPs. Open a ticket with the service, not with your DNS.
If your record is correct, the IP is authorized, and a specific receiver still returns 550 5.7.1, the rejection is that receiver’s local policy or a reputation block sharing the 5.7.1 code. Contact the receiving organization’s postmaster with the full bounce and message headers.