550 5.7.1 message blocked / rejected — how to fix it

A 550 5.7.1 is the blunt one. Unlike a 421 deferral that retries on its own, this is a permanent rejection: the receiver refused the message and won't try again. So the job isn't to resend — it's to find out why you're blocked and remove the cause. The single most useful habit with a 5.7.1 is to read the words after the code before doing anything: it’s a deliberately broad rejection, and the accompanying text is what tells you which of several very different problems you actually have.

It's permanent — fix the cause, not the message

The leading 5 in 550 and in 5.7.1 both mean "permanent failure." The message is gone. What matters is the reason, because a 5.7.1 has three common roots, and they need different fixes.

Why permanent changes your response

The difference between a 4xx and a 5xx isn’t academic — it dictates what you should do. A 4xx (like the 421 deferral) keeps the message queued and tells you to try again later, so patience is the right move. A 5xx is final: the receiver has decided, the message is gone, and retrying the same mail from the same IP produces the same rejection. Worse, every rejected attempt is itself a negative signal, so blindly resending doesn’t just fail — it actively deepens the reputation problem that may have caused the block.

This matters more since the November 2025 enforcement shift, when Gmail moved from quietly routing non-compliant mail to spam toward rejecting it outright at the SMTP level. A message that once would have landed in a spam folder where a recipient might still find it now bounces back to you and never reaches them at all. The bounce damages your standing, and the recipient sees nothing. That’s why a 5.7.1 deserves an immediate, deliberate fix rather than a reflexive retry.

The three common causes

• Blocklist listing — your IP or domain is on Spamhaus, UCEPROTECT or a provider-internal list (Microsoft S3140/S3150).
• Reputation / content — Gmail and others reject mail they judge suspicious from a low-reputation sender.
• Authentication or policy — SPF/DKIM/DMARC failing, or sending from an address you're not authorized to.

Read the response: the 5.7.x family

A plain 5.7.1 is the catch-all “delivery not authorized, message refused” — it can mean a blocklist, a reputation judgement, or a content/policy block, and only the text resolves which. But the wider 5.7.x family is more specific, and the enhanced code itself often names the fix:

Code	Meaning	Where to look
5.7.1	Policy rejection / likely unsolicited	Reputation, content, or a blocklist — read the text
5.7.26	Unauthenticated sender	SPF/DKIM/DMARC not passing or aligning
5.7.27	SPF failure	SPF missing, broken, or PermError
5.7.30	DKIM failure	DKIM key wrong or body hash failing
5.7.29	TLS required	Opportunistic/forced TLS not configured
5.7.25	PTR / reverse-DNS issue	Missing or mismatched reverse DNS

If you got one of the specific codes, you already have your answer — fix the named protocol. If you got a bare 5.7.1, the text beside it is your map: a blocklist URL, a “very low reputation” note, an “Unable to Relay,” or a content complaint each send you down a different path below. Paste the whole line into the SMTP code lookup if the wording is cryptic.

Diagnose in order

Check authentication first, because it's the fastest to rule in or out: confirm SPF, DKIM and DMARC pass and align (setup guide). Then look up your sending IP and domain on the major blocklists. If you're listed, that's almost certainly the cause; if you're clean and authenticated, it's reputation or content, and the emails-going-to-spam diagnostic applies.

Fix, then delist

Delisting before fixing the cause is wasted effort — reputable lists re-list you fast. Close the source (a compromised account, a bad import, a complaint spike), then submit the delisting request with evidence the problem is resolved. Our blacklist-removal service does this end to end, and the Auto PMTA Configurator adds continuous blocklist monitoring with AI-assisted delisting so the next listing surfaces in minutes, not after your placement collapses.

The blocklist case in depth

If the response names a blocklist or your IP turns up on one, this is your cause, and it tends to be the most damaging because a single listing can block mail to many receivers at once — lots of providers consult the same public lists before accepting a connection. Public RBLs like Spamhaus, Barracuda and UCEPROTECT are the usual ones; Microsoft also runs internal lists and returns an NDR such as “Client host blocked using Blocklist 1; to request removal forward this message to [email protected].”

Getting off the list is a two-step job, in this order. First, find and fix what got you listed: a compromised account or webform relaying spam, a bad list import, a complaint spike, an unsecured server emitting outbound junk. Listings are symptoms, and reputable lists re-add you within hours if the behaviour continues, so delisting before fixing the source is wasted effort. Second, submit the delisting request through that list’s process, with evidence the source is closed. Our blacklist-removal service does both sides, and the Auto PMTA Configurator adds live monitoring so the next listing shows up in minutes rather than after a week of failed delivery.

The authentication / policy case

When the code is one of the authentication-specific ones — 5.7.26 unauthenticated, 5.7.27 SPF, 5.7.30 DKIM, 5.7.29 TLS, 5.7.25 reverse DNS — the rejection isn’t about reputation at all; it’s that your mail doesn’t meet the receiver’s baseline requirements. Since the 2026 bulk-sender rules, unauthenticated mail to the big providers is rejected rather than filtered, so a missing or misaligned signature is now a hard block, not a soft penalty.

The fix is precise: make SPF, DKIM and DMARC pass and align with your From domain, enable TLS, and publish valid reverse DNS for every sending IP. Each of these has its own deeper guide — the SPF PermError fix for a blown lookup budget, the DKIM body-hash fix for signature failures, and the authentication setup for getting all three right in PowerMTA or KumoMTA. Because the code names the protocol, this branch is usually the quickest 5.7.1 to resolve: there’s no detective work, just a record to repair.

The reputation and content case

If authentication passes and you’re not listed, but a bare 5.7.1 persists, the receiver simply doesn’t trust this mail. Gmail’s “very low reputation” rejections fall here: your IP or domain has accumulated negative history — high complaints, low engagement, bounces, a transactional/marketing mix — and the provider has decided that’s enough to refuse you. Check Google Postmaster Tools and Microsoft SNDS for the reputation read, and treat the block as the loud end of the same spectrum that sends mail to spam.

Content can trip it too, more so at Microsoft, which leans on lexical filtering: spam-trigger phrasing, heavy link density, risky attachments or topics the filter distrusts can earn a policy rejection on their own. The repair is the full reputation playbook rather than a single setting — prune unengaged recipients, cut complaints, separate streams, warm cold IPs and clean up content — which is exactly what the emails-going-to-spam diagnostic walks through. This is the slowest branch to recover, because trust is rebuilt over days of good sending, not toggled.

“Unable to Relay” is a different problem

Not every 5.7.1 is about reputation. “5.7.1 Unable to Relay” or “relaying denied” means the receiving server won’t forward the message because the connecting IP or sender isn’t authorized to relay through it — a permissions problem, not a trust one. On your side, the fix is to authenticate properly and send only from authorized IPs; you shouldn’t be relaying through a server that doesn’t expect you.

Sometimes, though, it’s the recipient organisation’s own configuration — a connector or allow-list rule on their Exchange/Microsoft 365 tenant rejecting external senders, or an IP added to the wrong filter. In that case there may be nothing to fix on your end at all, and the resolution lies with the recipient’s administrator. Recognising this early saves hours of auditing your own perfectly healthy setup for a problem that isn’t yours.

A five-minute diagnosis

You can usually pin a 5.7.1 to its real cause in a few minutes by checking three things in order, each ruling out a branch. One: the response text. If it carries a specific 5.7.x code or a blocklist URL, you’re basically done — fix the named protocol or chase the listing. Two: your listings. Look up the sending IP and domain on the major blocklists; a hit makes the blocklist branch your answer. Three: your authentication. Confirm SPF, DKIM and DMARC pass and align with a quick header read or a seed test.

