A WP Mail SMTP log shows 550 5.7.1 against a message to a Gmail address. The same code appears against a message to Outlook, with a different cause behind it. The receiving server’s wire text is where the difference lives, and the 
SMTP Field Manual is the catalogue of that wire text.
The site is a searchable collection of real-world SMTP responses (bounces, deferrals, and outright rejections) recorded against major mailbox providers and spam-filter services. Each entry is the actual string the receiver returned, mapped to its SMTP code class and tagged for severity. For a WordPress operator parsing a mailer-plugin log, that mapping is the diagnostic step between “the message failed” and “this is why, and this is whether to retry, fix, or escalate.” For the configuration that produces the SMTP transaction in the first place, see How to set up email on WordPress.
What the manual covers
The catalogue is organised along two axes: SMTP code on one side, providers and filters on the other.
SMTP codes with dedicated pages: 421, 422, 450, 451, 452 on the persistent-transient-failure (4xx) side; 501, 540, 550, 551, 552, 553, 554 on the permanent-error (5xx) side. Each code carries the standard semantics plus the variations introduced by individual providers.
Mailbox providers (23 at time of writing): Amazon SES, Apple, AT&T, Comcast, Free, GMX, GoDaddy, Google, Hey, Hostpoint, ImprovMX, Infomaniak, Mail.ru, Orange, Outlook, ProtonMail, QQ, Rackspace, Rambler, Web.de, Yahoo, Yandex, Zoho.
Spam-filter services (9): Barracuda, Cisco, Email Security.cloud, Exchange Online Protection, FireEye, Mimecast, Proofpoint, Trend Micro, ZeroSpam.
Each cross-listing carries a low / medium / high severity tag. The tag sits between the bare numeric code, which is too coarse to act on alone, and the prose explanation, which carries the diagnosis once the reader knows what to look for.
How a WordPress operator uses it
Bounce text reaches a WordPress operator through three common channels: a mailer-plugin log (WP Mail SMTP, FluentSMTP, Post SMTP all surface SMTP responses from the relay), a transactional provider’s dashboard (Postmark and SendGrid expose the receiver’s response on every bounced event), or the local mail log on a self-hosted server. In all three, the operator ends up holding a string of the form <code> <enhanced-code> <text>.
The diagnostic flow:
- The numeric code (421, 550, 554) gives the class. 4xx says the receiver rejected the command but the rejection is temporary, so a retry later may succeed; 5xx says the receiver rejected it permanently, so a retry without changing the message or the sender’s configuration will not. RFC 5321, section 4.2.1, is the definition.
- The enhanced status code (the
5.7.1part) refines the class with a detail subject.5.7.1is policy-related,5.1.1is bad-recipient,5.4.xis network or routing. RFC 3463 defines the schema. - The provider-specific prose is the actual diagnosis. Gmail’s
550 5.7.1is a broad policy code covering low IP or domain reputation, unsolicited-content detection, header non-compliance, and a share of authentication failures. Google has been moving the authentication-specific cases to5.7.26,5.7.27,5.7.30, and5.7.40since the 2024 bulk-sender rules took effect, so a bare5.7.1on Gmail in 2026 leans more toward reputation and content than it used to. Outlook’s550 5.7.1on Exchange Online Protection, the filter layer in front of Microsoft 365 mailboxes, covers sender IP or reputation listings on the Microsoft Customer Block List, recipient-policy rejection, and relay-auth-required cases. Same code class, different remediation.
The Field Manual is the step where (3) becomes routine. The reader looks up the code, lands on the provider page, and reads what that provider tends to mean by it. The result is a diagnosis instead of a guess. For the wider session-log context that surrounds the bounce line, see how to read an SMTP session log; for getting a test message to the receiver in the first place, see test the WordPress mail server with swaks.
What the manual is not
The Field Manual is a reference of receiver behaviour. It does not cover:
- The SMTP protocol itself. No walkthrough of the SMTP state machine, ESMTP extensions, pipelining, or AUTH negotiation. RFC 5321 still owns that material.
- Long-tail providers. The catalogue concentrates on major mailbox providers and well-known filters. Regional ISPs, small business hosts, and obscure ESPs are mostly absent; the contribution guidelines explicitly direct submissions toward “major providers” rather than comprehensive coverage.
- Deliverability strategy. The manual tells the operator what the receiver said. It does not tell the operator how to fix sender reputation, configure DMARC, or warm a new IP. That is the job of a guide, not a code reference.
- Real-time accuracy. Entries are community-contributed snapshots. Providers reword bounce text periodically; a manual entry from 2021 may not match a 2026 bounce verbatim. The code class and the general category are stable; the exact prose is not.
Treating the manual as the first lookup rather than the last word fits the shape of the resource.
Provenance and contribution
The SMTP Field Manual was built by 
Wildbit, the team behind 
Postmark. Wildbit sold Postmark and DMARC Digests to ActiveCampaign in May 2022; the SMTP Field Manual was part of that deal and is now maintained by ActiveCampaign’s Postmark team. nanoPost’s Postmark review covers the service that funded the work.
The site is MIT-licensed and open source. The code and data live at 
ActiveCampaign/smtp-field-manual on GitHub (the old wildbit/smtp-field-manual URL redirects there). Data is stored as JSON files under /data; new entries arrive via pull request, GitHub issue, or email to [email protected]. Contributions are asked to strip personal information and replace unique mail-server identifiers with root domains before submission.
Where to go from here
The Field Manual is one of three reference points in a bounce-decoding workflow on a WordPress site. The other two:
- How email works: a WordPress operator’s reference for the chain that produces the bounce in the first place: what each stage controls and what each stage doesn’t.
- Troubleshoot WordPress email for the diagnostic flow that lands on a specific bounce line.
Together, the three reduce a bounce line to something the operator can act on.