Email bounces occur when the receiving server rejects a message. The bounce report usually contains an SMTP status code and a diagnostic string, which together indicate whether the failure is temporary or permanent. Understanding these codes allows you to maintain list hygiene, tune retry logic, and protect deliverability.
This article explains soft vs hard bounces, interprets SMTP 4xx and 5xx codes, and provides examples from Gmail and Microsoft 365.
The Core Difference
4xx = Soft bounce (temporary)
The server says: “Not now. Try later.”
These are transient issues such as rate limiting, DNS hiccups, temporary blocks, infrastructure delays, or mailbox over-quota conditions.
5xx = Hard bounce (permanent)
The server says: “This will not work as-is.”
These indicate invalid recipients, authentication failures, policy rejection, or domain/IP reputation problems.
MTAs retry 4xx for hours but stop immediately on 5xx unless infrastructure changes.
Soft Bounce (4xx) Examples
Gmail Soft Bounces
Common temporary Gmail conditions include: • 421 4.3.0 / 4.4.5 / 4.7.0 – Temporary system problem or server busy
• 450 4.2.1 / 4.7.1 – Relay limit exceeded, recipient policy deferral
• 452 4.2.2 – Mailbox full
• 450 4.2.0 / 451 4.3.0 – Mailbox or local resource temporarily unavailable
• 421 4.7.0 – Temporary anti-abuse or reputation-based deferral
• 421 4.7.0 – TLS required but temporarily unavailable
Gmail uses 421, 450, and 452 for rate limits, temporary blocks, and infrastructure instability.
Microsoft 365 Soft Bounces
Exchange Online uses 4xx codes for transient conditions: • 421 4.4.1 / 4.3.2 – Timeout or service unavailable
• 450 4.2.0 – Mailbox temporarily unavailable
• 452 4.2.2 / 4.3.1 – Mailbox full or system storage limits
• 451 4.7.0 / 4.7.500 – Temporary policy or server busy
• 450 4.4.312 / 451 4.4.0 – Temporary DNS lookup failure
These should be retried, with reduced concurrency if deferrals repeat.
Hard Bounce (5xx) Examples
Gmail Hard Bounces
Invalid recipients (5.1.x)
- 550 5.1.1 / 5.1.0 / 5.1.10 – Recipient does not exist
Mailbox disabled or over quota (5.2.x)
- 550 5.2.1 – Disabled mailbox
• 552 5.2.2 / 5.2.3 – Quota exceeded or message too large
Authentication / policy rejection (5.7.x)
- 550 5.7.26 – DMARC rejection
• 550 5.7.1 – Domain policy or content-based block
• 550 5.7.0 – Unauthorized mail relay
Content and formatting failures
- 554 5.5.0 / 553 5.3.0 – Format or address syntax issues
Microsoft 365 Hard Bounces
Invalid recipients (5.1.x)
- 550 5.1.1 / 5.1.10 – User not found
• 551 5.1.x – User not local
Mailbox disabled or restricted (5.2.x)
- 550 5.2.1 – Disabled mailbox
• 552 5.2.2 – Quota exceeded
Authentication and policy failures (5.7.x)
- 550 5.7.1 – Not permitted to send as this sender
• 5.7.57 – Client not authenticated
• 550 5.7.606 / 5.7.708 – IP banned or blocked
• 550 5.7.23 – SPF failure
Routing and content issues
- 553 5.5.4 – Invalid domain
• 554 5.4.14 – Routing loop detected
• 554 5.5.0 – Message refused by policy
Handling Guidelines
Soft Bounces (4xx)
- Retry with exponential backoff
• Reduce concurrency for throttled domains
• Watch domain-specific rate limits
• Maintain stable sending patterns
• Warm IPs and sending domains carefully
Hard Bounces (5xx)
Treat all hard bounces as permanent unless the provider explicitly states otherwise.
List hygiene:
• Immediately suppress 5.1.x invalid users
• Suppress 5.2.1 disabled mailboxes
• Optionally retry once for 5.2.2 / 5.2.3
• Do not retry 5.7.x until authentication or policy issues are fixed
Infrastructure:
• Fix SPF, DKIM, DMARC alignment
• Repair connectors or relay permissions
• Resolve domain/IP reputation issues
• Send small verification batches before resuming full traffic
Organizational-Level Governance
Hard bounce remediation should include:
• Global suppression rules across all systems
• Monitoring clusters of hard bounces for acquisition or list-quality issues
• Authentication and policy hardening for all sending sources
• Reviewing spam/content rejection patterns
• Enforcing verification and sunset policies to prevent decay of list quality
Summary
To sum it up, soft bounces indicate temporary conditions that resolve with proper retry logic and pacing. Hard bounces point to permanent issues such as invalid recipients or authentication and policy failures, and should feed directly into suppression and infrastructure corrections.
When SMTP codes are interpreted correctly, they expose where the failure sits: the recipient address, the remote server, your own authentication setup, or your sending behavior. This allows you to adjust retry windows, maintain list accuracy, and reinforce SPF, DKIM, and DMARC alignment.
Bounce data is not noise. It is a diagnostic layer that helps maintain a stable sender reputation and a predictable delivery path.