Reading SMTP bounce codes in WordPress mailer logs

A WP Mail SMTP log row against a failed message looks like this:

Status: Failed
Error: SMTP Error: 550 5.7.26 The email is not authenticated. For
more information, go to https://support.google.com/mail/answer/81126

Three pieces are inside that string. 550 is the SMTP reply code (from RFC 5321); 5.7.26 is the enhanced status code (from RFC 3463); the prose is what Gmail chose to say about it. Reading all three together tells the operator what the receiver decided and, usually, what to change on the sending side. Reading them in isolation, or misreading which piece is which, is where diagnosis goes wrong.

This reference decodes those log rows for the codes WordPress senders actually see: what each numeric class means, what the enhanced status codes add, and where the provider-specific variations (Gmail’s bulk-sender codes, Microsoft 365’s three flavours of 5.7.1) diverge from the RFC gloss. Grouped by cause, not by numeric order.

How WordPress mailer plugins record bounces

The three mailer plugins WordPress sites actually use, WP Mail SMTP, FluentSMTP, and Post SMTP, all preserve the SMTP response verbatim on failure, but they surface it differently in the log UI.

WP Mail SMTP stores the response in the Error field on the individual log entry (Email Log, then open a failed message). The Pro version additionally captures the raw SMTP session in the entry’s details view.
FluentSMTP shows the response in the log entry’s Details pane, alongside the Log Status: Failed marker. Pro adds the raw conversation transcript.
Post SMTP stores it in the Delivery Response column of the Message log. Failed rows carry the exact <code> <enhanced-code> <text> line the plugin got back, whether the transport was SMTP or a provider REST API.

When the mailer is configured against a REST-API provider (SendGrid, Postmark, Mailgun, Amazon SES) rather than raw SMTP, the string the plugin logs is the provider’s translation of the receiver’s rejection into their own error dictionary. The underlying wire event is the same; the string is not. The codes below apply to raw SMTP responses; the lookup section at the end covers where each provider’s dictionary lives. Delivery-status webhooks are the asynchronous surface for the same events; see email service webhooks in WordPress for the callback side.

The numeric code: 4xx versus 5xx

The three-digit reply code is the RFC 5321 class. Its first digit is the only piece of the code every receiver interprets the same way.

2yz: accepted. 250 OK is the response WordPress operators want to see; it means the receiver has taken responsibility for the message. If the plugin logs the row as Sent, this is what it saw.
4yz: transient negative. The command was refused, but the refusal is not final. A sending MTA (mail transfer agent, the software that hands the message from the sending relay to the receiving server) MAY re-attempt. Common codes: 421 (service not available, closing channel), 450 (mailbox temporarily unavailable), 451 (local processing error), 452 (insufficient system storage, often greylisting).
5yz: permanent negative. The command was refused; a retry with the same message and the same configuration will not succeed. The sending side typically issues a delivery status notification (DSN) to the envelope-from address (the address in the SMTP MAIL FROM command, which is the return path for bounces and often differs from the From: header the recipient sees). Common codes: 550 (mailbox unavailable or policy rejection, the workhorse), 552 (message size exceeds fixed limit), 553 (mailbox name syntax rejected), 554 (transaction failed).

The 4xx / 5xx split is the first thing to read. A 421 in the log at 09:00 that isn’t in the log at 09:15 means the retry succeeded and the message went; a 550 in the log means the message is gone, whatever the prose says.

Sending MTAs vary in how long they retry a 4xx before giving up and downgrading to a DSN. The provider relays a WordPress site is most likely to use retry within a day or two (AWS SES around 12 hours, SendGrid and Mailgun around 72), while self-hosted MTAs at defaults (Postfix, Sendmail, Exim) retry for five days, per RFC 5321 §4.5.4.1’s “at least 4-5 days” recommendation. The code class does not change during that window.

The enhanced status code

The 5.7.26 in the example log row is an enhanced status code, defined in RFC 3463. It uses a fixed three-part shape: class.subject.detail.

The class digit mirrors the SMTP reply code’s class (2 success, 4 transient, 5 permanent), which is why an enhanced code almost always shares its first digit with the numeric code next to it. The subject digit narrows the failure to a category. The detail digit identifies the specific failure inside that category.

The subject codes WordPress operators run into most often, from RFC 3463 §3:

Subject	Name (RFC 3463)	What it flags in a log row
`X.1.X`	Addressing Status	Something is wrong with the sender or recipient address
`X.2.X`	Mailbox Status	The recipient mailbox itself is the problem
`X.4.X`	Network and Routing Status	The delivery system couldn’t route or reach
`X.5.X`	Mail Delivery Protocol Status	Protocol-level issue between MTAs
`X.7.X`	Security or Policy Status	The receiver applied a policy and rejected

RFC 3463 defines the detail codes that follow, but individual providers extend the space with their own values (Google’s 5.7.26, 5.7.30, 5.7.40; Microsoft’s 5.7.606-649, 5.7.750). The provider extensions are the ones that carry the actual diagnosis.

Codes WordPress senders actually see

The subsections below group codes by cause; the RFC-numeric order lives in the tables under each subsection.

