Competitor Email Retry Policies
Research on how major email service providers handle delivery retries, including attempt counts, intervals, and best practices.
Last Updated: February 2025
Executive Summary
Most ESPs retry failed email deliveries for 72 hours using exponential backoff strategies, with retry attempts ranging from 6 to unlimited attempts. The standard approach balances quick recovery from temporary issues against resource efficiency and recipient server health.
Key Findings:
- Duration: 72 hours is the industry standard maximum retry window
- Strategy: Exponential backoff is universally adopted
- First retry: Ranges from immediately to 20 minutes
- Hard bounces: Never retried by any provider
- Soft bounces: Retried with increasing intervals
- Configuration: Most providers offer limited or no customization
Competitor Comparison Table
| Provider | Max Duration | Retry Attempts | First Retry | Strategy | Configurable |
|---|---|---|---|---|---|
| SendGrid | 72 hours | Until timeout | 1 minute | Exponential (1m, 10m, 1h, 4h) | No |
| Mailgun | 8 hours (default) | Until timeout | 10 minutes | Exponential, increasing intervals | Yes (5min-24h) |
| AWS SES | Not disclosed | Not disclosed | Immediate | Automatic, undisclosed | No |
| Postmark | Until bounce | Multiple | Not disclosed | Progressive backoff | No |
| Resend | Not disclosed | Not disclosed | Not disclosed | Not publicly documented | No |
| SparkPost | 72 hours | ~6 attempts | 20 minutes | Exponential (20m, 40m, 80m, 160m) | No |
| RFC 1123 | - | - | 30 min (minimum) | Exponential recommended | - |
Detailed Competitor Analysis
SendGrid
Retry Duration: Up to 72 hours
Strategy:
- Continues attempting delivery for 72 hours maximum
- Uses geometric backoff schedule for temporary failures (4xx SMTP codes)
- Typical intervals: 1 minute, 10 minutes, 1 hour, 4 hours
- After 72 hours, deferrals convert to blocks
Bounce Handling:
- Hard bounces (5xx): Not retried, immediately added to suppression list
- Soft bounces (4xx): Retried with exponential backoff
- Automatic suppression list management
Best Practices:
- Hard bounce rate should be less than 5%
- Suppression list retention: Configurable (1-3650 days)
Documentation:
Mailgun
Retry Duration: 8 hours (default), customizable
Strategy:
- Re-attempts delivery with increasing intervals
- Default: 8 hours maximum
- Messages expire if not delivered within retry window
Customization:
- Retry window: 5 minutes to 24 hours
- Example: 15-minute window = initial attempt + 1 retry at 10 minutes (2 total attempts)
- Retry schedule remains the same, only window changes
Retry Conditions:
- Only retries for immediate and soft bounces
- Permanent failures (hard bounces) never retried
- Temporary failures due to soft bounces or ESP throttling trigger retries
Event Types:
temporary-fail: Will retryfailed: Permanent failure, no retry
Documentation:
AWS SES (Amazon Simple Email Service)
Retry Duration: Not publicly documented
Strategy:
- Automatic retry for soft bounces over an extended period
- First delivery attempt: Usually within milliseconds
- Exact retry count and intervals: Not disclosed
Retry Behavior:
- Hard bounces: Not retried (except DNS lookup failures)
- Soft bounces: Automatic retry over extended period
- No configuration options available
Configuration:
- ❌ Cannot disable retries
- ❌ Cannot adjust retry count
- ❌ Cannot modify retry intervals
- ❌ Cannot set retry duration
Important:
AWS SES retry mechanism is fully automated and cannot be disabled or configured.
Notifications:
- Bounce notifications sent via email or Amazon SNS
- Notifies when hard bounces occur
- Notifies when soft bounces will no longer be retried
Documentation:
Postmark
Retry Duration: Until soft bounce or undeliverable status
Strategy:
- Makes several attempts for temporary errors
- Ceases attempts when message reaches "Soft Bounce" or "Undeliverable" status
- Different retry policies for outbound vs inbound webhooks
Outbound Email:
- Multiple delivery attempts for errors
- Stops at soft bounce or undeliverable
- Recommendation: Retry couple of times, then treat as hard bounce
Inbound Webhook Retries:
- Total attempts: 10 retries
- Intervals: Growing from 1 minute to 6 hours
- Trigger: Non-200 HTTP status code
- Failure: After 10 failed retries, shows "Inbound Error"
Webhook Retry by Type:
- Bounce & Inbound: 10 retries over several hours (critical events)
- Click, Open, Delivery, Subscription: Shorter retry window (1 min, 5 min, 15 min)
Priority:
- Critical events (bounces, inbound) get aggressive retry
- Engagement events (opens, clicks) are less time-sensitive
Documentation:
Resend
Retry Duration: Not publicly documented (for outbound delivery)
Webhook Retry Policy:
- Schedule: Exponential backoff
- Attempts:
- Immediately
- 5 seconds
- 5 minutes
- 30 minutes
- 2 hours
- 5 hours
- 10 hours
- Total duration: ~10 hours 35 minutes for 3 failed attempts
Bounce Categorization:
- Permanent (hard bounce): Never delivered
- Transient (soft bounce): Could be delivered in future
- Undetermined: Insufficient information in bounce message
Outbound Delivery Retry:
- Not explicitly documented in public documentation
- Assumed to follow industry standard practices
- Contact Resend support for specific details
Documentation:
SparkPost
Retry Duration: 72 hours maximum
Strategy:
- Exponential back-off scheme for delayed queue
- Dynamic process, typically 6 attempts over 72 hours
- Messages expire after 72-hour timeout
Retry Schedule:
- First failure: Delayed queue, retry in 20 minutes
- Second failure: Retry interval doubles to 40 minutes
- Third failure: Retry interval doubles to 80 minutes
- Fourth failure: Retry interval multiplies by 8 to 160 minutes
- Continues until delivered or 72-hour expiration
Adaptive Email Network (AEN):
- Moderates traffic to comply with ISP/server rules
- Detects ISP pushback and bounces
- Automatically "backs off" from receiving endpoints
- Adjusts sending patterns based on feedback
Bounce Classification:
- Bounce Classes 10, 30, 90: Permanent failures, never retried
- Soft Bounce: Temporary error, retried
- Hard Bounce: Invalid address, added to suppression list, never retried
Process:
- Continues retrying until message delivered or expiration reached
- Maximum 72 hours from initial send attempt
- Proprietary algorithm optimizes delivery timing
Documentation:
RFC Standards & Best Practices
RFC 1123 - SMTP Requirements
Minimum Retry Interval:
- MUST delay retrying after failed attempt
- SHOULD wait at least 30 minutes between retries
Recommended Strategy:
- Two connection attempts in first hour
- Back off to once every 2-3 hours thereafter
- More sophisticated strategies encouraged
Industry Best Practices
Exponential Backoff:
Start: 5 minutes
Progressive: 15, 30, 60, 120 minutes, etc.
Rationale:
- Quick recovery: Short initial intervals catch brief outages
- Resource efficiency: Longer intervals reduce wasted resources
- Server health: Avoid hammering struggling servers
- Network optimization: Balance retry attempts against costs
Common Patterns:
- Popular MTAs implement increasing backoff times
- Temporary failures trigger exponential backoff
- Very large messages may get degraded queue priority
References:
Comparison: Retry Strategies
Aggressive Retry (Quick Recovery)
Who: SendGrid (1m first retry)
Pros:
- Fast delivery for brief issues
- Better user experience
- Catches temporary glitches
Cons:
- More server load
- Higher resource usage
- Potential recipient server strain
Moderate Retry (Balanced)
Who: Mailgun (10m first retry), Postmark
Pros:
- Balance between speed and efficiency
- Reasonable resource usage
- Good for most use cases
Cons:
- Slower than aggressive approach
- May miss very brief outages
Conservative Retry (Resource Efficient)
Who: SparkPost (20m first retry)
Pros:
- Minimal server load
- Efficient resource usage
- Respects recipient servers
Cons:
- Slower delivery
- May not catch brief outages
- Longer time to final failure
Key Takeaways for Postchi
Industry Standards
- 72 hours is the gold standard for maximum retry duration
- Exponential backoff is universal across all providers
- Hard bounces are never retried by anyone
- Configuration is rarely offered - most providers use fixed policies
Recommended Approach for Postchi
Suggested Configuration
| Parameter | Value | Reasoning |
|---|---|---|
| Max Duration | 72 hours | Industry standard |
| Total Attempts | 8-10 | Balance between persistence and efficiency |
| First Retry | 5 minutes | Quick recovery for brief issues |
| Backoff Strategy | Exponential | Standard best practice |
| Intervals | 5m, 15m, 30m, 1h, 2h, 4h, 8h, 16h | Balanced progression |
| Hard Bounce | No retry | Universal standard |
| Configurable | Yes (per org tier) | Competitive advantage |
Implementation Considerations
BullMQ Configuration:
{
attempts: 10,
backoff: {
type: 'exponential',
delay: 5 * 60 * 1000, // 5 minutes initial
},
// Remove job after 72 hours
removeOnComplete: {
age: 72 * 60 * 60 // 72 hours in seconds
},
removeOnFail: {
age: 72 * 60 * 60
}
}
Per-Tier Customization:
// Free tier: Aggressive (save costs)
{
maxDuration: 24 * 60 * 60 * 1000, // 24 hours
maxAttempts: 5,
intervals: [5, 15, 30, 60, 120] // minutes
}
// Pro tier: Standard (balanced)
{
maxDuration: 72 * 60 * 60 * 1000, // 72 hours
maxAttempts: 8,
intervals: [5, 15, 30, 60, 120, 240, 480, 960] // minutes
}
// Enterprise: Configurable
{
maxDuration: configurable,
maxAttempts: configurable,
intervals: configurable
}
Conclusion
The email delivery retry landscape shows remarkable consistency:
- 72 hours is the industry standard
- Exponential backoff is universally adopted
- No configuration is the norm (Mailgun is the exception)
- Hard bounces never retry is absolute
For Postchi, adopting these standards with optional per-tier customization would provide:
- Industry-standard reliability
- Competitive differentiation through configuration
- Resource efficiency at scale
- Excellent user experience
References
- SendGrid: Bounce Classifications
- Mailgun: Will Mailgun retry my failed messages?
- AWS SES: Understanding Email Deliverability
- Postmark: Bounce Handling Best Practices
- Resend: Webhook Retries
- SparkPost: How Are Messages Retried?
- RFC 1123: SMTP Requirements