What’s left after those three is reputation or content, which you confirm in Postmaster Tools and SNDS. The reason to follow this exact order is cost: the response text is free, a blocklist check takes seconds, an authentication check takes a minute — and reputation, the slowest and vaguest cause, is the one you only conclude once the cheap, fast checks have come back clean. Jumping straight to “it must be my reputation” is how people spend a week rebuilding trust when a single SPF record was the whole problem.

How long recovery takes

Recovery time depends entirely on which branch you’re in, so set expectations before you start. An authentication block clears almost immediately: fix the record, let DNS propagate, and the next send is judged on the corrected setup. A blocklist listing clears on the order of hours to a couple of days after a successful delisting — but only once the underlying cause is genuinely closed, since a premature request just resets the clock. A reputation block is the slow one: rebuilding trust takes days to weeks of clean, consistent sending, and there is no way to compress it.

Knowing the timeline keeps you from the classic error of declaring the fix “not working” and reaching for a shortcut. If you repaired authentication, test within the hour. If you delisted, give it a little time and re-check the lists before resuming. If you’re rebuilding reputation, resist the urge to ramp volume to “make up” for lost time — that’s how you earn the block again. Match your patience to the branch, and resume volume gradually once mail is being accepted.

Mistakes that keep you blocked

Four habits turn a fixable 5.7.1 into a recurring one. Retrying blindly — resending the same mail from the same IP — can’t work against a permanent code and adds negative signal with every attempt. Rotating to fresh IPs to dodge the block spreads the bad sending and reads as evasion. Delisting before fixing the cause gets you re-listed within hours. And assuming it’s always reputation sends people chasing a slow reputation rebuild when the real problem was a one-line authentication fix the code had already named.

The meta-mistake behind all four is not reading the response. A 5.7.1 is vague by design, but the text beside it, your blocklist status and your authentication results together almost always pinpoint the cause in a few minutes. Spend those minutes diagnosing before you spend hours fixing the wrong thing — it is the single most effective move you can make with this error.

Verify before you resume

Once you believe the cause is fixed, prove it before turning the taps back on, because resuming into an unresolved block just re-earns it. Re-check your blocklist status to confirm the listing has actually dropped, send a seed test to mailboxes at each major provider and read the result — you want acceptance and a clean Authentication-Results, not another 5.7.1 — and glance at Postmaster Tools and SNDS to see reputation holding or trending up rather than still falling. A single accepted test message is encouraging but not proof on its own; what you want is consistent acceptance across providers and a reputation line that has clearly stopped sliding before you commit real volume to the route again.

Only then resume, and resume gently: a route that was just blocked has no goodwill banked, so ramp volume back over days rather than returning to full send the moment mail is accepted. Treating the first successful delivery as permission to blast is how a freshly cleared block becomes the next one. Confirm acceptance, climb back gradually, and keep watching the same signals that warned you the first time.

The bottom line

550 5.7.1 is a permanent “we refused this message,” and the fix always starts the same way: read the text after the code. A specific 5.7.x names the protocol to repair; a bare 5.7.1 points to a blocklist, a reputation/content judgement, or a relaying-permission problem, which you separate by checking your listings and your authentication. Fix the actual cause — delist after closing the source, repair the named authentication record, or work the reputation playbook — and never retry blindly or rotate IPs to evade it.

Treat the block as information: the receiver is telling you precisely what it won’t accept, and meeting that bar is the whole job. If you’re blocked now and need to get delisted cleanly, our blacklist-removal service handles the diagnosis, root-cause fix and delisting end to end, and the Auto PMTA Configurator ships correct authentication plus live blocklist monitoring so a 5.7.1 is something you catch early rather than discover when delivery has already collapsed. The throughline across every branch is the same: the receiver has told you exactly what it won’t accept, and your only real job is to stop doing that one thing and prove you’ve stopped before you send again — for legitimate, opt-in senders.