Bounce Handling Reference

Comprehensive bounce code reference, feedback loop setup per provider, suppression list architecture, and list hygiene automation patterns.

---

1. SMTP bounce code reference

Status code structure

SMTP enhanced status codes follow the format X.Y.Z:

• X = class (2=success, 4=temporary failure, 5=permanent failure)
• Y = subject (0=other, 1=address, 2=mailbox, 3=mail system, 4=network, 5=protocol, 7=security)
• Z = detail (specific to subject)

Hard bounces (5xx) - remove immediately

Code	Meaning	Action
550 5.1.1	User unknown / mailbox does not exist	Remove from list permanently
550 5.1.2	Bad destination domain	Remove - domain is invalid
550 5.1.3	Bad destination mailbox syntax	Remove - address is malformed
550 5.1.10	Null MX - domain does not accept mail	Remove permanently
551 5.7.1	Message rejected - policy (spam, blocklist)	Investigate; may need IP/domain cleanup
552 5.2.2	Mailbox full (some providers treat as permanent)	Suppress after 3 occurrences
553 5.1.3	Mailbox name invalid	Remove - address format is wrong
554 5.7.1	Blocked by recipient policy	Check blocklists, content, and reputation
556 5.1.10	Domain has null MX	Remove permanently

Soft bounces (4xx) - retry then suppress

Code	Meaning	Action
421 4.7.0	Connection rate limited / too many connections	Back off, retry in 30 min
450 4.2.1	Mailbox temporarily unavailable	Retry 3x over 72h
451 4.3.0	Mail system temporarily unavailable	Retry 3x over 72h
451 4.7.1	Greylisting - try again later	Retry after 5-15 minutes
452 4.2.2	Mailbox full (temporary)	Retry 3x over 72h, suppress if persistent
452 4.5.3	Too many recipients in one message	Reduce batch size
421 4.7.28	Gmail rate limit exceeded	Back off for 1h, reduce volume

Block bounces - investigate immediately

Pattern	Likely cause	Action
"blocked" or "blacklisted" in response	IP on a blocklist	Check Spamhaus, Barracuda, Spamcop
"poor reputation"	Domain or IP reputation is low	Check Google Postmaster Tools, SNDS
"too many complaints"	Complaint rate exceeded provider threshold	Review FBL data, clean list
"authentication required" or "SPF fail"	SPF/DKIM not configured for this IP	Fix authentication records
"DMARC policy"	Message fails DMARC and policy is reject/quarantine	Fix SPF/DKIM alignment

---

2. Bounce processing architecture

Processing pipeline

Incoming bounce
    |
    v
Parse DSN (Delivery Status Notification)
    |
    v
Extract: recipient, status code, diagnostic message
    |
    v
Classify: hard bounce / soft bounce / block / complaint
    |
    +-- Hard bounce --> Add to suppression list immediately
    |
    +-- Soft bounce --> Increment retry counter
    |       |
    |       +-- Retries < 3 --> Schedule retry (exponential backoff)
    |       |
    |       +-- Retries >= 3 --> Add to suppression list
    |
    +-- Block bounce --> Alert ops team, check blocklists
    |
    +-- Complaint --> Add to suppression list, flag for analysis

DSN (Delivery Status Notification) parsing

Bounce messages arrive as DSNs (RFC 3464). Key fields to extract:

Content-Type: multipart/report; report-type=delivery-status

--boundary
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.com
Final-Recipient: rfc822; user@recipient.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 The email account does not exist

Fields to extract:

• Final-Recipient - the address that bounced
• Status - the enhanced status code (X.Y.Z)
• Action - failed (hard), delayed (soft), delivered, relayed
• Diagnostic-Code - the full SMTP response from the receiving server

Retry strategy for soft bounces

Use exponential backoff with jitter:

Attempt	Wait time	Notes
1st retry	30 minutes	May resolve greylisting
2nd retry	4 hours	Server outage may resolve
3rd retry	24 hours	Mailbox full may clear
After 3rd	Suppress	Add to soft-bounce suppression (re-evaluate in 30 days)

