550 5.7.1 Message Rejected: Reading the Code

Your campaign stalled behind a wall of 550 5.7.1 responses, or one contact forwarded you a bounce that ends in those digits. The code looks specific. The fixes people suggest online disagree with each other, because they’re answering different bounces that share the same number.

550 means permanent failure. 5.7.1 means the receiver didn’t accept the delivery or the message content, as RFC 3463 defines it. Everything after that on the line is where the receiver tells you what it actually disliked. Treat 5.7.1 as a category, not a diagnosis.

What’s actually happening

When a receiving server turns mail away at the SMTP layer, it hands back a three-digit code, often an enhanced status like 5.7.1, plus a short English explanation. Your ESP saves that string in the bounce log or the delivery report.

Two different failures cause most of these bounces.

Policy rejection. The server took the connection, looked at who you claim to be and what you sent, and refused the message because of your reputation or your authentication. You’ll usually see words like SPF, DKIM, DMARC, policy, spam, blocked, or a provider-specific string like Microsoft’s 5.7.515.

Relay access denied. The server wouldn’t carry your mail, because you’re not allowed to send through that host for that recipient. Watch for relay, relaying denied, not permitted to relay, or unauthorized.

We call these two shapes policy rejection and relay denied. The same number covers both. A fix for relay permission does nothing for a DMARC failure, and the reverse is true too.

A real policy rejection often looks like this:

550 5.7.1 Message rejected due to SPF policy

A real relay denial often looks like this:

550 5.7.1 <user@example.com>: Relay access denied

Headers on a message that got through and then got filtered are a different story. This post covers SMTP-time rejection, where the message never reached a mailbox at all.

Policy rejection: the three causes, ranked

When the bounce text points at policy, authentication, or spam, work through these in order.

1. SPF, DKIM, or DMARC failed on the sending domain

This is the most common 5.7.1 on honest mail in 2026. Gmail, Yahoo, and Microsoft all publish sender rules that treat missing or failing authentication as a reason to reject mail outright, not just junk it.

Read Authentication-Results on a message that got through to a test mailbox, or on the outbound copy your ESP keeps:

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of bounce@esp.example does not designate 203.0.113.10 as permitted sender)
       dkim=pass header.i=@yourdomain.com
       dmarc=fail (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

One failing leg is enough for a 5.7.1 at strict receivers. The fix is the record that failed: publish or repair SPF for every sending path, turn on DKIM signing with your domain’s selector, and move DMARC past p=none toward enforcement once the reports look clean. The SPF failure guide walks the record side, and the Gmail and Yahoo requirements post covers the enforcement strings you’ll see in logs. We won’t repeat the record steps here.

2. The domain or sending IP sits on a blocklist the receiver uses

Policy text sometimes names Spamhaus, SpamCop, Barracuda, or a generic block list. A listing is a reputation verdict, not a syntax error. Check the domain and the outbound IP against the lists that matter, then fix the complaint or compromise source before you ask for removal. The spam placement hub ties blocklist hits to the symptom pattern when every provider rejects you at once.

3. Content or complaints tripped a provider’s limit

Less common as a bare 5.7.1, but it happens when the bounce mentions spam, bulk, or user complaints. Yahoo’s 421 4.7.0 [TSS04] deferral often shows up first while complaints climb. Your authentication can be perfect here and mail still stops. Pull the complaint rate from Google Postmaster Tools for Gmail traffic, and match the bounce timestamp to the campaign that went out that day.

Relay denied: the three causes, ranked

When the bounce mentions relaying, your mail reached a server that won’t send it for you.

1. Wrong SMTP host or port for the account

Marketing platforms, transactional APIs, and mailbox providers each document one submission host. Point a script or a badly configured plugin at smtp.gmail.com with credentials that can’t relay, and you get exactly this shape. Compare your setting to the provider’s current docs, then use the submission endpoint they name for logged-in clients.

2. Credentials missing, expired, or for the wrong mailbox

Relay permission belongs to the account that logged in. A rotated API key, a revoked app password, or SMTP credentials from a test server dropped into production all show up as relay errors, not SPF failures. Regenerate the credentials and send one test to yourself before you reopen the queue.

3. The server doesn’t allow your IP

Some older, self-run mail hosts only relay from office IP ranges. Cloud sending from a new datacenter IP fails with relay denied even when your DNS authentication is fine. Add the sending IP to the allowlist, or route mail through the provider’s authenticated relay instead of the MX host.

The fix and how to check it

Policy rejections end when the failing check passes on a new message. Edit the DNS, wait for it to spread, then send a test. Yesterday’s headers prove nothing about today’s record.

Run the sending domain through the email health check to see SPF, DKIM, and DMARC together. Send a test to a mailbox you control and open the raw source in the header analyzer. You want spf=pass, dkim=pass, and dmarc=pass on the From domain you actually use.

Relay rejections end when the SMTP session logs in on the correct host. The proof is one successful send in the provider’s log with no 5.7.1 on it. Don’t bulk-retry the failed queue until one clean test goes through.

Cost at scale

A 5.7.1 in a dashboard is easy to miss when it hits one segment or one provider. The dangerous version is slow drift: a DKIM selector expires on a Tuesday, a new vendor sends without an SPF include, a shared IP picks up a listing from a neighbor. Each failure looks like a lone bounce until a whole campaign returns the same code.

One header read answers today’s question for one message. It can’t tell you that SPF flipped from pass to fail six days ago while you weren’t looking. So we automated the watching. LitInboxes re-checks authentication, blocklists, and reputation on every monitored domain every six hours, keeps dated history so you can match a bounce spike to the day a record changed, and alerts you over email, Slack, Discord, or a webhook when something moves. There’s a walkthrough here if you want to see it on a live domain.

Checklist

1. Copy the full SMTP response text, not just 550 5.7.1.
2. Decide: policy rejection or relay denied, from the wording.
3. Policy path: read Authentication-Results, fix the failing record, health-check the domain.
4. Relay path: confirm host, credentials, and IP allowlisting against the provider’s docs.
5. Send one test message and confirm the code is gone before you retry the backlog.
6. If rejections cluster at one provider, check Postmaster and the blocklists for that provider’s signals.