A message leaves your queue, gets accepted at the TCP level, negotiates TLS, sends its recipients, and then dies at the end of DATA with something like this:
550 5.7.26 This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.
Or this:
550 5.7.509 Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.
The 5.7.x family is the hardest bounce class to diagnose, because it means the receiver understood you perfectly and refused you anyway. There is no typo to fix, no mailbox that doesn’t exist, no full quota. The recipient server parsed your envelope, evaluated it against a policy, and said no.
This page is a reference for that family specifically — every registered code, what the major providers add on top, and how to work out which one you’re actually looking at.
Table of Contents
How to read an SMTP status code
A modern rejection line has three parts, and most senders read the wrong one.
550 5.7.26 This email has been blocked because the sender is unauthenticated.
1. The reply code (550).
The original three-digit SMTP code from RFC 5321. It tells you almost nothing beyond permanent (5xx) versus temporary (4xx). Nearly every policy rejection is a 550, sometimes 554, 552, or 530.
2. The enhanced status code (5.7.26).
Defined by RFC 3463 as class.subject.detail. The class is 2 (success), 4 (persistent transient failure) or 5 (permanent failure). The subject is the category. The detail narrows it down.
RFC 3463 defines class 5 as a failure “not likely to be resolved by resending the message in the current form. Some change to the message or the destination must be made for successful delivery.” Class 4 is one where “persistence of some temporary condition has caused abandonment or delay… sending in the future may be successful.”
Subject class 7 is the one that matters here. The IANA registry describes it as Security or Policy Status:
“The security or policy status codes report failures involving policies such as per-recipient or per-host filtering and cryptographic operations. Security and policy status issues are assumed to be under the control of either or both the sender and recipient.”
That last clause is the useful part. A 5.7.x is not a machine failure. Someone — the receiving admin, the filtering vendor, or you, via your own DMARC policy — configured a rule, and your message met it.
3. The free text.
This is the part you should read first. The enhanced status code space is small and heavily overloaded; the free text is where the receiver tells you what actually happened, which IP was involved, and where to go. Two servers returning 550 5.7.1 can mean completely unrelated things. Two servers returning “Client host [x.x.x.x] blocked using Blocklist 1” mean exactly one thing.
One structural warning before the table. The IANA registry registers codes in the class-agnostic form X.7.n, where X stands for the class digit 2, 4 or 5. That does not mean you may pick freely: each registry entry carries an “Associated basic status code” column that constrains which classes are valid for that code, and most X.7.x entries admit only 5xx. Providers are free to use the numeric detail space above 30 however they like, and they do. Gmail and Microsoft have both minted codes that collide with registered meanings. Those collisions are flagged below, because writing a filter rule against the number alone will burn you.
The 5.7.x family decoded
Codes 5.7.0 through 5.7.30 are the IANA-registered range, sourced from the SMTP Enhanced Status Codes Registry. Anything numbered above that is vendor-specific. Google’s emitted strings are quoted from Google’s Gmail SMTP errors and codes reference.
Two things worth pinning to memory. First, the IANA registry ends at X.7.30 — every code numbered above that is a vendor invention with no cross-provider meaning. Second, Gmail’s 5.7.27, 5.7.29 and 5.7.30 mean something completely different from the registered definitions of those numbers. Any bounce-classification logic that matches on the enhanced status code without also checking the receiving domain will misroute those three.
Worth adding as a footnote to the same point: the overloading is not only across vendors, it happens within a single vendor. Google itself uses 5.7.40 both for the missing-DMARC-record string in the table above and, as 504 5.7.40, for “Unrecognized authentication type”. Google likewise attaches more than one meaning to 5.7.26, which is why the table lists three distinct strings for it. Matching on the number alone fails even when you already know the receiving domain is Gmail.
4.7.x: the same family, temporary
Swap the leading 5 for a 4 and you get the same policy category as a persistent transient failure — the receiver is deferring, not refusing. RFC 3463’s own wording is the point: “sending in the future may be successful.”
These are the most actionable bounces you will ever get, because they arrive before a block:
421 4.7.0— Gmail returns this when the sending IP has no PTR record or the forward DNS does not point back to the IP. A warning shot for the same condition that becomes550 5.7.25.451 4.7.23— SPF failure being deferred rather than rejected.451 4.7.24— SPF evaluation error. Among the RFC 7372 authentication codes (5.7.20–5.7.26), 5.7.24 is the only one whose registry entry lists a 4xx alongside 550 — the other six list 550 alone. Other X.7.x codes outside that block, such as X.7.0, X.7.1 and X.7.15, also admit both classes.421 4.7.26— Gmail: “This email has been rate limited because it is unauthenticated.” Set up SPF or DKIM and this disappears before it becomes a rejection.451 4.7.26— DMARC-specific: “Unauthenticated email from [domain] is not accepted due to domain’s DMARC policy, but temporary DNS failures prevent authentication.” The policy decision is DMARC; the reason it is deferred rather than rejected is that authentication could not be evaluated — often your own DNS provider, not the receiver.
A rising 4.7.x rate to one destination is the single most reliable early warning in deliverability. It almost always precedes the equivalent 5.7.x. If you monitor one thing, monitor this.
The five most common 5.7.x causes in practice
1. Authentication failure
SPF, DKIM, DMARC, or alignment between them. Produces 5.7.23, 5.7.25, 5.7.26, 5.7.32, 5.7.40, 5.7.509 and 5.7.515. The most common single root cause is a return-path domain whose SPF record does not include the sending platform, combined with DKIM signed by the platform’s domain rather than yours — so both mechanisms technically pass but neither aligns, and DMARC rejects.
2. IP reputation
5.7.28, 5.7.508, 5.7.511, 5.7.606–649, and a large share of unlabeled 5.7.1s. The receiver has decided your IP behaves badly. Reputation systems react to volume anomalies, complaint rates, and traps — and they react faster than they recover.
3. Blocklist listing
Distinguishable from general reputation by the free text naming a list: “blocked using Blocklist 1”, “blocked using Proofpoint”, a Spamhaus URL, or a customer block list reference. Usually 5.7.1 or 5.7.0. The named list tells you exactly which delisting process applies, which is why the free text matters more than the number.
4. Content and message-format policy
5.7.0 with a security-issue string, 5.7.512, and Gmail’s substantial family of RFC 5322 compliance rejections under 5.7.1 — missing Message-ID, duplicate headers, multiple From addresses, malformed headers, encoded-word syntax where it is not permitted. These are cheap to fix and frequently overlooked because senders assume 5.7.1 always means reputation.
5. Recipient-side rules
5.7.2, 5.7.13 (public folder variant), 5.7.513, and the distribution-list and transport-rule variants of 5.7.1. Nothing is wrong with your infrastructure. One organization configured a rule. No amount of authentication or reputation work will change it — only the recipient’s admin can.
How to diagnose from your bounce logs
Do not read individual bounces. Aggregate them, and the pattern names the cause.
Group by recipient domain first. When 5.7.x bounces cluster in one domain, it’s a recipient-side rule or that organization’s block list — cause 5. Bounces spread across every Microsoft-hosted domain but nowhere else point to Microsoft reputation. And if they appear at Gmail, Microsoft, Yahoo and elsewhere simultaneously, the problem is yours: authentication or IP reputation.
Then group by the free text string, not the code. A thousand 5.7.1 bounces will resolve into three or four distinct strings, each a separate incident with a separate fix. Treating them as one problem is the most common diagnostic error in this family.
Then group by sending IP. If only one IP in your pool is affected, you have an IP reputation problem. If all of them are, you have a domain or content problem.
Sudden onset versus gradual. A 5.7.x rate that goes from near zero to significant within a single send points at a configuration change — a rotated DKIM key, an edited SPF record, a DMARC policy tightened from p=none to p=reject, a new sending IP, a new third-party tool. Check what changed in DNS in the last 72 hours before anything else. A rate that climbs over days or weeks, usually preceded by rising 4.7.x deferrals, is reputation decay: list quality, complaint rate, or volume growth.
Check whether the code is temporary. Separate 4.7.x from 5.7.x in the same report. The 4.7.x line is where you still have time.
Fixing each cause: the order that works
Order matters more than technique here. Most senders start at step 4, and it backfires.
- Stop the failing traffic to the affected destination. Retrying through a policy block is itself a negative signal, and many reputation listings expire on their own once the triggering traffic stops. Retrying resets that clock.
- Fix authentication. This is first among the real fixes because it is deterministic, fast, and verifiable. Confirm SPF passes for the return-path domain, DKIM validates on a live message, and at least one of them aligns with your From domain. Check the SPF 10-lookup limit. Check for a duplicate SPF TXT record. Authentication problems are the only 5.7.x cause you can fully verify from your side before sending again.
- Fix list and content behavior. Suppress non-engaged contacts, remove any purchased data, verify addresses that have not engaged in months, and clean up header and format problems. This is the step that determines whether a delisting request works.
- Request delisting — last, and only after steps 1–3. Every major provider evaluates whether your behavior changed. A request submitted while the bad traffic is still flowing gets ignored, and repeated ignored requests damage your credibility for future ones. For a 5.7.606–649 use sender.office.com. For 5.7.511, that portal will not work — email
[email protected]with the full NDR. - Re-warm. After delisting, return at a fraction of previous volume to your most engaged recipients only, and increase gradually while 4.7.x rates stay flat. Returning to full volume immediately reproduces the original signal.
Prevention
- Meet the bulk sender requirements before you need to. Google requires SPF and DKIM, DMARC on the sending domain, valid forward and reverse DNS, TLS, From alignment with SPF or DKIM, and one-click unsubscribe for marketing mail at 5,000+ messages a day to Gmail; we cover Gmail’s bulk sender requirements in full. Microsoft applies its own version at 5,000+ messages to consumer services, enforced via 5.7.515.
- Watch the complaint rate. Google publishes two figures at two different tiers, and conflating them is a common error. The 0.30% figure is the hard requirement in Google’s bulk sender list — “avoid ever reaching a spam rate of 0.30% or higher.” The 0.10% figure is best-practice guidance for the spam rate reported in Postmaster Tools, not an enforcement threshold. Treat 0.30% as the line you must not cross and 0.10% as the target you should operate below.
- Alert on 4.7.x, not just 5.7.x. Set a threshold on deferral rate per destination domain. This is your only reliable pre-block warning.
- Monitor authentication continuously. Enable DMARC aggregate reporting with a
rua=address and actually read it. It will show you unauthenticated sources sending as your domain long before a receiver rejects them. - Set PTR records on every sending IP, and confirm forward-confirmed reverse DNS resolves back. Non-negotiable on IPv6.
- Use the postmaster tools you have. Google’s Postmaster Tools at postmaster.google.com and Microsoft SNDS at aka.ms/snds. Note that SNDS has moved — the older
sendersupport.olc.protection.outlook.com/snds/URLs are being deprecated, so use theaka.msshort link. - Change one thing at a time in DNS. Most sudden-onset 5.7.x incidents trace to a DNS edit made days earlier by someone who did not connect the two.
Shared IP vs dedicated IP: who fixes what
The split falls cleanly along the causes above.
Authentication codes are always yours — 5.7.23, 5.7.25, 5.7.26, 5.7.32, 5.7.40, 5.7.509, 5.7.515. They are evaluated against your domain and your DNS. No IP arrangement changes that, and no provider can fix them on your behalf. On shared infrastructure your platform may host the DKIM key, but the DNS records live on your domain.
IP reputation codes depend on the arrangement — 5.7.28, 5.7.508, 5.7.511, 5.7.606–649. On a shared pool, the platform owns the IP reputation and the delisting relationship; your obligation is list quality, because one sender’s bad list degrades the pool for everyone. On a dedicated IP, the reputation is entirely yours: you benefit fully from clean sending and absorb the whole cost of a mistake. The delisting request is still usually submitted by whoever controls the IP, but the behavioral fix is yours either way.
Recipient-side rules are neither. 5.7.2, 5.7.513 and the transport-rule 5.7.1s can only be resolved by the receiving organization.
How Mailercloud handles bounce diagnostics
At Mailercloud we deliver over a billion emails a month, so we see the whole 5.7.x range daily. Bounces are classified by provider and by the free text string rather than the code alone, which keeps overloaded codes like Gmail’s 5.7.27 and 5.7.30 from being misfiled. Deferral rates are tracked per destination domain so 4.7.x patterns surface before they become blocks, authentication is validated at setup, and our deliverability team handles delisting and re-warming on shared pools.
If you are looking at a 5.7.x bounce right now and cannot work out which cause it is, talk to our deliverability team — or start free with Mailercloud.
FAQ: SMTP 5.7.x errors
What does a 5.7.1 SMTP error actually mean?
Formally, “delivery not authorized, message refused” — the receiver applied a per-host or per-recipient filter and declined. In practice 5.7.1 is the most overloaded code in email, covering IP blocklisting, relay denial, unauthenticated submission, distribution-list restrictions, transport rules and RFC 5322 format problems. The number alone is not diagnostic; the free text after it is.
Is a 5.7.x bounce permanent?
The 5 means permanent for that message as sent — resending it unchanged will fail again. It does not mean permanent for the address. Once you fix the underlying policy problem, most 5.7.x conditions clear. The exception is 5.7.17 and 5.7.18, where the mailbox or domain has changed owner; suppress those addresses.
Why do 5.7.26 and 5.7.509 both seem to be about DMARC?
They are different checks by different providers. Gmail’s 5.7.26 covers its baseline requirement that every sender authenticate with SPF or DKIM, and one of its three variants also fires on a recipient-domain DMARC policy. Microsoft’s 5.7.509 fires specifically when the 5322.From domain fails DMARC and publishes p=reject. In both cases the fix is alignment, not a weaker policy.
Why does the same code mean different things at Gmail and elsewhere?
The IANA registry only defines codes up to X.7.30, and providers extend the space independently. Gmail assigned 5.7.27, 5.7.29 and 5.7.30 to bulk-sender SPF, TLS and DKIM requirements, while those numbers are registered for null MX, ARC validation and REQUIRETLS respectively. Always interpret a code together with the receiving domain.
Should I request delisting straight away?
No. Every major provider checks whether your behavior changed before granting a delisting. Stop the failing traffic, fix authentication, clean the list, and only then submit — one request, honestly describing what you fixed. Requests submitted while the problem is ongoing get ignored, and repeated ignored requests reduce your chances next time.
What does SMTP error 5.7.26 mean?
It means the message failed authentication — Gmail returns 5.7.26 when a sender doesn’t authenticate with SPF or DKIM (and one variant fires on the recipient domain’s DMARC policy). It’s a Gmail code, not a Microsoft one. The fix is to get SPF or DKIM passing and aligned to your From domain — not to weaken any policy.
How do I fix a 5.7.509 or 5.7.515 bounce?
Both are authentication failures against your own domain. 5.7.509 means Microsoft enforced your published DMARC p=reject because neither SPF nor DKIM aligned — fix the alignment. 5.7.515 is Microsoft’s bulk-sender rule (5,000+/day to consumer inboxes) and needs SPF, DKIM, and an aligned DMARC policy all in place. Neither is solved by retrying; fix the DNS, then resend.
Amar CP is the Co-Founder and Sales Director at Mailercloud, where he leads partnerships, alliances, and customer growth. With over a decade of experience in application development, database architecture, and scaling web systems, Amar brings a rare blend of engineering depth and go-to-market expertise to email marketing. He writes about email deliverability, marketing automation, and helping small businesses grow smarter with data-driven campaigns.