Add random jitter of +/- 20% to avoid thundering herd when many bounces resolve simultaneously.

---

3. Feedback loops (FBL)

Feedback loops deliver complaint notifications when a recipient marks your email as spam. Processing FBLs is critical for maintaining reputation.

FBL setup by provider

Provider	FBL type	Setup URL	Format
Yahoo/AOL	Traditional FBL	https://senders.yahooinc.com/complaint-feedback-loop	ARF (RFC 5965)
Outlook/Hotmail	JMRP (Junk Mail Reporting Program)	https://sendersupport.olc.protection.outlook.com/snds/JMRP.aspx	ARF
Gmail	Postmaster Tools only	https://postmaster.google.com	Dashboard (no individual complaints)
Comcast	Traditional FBL	https://postmaster.comcast.net/feedback-loop.html	ARF
Apple (iCloud)	None publicly available	N/A	N/A

Gmail does not send individual complaint reports. Use Google Postmaster Tools to monitor aggregate spam rates. This makes Gmail the hardest to diagnose at the individual-message level.

ARF (Abuse Reporting Format) parsing

FBL complaints arrive as ARF messages (RFC 5965):

Content-Type: multipart/report; report-type=feedback-report

--boundary
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: Yahoo!-Mail-Feedback/2.0
Version: 1
Original-Mail-From: bounce@example.com
Arrival-Date: Mon, 14 Mar 2026 10:00:00 -0700
Source-IP: 203.0.113.5

Fields to extract:

• Feedback-Type - usually abuse (spam complaint)
• Original-Mail-From - your bounce/envelope sender
• Source-IP - your sending IP
• The third MIME part contains the original message (extract recipient address)

FBL processing rules

1. Immediately add the complainant to your suppression list
2. Never send to a complainant again - ever (not even transactional)
3. Track complaint rates per campaign, list segment, and sending IP
4. If complaint rate exceeds 0.1% for any segment, investigate:
   • Was the list source legitimate (opt-in)?
   • Was the content misleading or unexpected?
   • Was the frequency too high?
5. Use List-Unsubscribe headers (RFC 8058) to give users an easy alternative to the spam button

---

4. Suppression list management

Suppression list types

List	Contains	Source	Duration
Hard bounce	Permanently invalid addresses	Bounce processing	Permanent
Complaint	Users who reported spam	FBL processing	Permanent
Unsubscribe	Users who opted out	Unsubscribe handler	Permanent (per CAN-SPAM/GDPR)
Soft bounce	Temporarily failing addresses	Bounce processing	30 days (then re-evaluate)
Role-based	Generic addresses (info@, admin@)	List hygiene scan	Permanent unless explicitly opted in
Spam trap	Known spam trap addresses	Third-party hygiene services	Permanent

Suppression list architecture

Requirements for a production suppression system:

1. Global scope - suppression list applies across ALL sending streams, campaigns, and systems. A complaint on marketing mail must suppress transactional mail too.
2. Check before every send - every outgoing message must be checked against the suppression list before transmission. No exceptions.
3. Immutable hard entries - hard bounces, complaints, and unsubscribes must never be removed without explicit human review and re-confirmation from the recipient.
4. Audit trail - log when each entry was added, why (bounce code, complaint, unsubscribe), and from which campaign.
5. Import/export - support bulk import from ESP migration and bulk export for compliance requests (GDPR right to access).

Implementation pattern

Suppression Check Flow:

Before sending to recipient@example.com:
  1. Normalize email: lowercase, trim whitespace
  2. Check suppression table:
     SELECT reason, added_at FROM suppression
     WHERE email_hash = SHA256('recipient@example.com')
  3. If found -> skip send, log suppression hit
  4. If not found -> proceed with send

On bounce/complaint:
  1. Normalize email
  2. INSERT INTO suppression (email_hash, reason, source_campaign, added_at)
  3. Log event for analytics

Store email hashes, not plaintext addresses, in the suppression table. This reduces PII exposure. Use a consistent hash function (SHA-256) across all systems.

---

5. List hygiene automation

Automated hygiene schedule

Task	Frequency	Method
Process bounces	Real-time	Automated bounce handler
Process FBL complaints	Real-time	Automated FBL parser
Remove hard bounces	Real-time	Automated on receipt
Re-verify soft bounces	Every 30 days	Re-send or verify via API
Sunset inactive subscribers	Every 90 days	Auto-suppress if no engagement in 90-180 days
Full list verification	Quarterly	Third-party verification service
Spam trap scan	Quarterly	Third-party hygiene service

Sunset policy

A sunset policy automatically suppresses subscribers who have not engaged within a defined window. This is the single most impactful list hygiene measure.

Recommended sunset thresholds:

Engagement window	Action
No open/click in 90 days	Move to re-engagement segment
No open/click in 180 days	Send final re-engagement campaign
No response to re-engagement	Suppress permanently

Re-engagement campaign template

Before suppressing inactive subscribers, send a re-engagement sequence:

1. Email 1 (Day 0): "We miss you" - offer value or incentive to re-engage
2. Email 2 (Day 7): "Last chance" - clear statement that they will be removed
3. No response after Day 14: Add to suppression list

Only subscribers who open or click in the re-engagement sequence should remain on the active list. Passive opens (image proxy pre-fetching) do not count as genuine engagement - track click-throughs for reliable signal.

Email verification services

For bulk list cleaning, use a verification service before any large send:

Service	What it checks
ZeroBounce	Validity, spam traps, abuse emails, catch-all detection
NeverBounce	Real-time and bulk verification, deliverability scoring
BriteVerify	Syntax, domain, mailbox verification
Kickbox	Deliverability, risk scoring, disposable email detection

Run verification on:

• Any list that has not been mailed in 90+ days
• Lists from acquisitions or migrations
• Before a warm-up campaign
• After any deliverability incident

SPF, DKIM, and DMARC Reference

Deep-dive reference for email authentication protocols. Covers full DNS record syntax, alignment modes, common failure patterns, and troubleshooting steps.

---

1. SPF - Sender Policy Framework

Record syntax

v=spf1 [mechanisms] [qualifier]all

Mechanisms (evaluated left to right, first match wins):

Mechanism	Syntax	DNS lookups	Purpose
include	include:_spf.google.com	1+ (recursive)	Authorize another domain's SPF
ip4	ip4:203.0.113.0/24	0	Authorize an IPv4 address or range
ip6	ip6:2001:db8::/32	0	Authorize an IPv6 address or range
a	a:mail.example.com	1	Authorize IPs that the A record resolves to
mx	mx	1 per MX record	Authorize IPs of the domain's MX records
exists	exists:%{i}._spf.example.com	1	Advanced macro-based check
redirect	redirect=_spf.example.com	1	Delegate entire SPF policy to another domain

Qualifiers:

Qualifier	Meaning	Use when
+ (default)	Pass	Mechanism matches, authorize
-	Hard fail	Use with all in production: -all
~	Soft fail	Use with all during testing: ~all
?	Neutral	Rarely useful, avoid

The 10-lookup limit

SPF processing must not exceed 10 DNS lookups. Exceeding this causes a permerror and SPF fails for all messages.

What counts as a lookup:

• Each include: = 1 lookup + recursive lookups inside the included record
• Each a: = 1 lookup
• Each mx: = 1 lookup + 1 per MX record returned
• Each redirect= = 1 lookup
• Each exists: = 1 lookup
• ip4: and ip6: = 0 lookups (no DNS query needed)

How to count your lookups:

# Check your SPF record
dig TXT example.com +short | grep spf

# Use an online tool to count recursive lookups
# dmarcian.com/spf-survey or mxtoolbox.com/spf.aspx

SPF flattening resolves all include: mechanisms to their underlying IP addresses at publish time, replacing DNS lookups with ip4:/ip6: entries. This reduces lookup count but requires re-flattening when ESPs change their IPs. Automate flattening with a cron job or use a service like AutoSPF.

Common SPF errors

