5.7.1<\/code><\/td>\n | Delivery not authorized, message refused (RFC 3463). Result of per-host or per-recipient filtering.<\/td>\n | The most overloaded code in email: IP blocklisting, relay denial, unauthenticated submission, distribution-list rules, transport rules, reputation refusal.<\/td>\n | Never diagnose 5.7.1 from the number.<\/strong> Group bounces by the free-text string first, then treat each as its own incident.<\/td>\n <\/tr>\n \n 5.7.2<\/code><\/td>\n | Mailing list expansion prohibited (RFC 3463). Permanent only.<\/td>\n | You sent to a list address you’re not an authorized poster for.<\/td>\n | Get the sending address added to the list’s allowed-senders. Recipient-side config.<\/td>\n <\/tr>\n | \n 5.7.3<\/code><\/td>\n | Security conversion required but not possible (RFC 3463).<\/td>\n | A conversion between secure messaging protocols was needed and unavailable.<\/td>\n | Rare in bulk sending. Usually an S\/MIME or gateway encryption mismatch.<\/td>\n <\/tr>\n | \n 5.7.4<\/code><\/td>\n | Security features not supported (RFC 3463). Reply code 504.<\/td>\n | The message required a security feature the delivery path couldn’t support.<\/td>\n | Remove the unsupported requirement, or route via a path that supports it.<\/td>\n <\/tr>\n | \n 5.7.5<\/code><\/td>\n | Cryptographic failure (RFC 3463). Validation\/decryption failed \u2014 key material missing or invalid.<\/td>\n | Key exchange or certificate problem.<\/td>\n | Verify certificates and key distribution with the receiving party.<\/td>\n <\/tr>\n | \n 5.7.6<\/code><\/td>\n | Cryptographic algorithm not supported (RFC 3463).<\/td>\n | Algorithm mismatch between sender and receiver.<\/td>\n | Negotiate a mutually supported algorithm.<\/td>\n <\/tr>\n | \n 5.7.7<\/code><\/td>\n | Message integrity failure (RFC 3463). The message was corrupted or altered.<\/td>\n | In-transit modification, often an intermediary rewriting content.<\/td>\n | Check for gateways or forwarders altering the message body.<\/td>\n <\/tr>\n | \n 5.7.8<\/code><\/td>\n | Authentication credentials invalid (RFC 4954). Response to AUTH.<\/td>\n | Wrong SMTP username or password on your relay.<\/td>\n | Reset the SMTP credentials. Common after a password rotation nobody told the mail server about.<\/td>\n <\/tr>\n | \n 5.7.9<\/code><\/td>\n | Authentication mechanism too weak (RFC 4954).<\/td>\n | You offered a mechanism weaker than server policy allows.<\/td>\n | Retry with a stronger SASL mechanism.<\/td>\n <\/tr>\n | \n 5.7.10<\/code><\/td>\n | Encryption needed (RFC 5248). External privacy layer required for the auth mechanism.<\/td>\n | Cleartext auth attempted without TLS.<\/td>\n | Enable STARTTLS before authenticating.<\/td>\n <\/tr>\n | \n 5.7.11<\/code><\/td>\n | Encryption required for requested auth mechanism (RFC 4954). Historical.<\/td>\n | Same class of problem as 5.7.10.<\/td>\n | Establish TLS first.<\/td>\n <\/tr>\n | \n 5.7.12<\/code><\/td>\n | A password transition is needed (RFC 4954). Usually seen as 4.7.12 (reply 422\/432).<\/td>\n | Account requires a one-time auth via a different mechanism.<\/td>\n | Authenticate once with PLAIN over TLS, then retry.<\/td>\n <\/tr>\n | \n 5.7.13<\/code><\/td>\n | User account disabled (RFC 5248). Microsoft also documents 5.7.13 (or 135) for a public folder rejecting external senders.<\/td>\n | Sending account suspended, or a recipient public folder set to reject outside mail.<\/td>\n | Your account: contact your provider (likely suspended). Public folder: only the recipient’s admin can change it.<\/td>\n <\/tr>\n | \n 5.7.14<\/code><\/td>\n | Trust relationship required (RFC 5248).<\/td>\n | Missing federation or connector trust.<\/td>\n | Configure the trust relationship on the submission server.<\/td>\n <\/tr>\n | \n 5.7.15<\/code><\/td>\n | Priority level is too low (RFC 6710). Registry permits 4xx and 5xx.<\/td>\n | Receiver accepting only higher-priority messages, often under load.<\/td>\n | Often temporary \u2014 retry later, or raise MT-PRIORITY if you legitimately can.<\/td>\n <\/tr>\n | \n 5.7.16<\/code><\/td>\n | Message too big for the specified priority (RFC 6710).<\/td>\n | Size limit applied at your priority tier.<\/td>\n | Reduce message size or send at higher priority.<\/td>\n <\/tr>\n | \n 5.7.17<\/code><\/td>\n | Mailbox owner has changed (RFC 7293). 5xx only.<\/td>\n | RRVS check: the mailbox hasn’t been continuously owned since your stated date. Classic reassigned-corporate-address case.<\/td>\n | Suppress the address.<\/strong> Strong signal the contact left the organization.<\/td>\n <\/tr>\n \n 5.7.18<\/code><\/td>\n | Domain owner has changed (RFC 7293). 5xx only.<\/td>\n | The recipient domain itself changed hands.<\/td>\n | Suppress the whole domain<\/strong> and re-verify.<\/td>\n <\/tr>\n \n 5.7.19<\/code><\/td>\n | RRVS test cannot be completed (RFC 7293). The required timestamp wasn’t recorded.<\/td>\n | Receiver can’t evaluate your RRVS assertion.<\/td>\n | Reissue without RRVS protection if the risk is acceptable.<\/td>\n <\/tr>\n | \n 5.7.20<\/code><\/td>\n | No passing DKIM signature found (RFC 7372).<\/td>\n | The message carried no valid DKIM signature and the receiver requires one.<\/td>\n | Publish the DKIM public key and confirm your signer is actually signing outbound mail.<\/td>\n <\/tr>\n | \n 5.7.21<\/code><\/td>\n | No acceptable DKIM signature found (RFC 7372).<\/td>\n | DKIM passed but no signature met the receiver’s policy (key length, algorithm, signing domain).<\/td>\n | Move off sha1, use a 2048-bit key, and sign with a domain the receiver accepts.<\/td>\n <\/tr>\n | \n 5.7.22<\/code><\/td>\n | No valid author-matched DKIM signature found (RFC 7372). Special case of 5.7.21.<\/td>\n | DKIM passes but the d= domain doesn’t match the From address \u2014 a DKIM alignment failure.<\/td>\n | Sign with a domain that aligns with the From: header \u2014 what DMARC alignment requires.<\/td>\n <\/tr>\n | \n 5.7.23<\/code><\/td>\n | SPF validation failed (RFC 7372). Used in place of 5.7.1 per RFC 7208 \u00a78.4. Microsoft: an issue affects your SPF config.<\/td>\n | Your sending IP isn’t authorized by the SPF record of the MAIL FROM (return-path) domain \u2014 not necessarily the From domain.<\/td>\n | Add the platform’s include: to the return-path domain’s SPF. Stay under the 10-lookup limit; exceeding it is permerror, which many treat as fail.<\/td>\n <\/tr>\n | \n 5.7.24<\/code><\/td>\n | SPF validation error (RFC 7372). The only 5.7.20\u201326 code whose registry entry also lists a 4xx.<\/td>\n | SPF evaluation errored (syntax, permerror, DNS failure). Gmail also returns 550 5.7.24 for “suspicious entries” in an SPF record.<\/td>\n | Validate SPF syntax. Look for multiple SPF TXT records (instant permerror) and stray +all.<\/td>\n <\/tr>\n | \n 5.7.25<\/code><\/td>\n | Reverse DNS validation failed (RFC 7372). Gmail: no PTR, or forward DNS doesn’t reference the sending IP. Enforced hardest on IPv6.<\/td>\n | Missing PTR, or PTR that doesn’t resolve forward to the same IP.<\/td>\n | Set a PTR, confirm forward-confirmed reverse DNS. If you can’t get a PTR on IPv6, send over IPv4.<\/td>\n <\/tr>\n | \n 5.7.26<\/code><\/td>\n Multiple authentication checks failed (RFC 7372). Gmail uses it for its baseline auth requirement. Not a Microsoft code.<\/strong><\/td>\n | Gmail returns 3 strings: sender unauthenticated (needs SPF or DKIM); MAIL FROM has -all and failed SPF; or unauthenticated mail rejected by the domain’s DMARC policy.<\/td>\n | Read which string you got. DMARC string means your own policy<\/strong> rejected it \u2014 fix alignment, don’t weaken the policy.<\/td>\n <\/tr>\n \n 5.7.27<\/code> Gmail collision<\/span><\/td>\n | IANA: sender address has null MX (RFC 7505). Gmail overloads it: “blocked because it didn’t pass SPF authentication.” (Google’s rationale is doc prose, not the response \u2014 don’t match on it.)<\/td>\n | Either your return-path domain publishes MX 0 . , or you’re a Gmail bulk sender failing SPF.<\/td>\n | Check the free text. Null MX: use a return-path that can receive mail. Gmail variant: fix SPF on the return-path domain.<\/td>\n <\/tr>\n | \n 5.7.28<\/code><\/td>\n | Mail flood detected (registered from an expired Internet-Draft, not an RFC). Gmail: “unusual rate of unsolicited email from your IP.”<\/td>\n | Rate and reputation. Too much, too fast, from an IP the receiver doesn’t trust.<\/td>\n | Throttle immediately.<\/strong> Cut volume, mail only engaged recipients, rebuild over days. Retrying at full rate hardens the block.<\/td>\n <\/tr>\n \n 5.7.29<\/code> Gmail collision<\/span><\/td>\n | IANA: ARC validation failure (RFC 8617). Gmail overloads it: “blocked because it wasn’t sent over a TLS connection.”<\/td>\n | Either a broken ARC chain (a forwarder\/list server), or opportunistic TLS not used at all.<\/td>\n | TLS variant: enable STARTTLS on outbound. Genuine ARC failure: the problem is at the forwarding hop, not yours.<\/td>\n <\/tr>\n | \n 5.7.30<\/code> Gmail collision<\/span><\/td>\n | IANA: REQUIRETLS support required (RFC 8689). Gmail overloads it: “blocked because it didn’t pass DKIM authentication.”<\/td>\n | Almost always the Gmail DKIM variant in practice.<\/td>\n | Publish a DKIM record and verify the signature validates on a live message, not just a test send.<\/td>\n <\/tr>\n | | Vendor-specific (above 5.7.30 \u2014 no cross-provider meaning)<\/td><\/tr>\n | \n 5.7.32<\/code> Gmail<\/span><\/td>\n | Gmail: From header isn’t aligned with the authenticated SPF or DKIM organizational domain. (Google’s docs show a 421 prefix \u2014 treat the alignment meaning as authoritative, not the class.)<\/td>\n | DMARC alignment failure specifically, distinct from authentication failure.<\/td>\n | Align the return-path (SPF) or DKIM d= domain with your From domain. A subdomain of the same org domain satisfies relaxed alignment.<\/td>\n <\/tr>\n | \n 5.7.40<\/code> Gmail<\/span><\/td>\n | Gmail: the sending domain has no DMARC record, or the record specifies no policy. (Also used as 504 5.7.40 for “unrecognized authentication type.”)<\/td>\n | No DMARC record, or malformed with no p= tag.<\/td>\n | Publish _dmarc.yourdomain.com with at least v=DMARC1; p=none; rua=mailto:\u2026 , then tighten once reports are clean.<\/td>\n <\/tr>\n | \n 5.7.57<\/code> Microsoft<\/span><\/td>\n | Microsoft: client wasn’t authenticated to send anonymous mail during MAIL FROM.<\/td>\n | An app\/device relaying through smtp.office365.com without authenticating.<\/td>\n | Fix the app’s SMTP auth config, or use a connector instead of client submission.<\/td>\n <\/tr>\n | \n 5.7.64<\/code> Microsoft<\/span><\/td>\n | Microsoft: TenantAttribution; Relay Access Denied.<\/td>\n | A hybrid inbound connector no longer matches the on-premises environment.<\/td>\n | Re-check the inbound connector’s certificate or IP config against what your on-prem servers present.<\/td>\n <\/tr>\n | \n 5.7.509<\/code> Microsoft<\/span><\/td>\n | Microsoft: sending domain doesn’t pass DMARC and has a policy of reject. Evaluated against the 5322.From address.<\/td>\n | Your own DMARC p=reject enforced against you, because neither SPF nor DKIM aligned.<\/td>\n | Fix alignment.<\/strong> Most often catches a third-party tool nobody remembered was sending as your domain.<\/td>\n <\/tr>\n \n 5.7.511<\/code> Microsoft<\/span><\/td>\n | Microsoft: “Access denied, banned sender.” Not self-service delistable.<\/td>\n | Serious reputation event on the sending IP.<\/td>\n | Email the full NDR (code + IP) to delist@microsoft.com; Microsoft responds within 48h. The self-service portal won’t work for this code.<\/td>\n <\/tr>\n | \n 5.7.515<\/code> Microsoft<\/span><\/td>\n | Microsoft consumer (Outlook.com): sending domain doesn’t meet the required authentication level. Applies at 5,000+ messages to consumer services from one From domain.<\/td>\n | Microsoft’s bulk sender requirement: SPF and DKIM passing plus a valid aligned DMARC policy.<\/td>\n | Full SPF, DKIM, and DMARC alignment \u2014 not one of the three. Enforced (reject from day one) since 29 April 2025.<\/td>\n <\/tr>\n | \n 5.7.606\u2013649<\/code> Microsoft<\/span><\/td>\n | Microsoft (collective range): “Access denied, banned sending IP.” The specific number carries no distinct published meaning.<\/td>\n | Your sending IP is on Microsoft’s blocked senders list.<\/td>\n | Fix the behavior first, then use the delist portal at sender.office.com (one email + one IP per submission). Results “up to 24 hours or longer.”<\/td>\n <\/tr>\n <\/tbody>\n <\/table>\n<\/div>\n\n\n\n Two things worth pinning to memory. First, the IANA registry ends at X.7.30<\/strong> \u2014 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.<\/p>\n\n\n\nWorth adding as a footnote to the same point: the overloading is not only across vendors, it happens within<\/em> 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<\/code>, 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.<\/p>\n\n\n\n | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |