Email Delivery Failure Recovery: Diagnosing and Fixing Failed Sends

Quick Answer

Email delivery failures fall into three categories: permanent failures (suppress and move on), temporary failures (retry automatically — most resolve within 24h), and policy failures (your domain is being filtered or blocked — requires active investigation). Diagnosing the type before acting prevents wasted sends and further reputation damage.

Permanent failures — SMTP 5xx codes

Address does not exist, has been disabled, or the receiving server has permanently rejected your sends.

• 550 5.1.1 — Mailbox does not exist
• 550 5.7.1 — Message rejected due to sender policy
• 554 5.7.0 — Message rejected — policy reason

Recovery: Suppress the address. Do not retry. No further action on the individual address. See bounce suppression handling.

Temporary failures — SMTP 4xx codes

Transient — receiving server temporarily unavailable, mailbox full, message deferred.

• 421 4.7.0 — Service temporarily unavailable
• 450 4.2.1 — Mailbox temporarily unavailable
• 451 4.7.650 — Deferred due to policy (common Gmail response)

Recovery: Retry with exponential backoff. NexusProMail handles this automatically. If 3+ consecutive soft bounces on same address, suppress it.

Policy failures — reputation-based rejections

Rejections based on your sending domain or IP reputation, not the recipient address. More serious — requires investigation.

Step 1 — Verify authentication records

dig TXT yourdomain.com | grep spf
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com

Any authentication failure = fix before investigating further. See DMARC troubleshooting guide.

Step 2 — Check blacklists

# Check Spamhaus
dig yourdomain.com.zen.spamhaus.org
# NXDOMAIN = not listed (good)
# Any other response = listed

If listed, identify root cause (compromised account, spam operation, purchased list) and submit delisting request after fixing it.

Step 3 — Check Google Postmaster Tools

For Gmail-concentrated failures, Postmaster Tools shows domain reputation (High/Medium/Low/Bad) and spam rate. Reputation dropping on a specific date = correlate with that day's send. What segment was used?

Recovery by failure type

Authentication failure

1. Fix broken DNS record
2. Verify with dig (allow 48h propagation)
3. Check Authentication-Results header in a test email
4. Resume sending once passes consistently

Reputation damage

1. Stop sending immediately
2. Fix root cause (list quality, authentication, complaint source)
3. Identify highest-engagement segment (opened in last 30 days)
4. Resume at 200-500/day to engaged contacts only
5. Increase volume weekly — treat as domain re-warming
6. Monitor Postmaster Tools and bounce/complaint rates daily

Blacklist delisting

1. Fix root cause of the listing
2. Submit delisting request to the blacklist operator
3. Wait for removal (Spamhaus CBL typically within 24h)
4. Verify removal, then resume at reduced volume

Prevention

• Automate hard bounce suppression — see bounce suppression handling
• Monitor complaint rates after every send — above 0.08% requires investigation before next send
• Use double opt-in for all new sign-ups
• Set up Google Postmaster Tools for early reputation warning

For ongoing monitoring setup, see how to monitor email deliverability. For domain warming context after recovery, see domain warming guide.