Error	Cause	Fix
permerror	> 10 lookups or syntax error	Flatten includes or remove unused mechanisms
temperror	DNS timeout during lookup	Check DNS server health, reduce lookup count
Multiple SPF records	Two TXT records starting with v=spf1	Merge into one record
Too long (> 450 chars)	Record exceeds practical TXT limit	Split into include: sub-records or flatten

Subdomain SPF

SPF is evaluated per envelope sender (Return-Path) domain. If you send from news@marketing.example.com, the SPF record at marketing.example.com is checked, not example.com. Publish SPF records on every subdomain you send from.

For subdomains you do NOT send from, publish a restrictive SPF to prevent spoofing:

nosend.example.com.  IN  TXT  "v=spf1 -all"

---

2. DKIM - DomainKeys Identified Mail

How DKIM works

1. Sending server computes a hash of specified headers + body
2. Hash is signed with a private key
3. Signature is added as the DKIM-Signature header
4. Receiving server fetches the public key from DNS and verifies the signature

DKIM-Signature header anatomy

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1;
  h=from:to:subject:date:message-id;
  bh=base64_body_hash;
  b=base64_signature

Tag	Meaning	Notes
v=	Version	Always 1
a=	Algorithm	rsa-sha256 (required), ed25519-sha256 (emerging)
c=	Canonicalization	relaxed/relaxed recommended (header/body)
d=	Signing domain	Must align with From domain for DMARC
s=	Selector	Identifies which key to fetch from DNS
h=	Signed headers	Must include from; recommended: to, subject, date, message-id
bh=	Body hash	Base64-encoded hash of the canonicalized body
b=	Signature	Base64-encoded signature of the header hash
l=	Body length	AVOID - allows appending content to signed messages

DNS record format

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

Tag	Meaning	Notes
v=	Version	DKIM1
k=	Key type	rsa (default) or ed25519
p=	Public key	Base64-encoded; empty p= revokes the key
t=	Flags	t=s restricts to exact domain (no subdomains); t=y testing mode

Key management best practices

• Use 2048-bit RSA keys minimum (1024-bit is cryptographically weak)
• Use a unique selector per sending service (e.g., sg1 for SendGrid, gm1 for Gmail)
• Rotate keys annually with zero-downtime process:
  1. Generate new key pair with a new selector name
  2. Publish new public key in DNS
  3. Wait 48-72 hours for DNS propagation
  4. Switch signing to the new key
  5. Keep old public key in DNS for 7 days (inflight messages)
  6. Remove old public key from DNS

DKIM troubleshooting

Symptom	Likely cause	Fix
dkim=fail in headers	Key mismatch or body modified in transit	Verify public key matches private key; check for content rewriting (mailing lists, AV scanners)
dkim=temperror	DNS lookup for key failed	Check DNS propagation of the DKIM TXT record
Key not found	Wrong selector or DNS not propagated	Verify dig TXT selector._domainkey.example.com returns the key
Signature covers wrong domain	d= in signature doesn't match From domain	Configure ESP to sign with your domain, not theirs

---

3. DMARC - Domain-based Message Authentication, Reporting, and Conformance

How DMARC works

DMARC validates that at least one of SPF or DKIM passes AND aligns with the From header domain. "Alignment" means the domain in the From header matches the domain authenticated by SPF (envelope sender) or DKIM (d= tag).

Message passes DMARC if:
  (SPF passes AND SPF aligns with From domain)
  OR
  (DKIM passes AND DKIM d= aligns with From domain)

DMARC record syntax

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s; pct=100; ri=86400; fo=1"

Tag	Values	Default	Purpose
v=	DMARC1	required	Version identifier
p=	none, quarantine, reject	required	Policy for the domain
sp=	none, quarantine, reject	inherits p=	Policy for subdomains
rua=	mailto: URI	none	Aggregate report destination
ruf=	mailto: URI	none	Forensic report destination
adkim=	r (relaxed), s (strict)	r	DKIM alignment mode
aspf=	r (relaxed), s (strict)	r	SPF alignment mode
pct=	0-100	100	Percentage of messages to apply policy to
ri=	seconds	86400	Aggregate report interval
fo=	0, 1, d, s	0	Forensic report options