Authentication rejections (`5.7.x`)

The 5.7.x family absorbs the majority of policy-driven rejections a WordPress sender sees, because “the receiver applied a policy” is what most rejections actually are.

5.7.1, three separate meanings on Microsoft 365. Microsoft’s Exchange Online Protection uses 5.7.1 for three unrelated situations, distinguishable only by the accompanying prose (Microsoft NDR reference):

Delivery not authorized: the recipient (typically a distribution group) is configured to accept mail only from named senders, or an Exchange transport rule matched and blocked.
Unable to relay: the receiving system is being asked to forward a message to a domain it doesn’t handle. On a WP operator’s log this usually means an MX record pointed the message at the wrong host.
Client was not authenticated: the sending client submitted a message before authenticating. This is the WordPress-specific case: a mailer plugin configured to connect to smtp.office365.com on port 587 with a username but no working password, or with a legacy password on an account that now requires an app password or OAuth. Log rows carrying this text point at the plugin’s SMTP credentials, not at the message or the recipient. The WordPress SMTP with Microsoft 365 guide covers the credential-side setup that resolves this state.

Microsoft’s 5.7.750 Client blocked from sending from unregistered domains. Same family: a Microsoft 365 tenant sending from a domain that isn’t provisioned on the tenant. The fix is to add the domain to the tenant’s accepted domains list, not to change the WordPress side. Microsoft’s actual entry begins Service unavailable.; the 5.7.750 appears next.

Gmail app-password auth failures (535-5.7.8 and 534-5.7.9). The Gmail parallel to Microsoft’s Client was not authenticated. Both codes indicate the SMTP credentials the plugin is presenting are wrong for a Gmail SMTP submission:

534-5.7.9 Application-specific password required: the SMTP authentication is using the account’s main password, not an . Generate one and switch.
535-5.7.8 Username and Password not accepted: wrong password, App Passwords disabled at the Workspace-admin level, whitespace pasted into the password field, or the App Password revoked after the account password was rotated (Google revokes every App Password on the account when the main password changes).

Gmail App Passwords for WordPress SMTP walks through the credential-side fix.

Gmail’s 5.7.26, 5.7.27, 5.7.30, 5.7.40, the bulk-sender codes. Google and Yahoo tightened sender-authentication requirements in February 2024, and the enhanced codes they now use to say so are specific (Gmail SMTP error reference):

5.7.26: “This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.”
5.7.27: the message failed SPF specifically.
5.7.30: the message failed DKIM specifically.
5.7.40: “Your message was blocked because the sending domain doesn’t have a DMARC record or the DMARC record doesn’t specify a DMARC policy.”

WooCommerce sites that grew past five thousand transactional messages a day to Gmail addresses started collecting these codes in 2024 and 2025. All four point at the sending domain’s DNS setup, not at the message itself. The DNS setup guide covers the records the codes are asking for, and the Workspace SMTP guide covers the Workspace side of the same configuration. Once DMARC is deployed, parsing DMARC aggregate reports is the next step for confirming the fix landed.

Gmail’s 5.7.1, the generic policy code. Where Microsoft’s 5.7.1 has three specific meanings, Gmail’s 5.7.1 is deliberately broad: “the user or domain that you are sending to (or from) has a policy that prohibits the email.” Since Google moved authentication-specific rejections to the 5.7.26/27/30/40 codes above, a bare 5.7.1 from Gmail in 2026 usually points at reputation, content filtering, or recipient-side rules rather than the SPF/DKIM cases it used to catch.

Gmail’s 5.7.25, 5.7.28, 5.7.29. 5.7.25 is a missing or mismatched PTR record (the reverse-DNS entry that maps an IP address back to a hostname) on the sending IP; the relay’s problem, not the WordPress operator’s, unless the operator is running their own MTA. 5.7.28 is unusual-volume detection: the sending IP is being throttled for looking too spam-shaped. 5.7.29 is a rejection for not using TLS.

Address failures (`5.1.x`)

A 5.1.x on a WordPress send almost always means the address the plugin submitted doesn’t resolve on the recipient’s side. The message never reached spam filtering; the receiver rejected it at the recipient step.

5.1.1: bad destination mailbox address. RFC 3463 §3 quotes it as “The mailbox specified in the address does not exist.” Common causes: a typo in a WooCommerce order form, a stale WordPress user profile, a form plugin sending to a name that used to exist but doesn’t now.
5.1.10: Microsoft’s variant, “Recipient not found,” returned when EOP’s address lookup fails.
5.1.2: bad destination system address. The domain part is unreachable, meaning the MX doesn’t resolve. Usually a typo (gmial.com) or an expired domain.

5.1.x codes are the easy ones to clean up. They point at an address the sending site controls (a form input, a user record, a list entry), not at the sending infrastructure. Cleaning them up costs nothing and reduces the log noise that hides real deliverability signals.

Mailbox failures (`5.2.x`)

The mailbox exists but can’t accept the message. Recipient-side problem in almost every case; the sender’s remedy is limited to noticing.

