Last updated: July 2026
In short: When email delivery fails, receiving mail servers return a numeric SMTP status code along with a diagnostic text message (bounce report). This directory summarizes the specific error strings across five major receiving platforms, linking directly to step-by-step resolution workflows and postmaster delisting paths.
Mail servers exchange messages using the Simple Mail Transfer Protocol (SMTP). When a receiving system encounters an issue during delivery—such as missing email authentication records (SPF, DKIM, DMARC), absent reverse DNS (PTR) setup, or elevated spam complaint rates—it terminates the connection with a 3-digit status code and a descriptive text explanation.
Status codes beginning with 4xx (such as 421 or 451) indicate temporary throttling (greylisting or rate-limiting), instructing the sending server to perform automated retries later. Status codes beginning with 5xx (such as 550 or 554) indicate a permanent rejection (hard bounce), requiring technical intervention before delivery can succeed.
Specific Error Dictionary and Delisting Guides by Provider
Each major receiving provider enforces distinct anti-abuse algorithms and postmaster rules. Select the provider whose server generated your bounce report to access exact error definitions, root causes, and delisting procedures:
1. Google (Gmail & Google Workspace)
Google enforces strict domain authentication across inbound messages and monitors user complaint rates inside Google Postmaster Tools. Missing SPF/DKIM or unusual volume spikes trigger immediate bounces:
2. Microsoft (Outlook.com & Microsoft 365 / Exchange)
Microsoft blocks sending IPs with poor network reputation and enforces strict SPF, DKIM, and DMARC rules for high-volume senders. Additionally, tenant IT administrators can implement local organization blocklists:
3. Deutsche Telekom (T-Online)
T-Online mail servers maintain high sensitivity toward sudden volume spikes, elevated bounce rates, and forward-confirmed reverse DNS mismatches. Deutsche Telekom provides a direct postmaster contact for unblocking inquiries:
4. 1&1 Mail & Media (GMX & WEB.DE)
The shared Nemesis ESMTP Service of GMX and WEB.DE omits Enhanced Status Codes, instead appending specific diagnostic web URLs (URIs) directly inside bounce messages to direct senders to exact delisting forms:
5. IONOS (Hosting & Mail Business)
IONOS monitors both technical authentication and connection consistency. Delivering mail to non-existent mailboxes (Mailbox unavailable) or rotating HELO/EHLO strings rapidly triggers IP blocks and temporary delays:
Best Practices to Prevent SMTP Bounces
To maintain optimal deliverability and avoid IP blocklists across all receiving providers, adhere to these foundational server standards:
- Comprehensive Authentication: Publish complete, syntax-validated SPF, DKIM, and DMARC records for all domains sending mail from your infrastructure.
- Valid Reverse DNS (PTR): Ensure that every sending IP address has a forward-confirmed reverse DNS record (
FCrDNS) matching your mail hostname. - Active List Hygiene: Immediately remove hard bounces (
5xx) from mailing databases and implement confirmed opt-in (double opt-in) workflows.
Verifying your configuration
To check your sending domain and server configuration for common authentication and DNS errors before outbound delivery fails, audit your setup with the free MXAudit scanner.