Alignment modes explained

Relaxed alignment (adkim=r, aspf=r):

• Organizational domain must match (e.g., mail.example.com aligns with example.com)
• Recommended during initial deployment

Strict alignment (adkim=s, aspf=s):

• Exact domain match required (e.g., mail.example.com does NOT align with example.com)
• Recommended for production after confirming all senders align

DMARC deployment roadmap

Phase 1 - Monitor (weeks 1-4):

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

• Collect reports, identify all legitimate sending sources
• Use a DMARC report analyzer (dmarcian, Valimail, Postmark) to parse XML reports

Phase 2 - Quarantine (weeks 5-8):

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"

• Start at 25%, increase to 50%, then 100% over 3-4 weeks
• Monitor reports for legitimate mail being quarantined

Phase 3 - Reject (week 9+):

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

• Full enforcement with strict alignment
• Continue monitoring reports permanently

DMARC aggregate report structure

Reports are XML files sent daily. Key fields:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range><begin>1234567890</begin><end>1234654290</end></date_range>
  </report_metadata>
  <record>
    <row>
      <source_ip>203.0.113.5</source_ip>
      <count>150</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result></dkim>
      <spf><domain>bounce.example.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

---

4. BIMI - Brand Indicators for Message Identification

BIMI displays your brand logo next to authenticated emails in supported mailbox providers (Gmail, Yahoo, Apple Mail).

Prerequisites

• DMARC policy must be p=quarantine or p=reject (not none)
• A Verified Mark Certificate (VMC) from a certificate authority (DigiCert, Entrust)
• Logo in SVG Tiny PS format

DNS record

default._bimi.example.com.  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

Tag	Purpose
l=	URL to SVG Tiny PS logo file (HTTPS required)
a=	URL to VMC certificate in PEM format

BIMI is a reward for doing authentication right. It requires DMARC at enforcement level, which means SPF and DKIM must already be solid.

---

5. Verifying authentication from email headers

When troubleshooting, check the Authentication-Results header in a received message:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com header.s=selector1;
  spf=pass (google.com: domain of bounce@example.com designates 203.0.113.5 as permitted sender) smtp.mailfrom=bounce@example.com;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

What to look for:

• dkim=pass with correct header.i= domain
• spf=pass with correct smtp.mailfrom= domain
• dmarc=pass with expected policy
• If any show fail, check the specific domain and IP in the result

Quick diagnostic commands:

# Check SPF record
dig TXT example.com +short | grep spf

# Check DKIM public key
dig TXT selector1._domainkey.example.com +short

# Check DMARC record
dig TXT _dmarc.example.com +short

# Check BIMI record
dig TXT default._bimi.example.com +short

# Test with a real message - send to a Gmail account and view
# "Show Original" to see full Authentication-Results header

Warm-up and Reputation Reference

Detailed warm-up schedules for different volume tiers, reputation monitoring playbooks, and blocklist delisting procedures.

---

1. IP warm-up schedules

Why warm-up matters

Mailbox providers track sender reputation per IP and per domain. A new IP has zero history - providers treat it as suspicious by default. Warm-up builds a track record of legitimate sending behavior. Skipping warm-up is the most common cause of deliverability failure for new senders.

Low volume (target: < 25K emails/day)

Day	Daily volume	Notes
1-3	50	Most engaged recipients only (opened in last 14 days)
4-7	100-200	Expand to opened in last 30 days
8-14	500-1,000	Expand to opened in last 60 days
15-21	2,000-5,000	Expand to opened in last 90 days
22-28	10,000-25,000	Full active list

Medium volume (target: 25K-100K emails/day)

Day	Daily volume	Notes
1-3	100	Most engaged only
4-7	500	Opened in last 30 days
8-14	2,000-5,000	Opened in last 60 days
15-21	10,000-25,000	Opened in last 90 days
22-35	25,000-100,000	Gradually include full list

High volume (target: 100K+ emails/day)