5.2.1: mailbox disabled, not accepting messages. RFC 3463 §3: “The mailbox exists, but is not accepting messages.”
5.2.2: mailbox full. Quota or capacity limit reached on the recipient.
5.2.3: message length exceeds an administrative limit on the recipient’s system. Large WooCommerce order confirmations with many line items, or membership-plugin exports attached, can trip this against corporate mailbox limits set below Gmail’s 25 MB default.

5.2.x isn’t a reputation problem and isn’t a policy problem; the message just couldn’t be filed. Persistent 5.2.2 against the same recipient means the recipient is not reading their mail.

Rate limiting and reputation

Two shapes to watch, both of which arrive first on high-volume WordPress properties (WooCommerce launches, LMS enrolment bursts, newsletter double-opt-in floods).

421: service not available, receiver dropping the connection. Google returns it against senders exceeding per-IP or per-domain rate limits; large mailbox providers use it as a throttle signal generally. The sending MTA will retry.
4.2.1 on Gmail: rate limiting because the recipient is receiving too much mail too quickly. The message will retry; sustained recipient throttling means the recipient’s inbox rules are the bottleneck.
4.7.x: Gmail publishes 4.x.x variants of most 5.7.x codes (documented in the Gmail reference above). A 4.7.28 today is a deferred version of 5.7.28; a persistent 4.7.28 becomes a 5.7.28 once the receiver decides the pattern is not transient.
Microsoft’s 5.7.606-649 Access denied, banned sending IP: the sending IP is on Microsoft’s block list. Sender-facing action is limited to Microsoft’s delisting portal, and only if the operator controls the sending IP (which they generally don’t when sending via a provider).

Message-shape rejections

552: message exceeds a fixed size limit set by the receiver. Reduce attachment size or move large files to a link.
553: mailbox name not allowed. The address is syntactically invalid, or the receiver’s policy rejects the specific local-part (some receivers refuse role addresses).
554: transaction failed. Used as a catch-all when the receiver’s SMTP service is refusing at the transaction level. Prose is essential; the code alone doesn’t say what failed.

Transient failures worth waiting on

A 4xx in the log is not a bounce. The sending MTA has the message and will re-attempt.

421: connection-level defer. See Rate limiting above; most 421s from big providers are throttles rather than one-off connection blips.
450: mailbox temporarily unavailable. Retry.
451: receiver’s local processing error. Retry; if persistent, the receiver has a problem the sender can’t fix.
452: insufficient system storage on the receiver, or a greylisting response. Greylisting is a common anti-spam tactic where the receiver defers first-time senders and expects a compliant retry a few minutes later.

If a 4xx row from a provider relay (SES, SendGrid, Mailgun, Postmark) has been sitting in the log for more than about 72 hours, the relay has almost certainly given up and a 5xx DSN row will follow. Self-hosted setups at defaults may still be retrying up to five days. Until the DSN lands, the message is in-flight.

Looking up what your specific string means

Numeric class and enhanced code narrow the failure to a family; the prose the receiver returned is where the diagnosis lives. Four external lookup references cover the common receivers well and complement each other:

Google’s Gmail SMTP error reference: authoritative for every 5.7.x and 4.7.x code Gmail issues. Updated as Google adds codes; the 2024 bulk-sender expansions are documented here.
Microsoft’s Exchange Online NDR reference: the full table for Exchange Online / Microsoft 365 rejections, including the three 5.7.1 flavours above and the 5.7.6xx/5.7.7xx reputation and tenant-provisioning codes.
The SMTP Field Manual: MIT-licensed catalogue of real-world SMTP responses collected across 23 mailbox providers and 9 spam filters. Useful when the receiver is not Google or Microsoft (Yahoo, ProtonMail, Zoho, GMX, Rackspace, and the corporate filter services like Proofpoint and Mimecast are all covered). Community-contributed snapshots, so entries are directional rather than real-time authoritative. Built by Wildbit and now maintained by ActiveCampaign after the May 2022 acquisition.
Provider-specific error dictionaries where the sending relay is a REST-API provider: AWS SES bounce/complaint notifications, Postmark’s bounce API, Mailgun’s error index. These matter because the string Post SMTP or WP Mail SMTP logs came through the provider’s translation layer, and the provider’s dictionary is what maps the translated code back to the receiver’s original response.

For the wider session transcript that surrounds a single bounce line, how to read an SMTP session log walks through a full conversation.

What the code cannot tell you

The bounce code says what the receiver did. It does not say what to change.

5.7.26 says Gmail refused because SPF and DKIM both failed. It does not say which record to add, whether the SPF include is missing or the DKIM selector is wrong, or whether the mailer plugin’s From: header is misaligned with the authenticated domain. Answering that lives further upstream, in how email works on WordPress. 5.2.2 says the recipient’s mailbox is full; whether the sender should suppress future sends to that address, and how, is a suppression-list decision that lives in the sending provider’s dashboard, not in the log. 421 says the receiver is throttling; whether the sending pattern needs adjusting, or the volume genuinely needs a warm-up window, is a deliverability question the log doesn’t answer.

For the WordPress-side surface (how a failing send actually reaches WordPress and what hook fires), see debugging the wp_mail_failed hook. For the diagnostic flow that lands on a specific bounce in the first place, troubleshoot WordPress email.