Day	Daily volume	Notes
1-3	200	Most engaged only
4-7	1,000-2,000	Opened in last 30 days
8-14	5,000-15,000	Opened in last 60 days
15-28	15,000-75,000	Opened in last 90 days
29-42	75,000-250,000+	Full list, increase 25-50% per day

High-volume senders should warm up over 6 weeks, not 4. The stakes are higher and recovery from a failed warm-up takes longer.

Warm-up rules (all tiers)

1. Start with your most engaged recipients - high open rates prove to providers that people want your mail
2. Send at consistent times - same time each day, same days each week
3. Do not skip days - gaps in sending reset the trust you have built
4. Monitor daily:
   • Hard bounce rate must stay under 2%
   • Complaint rate must stay under 0.1%
   • If either threshold is exceeded, pause for 24h, clean list, resume at the previous day's volume
5. Separate streams - warm up transactional and marketing IPs independently
6. Avoid weekends initially - some providers have stricter weekend filtering

Domain warm-up

Domain reputation is increasingly more important than IP reputation (especially for Gmail). When warming a new sending domain:

• The domain warm-up schedule mirrors the IP warm-up schedule above
• Subdomains inherit partial reputation from the parent domain
• Use subdomains to isolate streams: transactional.example.com, marketing.example.com, notifications.example.com
• Each subdomain needs its own SPF, DKIM, and DMARC configuration

---

2. Reputation monitoring

Provider-specific tools

Google Postmaster Tools (Gmail):

• URL: https://postmaster.google.com
• Shows: domain reputation (High/Medium/Low/Bad), spam rate, authentication results, encryption percentage, delivery errors
• Requires DNS TXT verification of domain ownership
• Data appears only for domains sending > ~200 messages/day to Gmail
• Domain reputation levels:
  • High: good standing, mail delivered to inbox
  • Medium: some filtering, watch for decline
  • Low: significant filtering, investigate immediately
  • Bad: most mail going to spam, urgent action needed

Microsoft SNDS (Outlook/Hotmail):

• URL: https://sendersupport.olc.protection.outlook.com/snds/
• Shows: IP reputation (Green/Yellow/Red), complaint rate, spam trap hits
• Requires IP ownership verification
• Data is per-IP, not per-domain

Sender Score (Validity):

• URL: https://senderscore.org
• Third-party IP reputation score from 0-100
• Score > 80: good, 70-80: needs attention, < 70: deliverability problems

Key metrics dashboard

Track these metrics per sending IP and per sending domain:

Metric	Source	Frequency	Healthy	Action trigger
Bounce rate	Your MTA logs	Per send	< 1%	> 2% pause and clean
Complaint rate	FBL reports / Postmaster Tools	Daily	< 0.05%	> 0.1% investigate
Spam trap hits	Blocklist monitors	Daily	0	Any hit: investigate source
Inbox placement	Seed list testing	Weekly	> 95%	< 85% full audit
Domain reputation	Google Postmaster Tools	Daily	High	Medium or below: investigate
IP reputation	Microsoft SNDS	Daily	Green	Yellow: watch; Red: act
Authentication rate	DMARC aggregate reports	Daily	> 99% pass	< 95%: fix auth config

Engagement metrics that affect reputation

Mailbox providers (especially Gmail) use engagement signals to determine inbox placement:

Signal	Positive	Negative
Opens	High open rate (> 20%)	Low open rate (< 5%)
Clicks	Users click links	No engagement
Replies	Users reply to your emails	Never any replies
Move to inbox	Users move from spam to inbox	Users never rescue from spam
Mark as spam	Rare (< 0.05%)	Frequent (> 0.1%)
Delete without reading	Rare	Frequent (suggests unwanted mail)

---

3. Reputation recovery

When reputation is damaged

Signs of reputation damage:

• Google Postmaster Tools shows "Low" or "Bad" domain reputation
• Inbox placement drops below 85%
• Bounce rates spike above 5%
• You appear on one or more blocklists

Recovery playbook

Step 1 - Stop the bleeding (Day 1):

• Reduce sending volume to 10% of normal
• Send only to your most engaged segment (opened in last 14 days)
• Verify all authentication (SPF, DKIM, DMARC) is passing

Step 2 - Clean your list (Days 2-3):

• Remove all hard bounces permanently
• Suppress addresses that have not engaged in 180+ days
• Run your list through an email verification service (ZeroBounce, NeverBounce, BriteVerify) to catch invalid addresses and known spam traps
• Remove role-based addresses (info@, admin@, support@) unless they opted in

Step 3 - Identify root cause (Days 3-5):

• Review DMARC aggregate reports for authentication failures
• Check if a specific campaign or list segment caused the spike
• Look for spam trap sources (often purchased lists or scraped addresses)
• Review recent content changes that might trigger content filters

Step 4 - Rebuild (Weeks 2-6):

• Follow the warm-up schedule as if starting from scratch
• Send only to engaged recipients for the first 2 weeks
• Gradually expand to the full (cleaned) list
• Monitor daily - if metrics degrade, reduce volume again

Step 5 - Prevent recurrence:

• Implement double opt-in for all new subscribers
• Add sunset policies: auto-suppress after 90 days of no engagement
• Set up automated alerts on bounce rate, complaint rate, and reputation score
• Schedule quarterly list hygiene reviews

---

4. Blocklist handling

Major blocklists

Blocklist	Impact	Check URL
Spamhaus SBL	Severe - widely used by enterprise receivers	https://check.spamhaus.org
Spamhaus XBL	Severe - compromised hosts / botnets	https://check.spamhaus.org
Barracuda BRBL	Moderate - used by Barracuda appliance users	http://www.barracudacentral.org/lookups
SURBL	Moderate - domain-based (checks URLs in email body)	https://surbl.org/surbl-analysis
Spamcop	Moderate - complaint-driven	https://www.spamcop.net/bl.shtml
UCE Protect	Low-Moderate	https://www.uceprotect.net/en/

Delisting procedures

General process:

1. Identify which blocklist you are on (use MXToolbox Blacklist Check)
2. Fix the underlying cause FIRST (sending to traps, compromised server, etc.)
3. Submit a delisting request through the blocklist's self-service portal
4. Wait - processing time varies from hours to days
5. Monitor to ensure you do not get relisted

Spamhaus delisting:

• Self-service removal: https://check.spamhaus.org (lookup your IP, follow removal link)
• Fix the issue first - Spamhaus will relist immediately if the problem persists
• SBL listings require explanation of what happened and what you changed
• XBL listings are usually automatic (compromised host) - secure the server first

Barracuda delisting:

• Self-service: http://www.barracudacentral.org/lookups/lookup-reputation
• Requires that your IP has no negative activity for 12+ hours before requesting
• Generally processes within 12-24 hours

Preventing blocklisting

• Never send to purchased or scraped lists (spam traps are embedded)
• Process hard bounces immediately (repeated hits to dead addresses flag you)
• Honor unsubscribe requests within 24 hours (not the 10-day CAN-SPAM maximum)
• Monitor for compromised accounts sending spam through your infrastructure
• Use feedback loops to catch complaint spikes early
• Implement rate limiting to prevent abuse if your system allows user-generated email

---

5. Dedicated vs shared IP strategy

Factor	Shared IP	Dedicated IP
Volume threshold	< 50K emails/month	> 50K emails/month
Reputation control	Shared with other senders	Fully in your control
Warm-up required	No (pre-warmed by ESP)	Yes (must warm up yourself)
Cost	Lower (included in ESP plan)	Higher (additional IP cost)
Risk	Neighbor's bad behavior affects you	Only your behavior matters
Best for	Small senders, startups	High-volume or reputation-sensitive senders

When to move to a dedicated IP:

• Volume exceeds 50K emails/month consistently
• You need full control over sender reputation
• Your industry has strict deliverability requirements (finance, healthcare)
• You are experiencing deliverability issues on shared IPs despite good practices

Multiple dedicated IPs:

• Separate transactional mail (receipts, password resets) from marketing
• Consider separate IPs per mail stream if volume justifies it
• Each IP needs its own warm-up schedule
• PTR records must be configured for each IP (reverse DNS)