List Hygiene and Sunset Policies

The composition of a mailing list drives the metrics mailbox providers score senders on (see Metrics and Benchmarks). This article covers the full address lifecycle: acquisition, validation at signup, ongoing bounce/complaint handling, and removal of unengaged addresses (sunset).

Acquisition: dos and don'ts

Never rent, buy, or scrape email lists. All three ESP guides agree, for concrete reasons:

• Purchased lists contain large numbers of invalid addresses, spiking hard-bounce rates (AWS SES).
• They contain spam traps — addresses planted specifically to catch illegitimate senders. Landing in one can damage delivery rates and reputation "irrevocably" (AWS SES).
• Scraping/harvesting (bots crawling websites for addresses) is particularly risky because none of the recipients opted in (SendGrid).

Legitimate growth instead: create opportunities for people to provide addresses voluntarily — landing pages that explain what the email program delivers, display ads driving opt-in, explicit documented consent before any sending (SendGrid).

Validation at signup

Practice	Detail	Source
Double opt-in	Send a confirmation link at signup; do not mail the address until it's clicked. Eliminates typo-driven hard bounces and proves intent.	AWS SES, SendGrid
Syntactic + MX validation	On form submission, verify the address is well-formed (recipient@example.com) and the domain has valid MX records.	AWS SES
CAPTCHA on signup forms	Prevents bot signups that poison the list.	SendGrid
Typo/disposable detection	Validate at signup to flag disposable domains and suggest corrections for common typos (e.g., via a validation API).	SendGrid
Reject role/watchdog aliases	Addresses like postmaster@, abuse@, noc@ almost never sign up intentionally; they can be maliciously added as sabotage and are customarily reserved for email watchdogs.	AWS SES
Guard user-generated content	Forum registrations and form submissions can be filled with spammer content; never pass user-defined input into outbound mail unchecked.	AWS SES
Welcome-email validation	Send a welcome email to every new address; automatically remove addresses whose welcome email bounces.	SendGrid

A welcome message also sets expectations — recipients who understand why they're getting mail complain less (see Foundations).

Spam traps

Two categories (SendGrid):

• Pristine traps (honeypots) — addresses that never signed up for anything, planted by ISPs and anti-spam organizations. Only acquirable via purchased/scraped lists.
• Recycled traps — real addresses abandoned by their owners and later repurposed as traps. After roughly 12 months of inactivity, an abandoned address is either turned off completely (producing hard bounces) or converted into a spam trap.

Recycled traps are why engagement-based sunsetting is mandatory even for consent-clean lists: an address that stopped engaging a year ago may now be a trap.

Bounce handling

Rules from AWS SES and Postmark:

• Hard bounce → remove immediately. Never re-send to a hard-bouncing address; repeated hard bounces accumulate and harm reputation with that ISP. Postmark's practice for transactional systems: automatically suspend delivery to the address, requiring explicit reactivation after the underlying problem is fixed.
• Soft bounce → retry, then treat as hard. Sending systems retry soft bounces at intervals over the following days; if an address soft-bounces repeatedly across sends, treat it as hard and suppress it.
• Mailbox-full is usually permanent in practice. SendGrid: only about 8.5% of mailbox-full addresses return to active status within 30 days. Track recurring mailbox-full responses and suppress addresses that consistently show the pattern.
• Receive your bounce notifications reliably. The address collecting bounce/complaint notifications must itself accept mail. Avoid using an ISP-hosted mailbox for this — an influx of bounce notifications can be spam-foldered or dropped; if unavoidable, check the spam folder and never mark bounce messages as spam (AWS SES).
• Make bounces traceable. A bounce identifies the refusing mailbox, but to map it to a campaign, embed an X-header with a value traceable to your internal tracking system (AWS SES).

Operational tactics for transactional bounces (Postmark)

For product/transactional email, a bounce often means a user you can't reach — a product problem, not just a list problem:

1. Halt delivery to the address immediately on hard bounce or spam complaint (protects reputation)
2. Automatically alert the support team to investigate
3. Show an in-app notification to the affected user at login ("we can't reach your email")
4. Log the bounce event on the account record
5. Let the user self-reactivate delivery after correcting their address
6. Fall back to alternative channels (SMS, secondary email) when available
7. Notify account admins/collaborators when a critical user's email bounces
8. Optionally surface auto-responder (out-of-office) replies in collaborative contexts
9. Process bounce webhooks in application code rather than polling
10. Use a sandbox environment for testing so test sends never hit real recipients

Complaint handling

• Keep the complaint rate below 0.1% (see Metrics and Benchmarks for the full threshold table).
• When a recipient complains about a marketing email, immediately stop sending them marketing email. If the program also sends transactional/notification mail, it may be acceptable to continue those message types to that recipient (AWS SES).
• Complaint feedback-loop notifications typically redact the complainer's address; embed custom X-headers or identifiers in the message body so the complaining address can be identified and suppressed (AWS SES).
• Verify complaint notifications aren't themselves being spam-filtered on your side.

Unsubscribe and preference management

• One-click unsubscribe (RFC 8058 List-Unsubscribe) is required by the Google/Yahoo bulk-sender rules and is a CAN-SPAM baseline (SendGrid).
• Put a clear unsubscribe link in the footer; friction breeds complaints instead of unsubscribes.
• Offer a preference center with frequency control and a "down-subscribe" option (fewer emails instead of none) — retains the subscriber while cutting negative signals (SendGrid).

Sunset policies

A sunset policy "reduces the frequency that an email address receives campaigns or suppresses it entirely based on engagement, or lack thereof" (SendGrid). Rationale: unengaged addresses drag down engagement rates, and after ~12 months of inactivity may become hard bounces or recycled spam traps.

A complete sunset workflow combining the sources:

1. Define inactivity by recency of opens/clicks (remembering open-tracking inflation — weight clicks; see Metrics and Benchmarks).
2. Reduce frequency first for cooling segments rather than cutting them off.
3. Validate status out-of-band where possible — website logins, purchase history — before mailing a long-dormant address (AWS SES).
4. Run a re-engagement / win-back campaign as the last step: a message noting you haven't heard from the recipient and asking them to confirm they still want the mail (AWS calls this a win-back; SendGrid a re-engagement campaign — "one last chance").
5. Purge non-responders. After the win-back, remove every recipient who did not respond (AWS SES).
6. If mailing a list that hasn't been contacted in a long time, precede it with a welcome-style message reminding recipients who you are and why they're receiving mail — this reduces complaints (AWS SES).

Sending less to fewer, better recipients typically increases inbox delivery — see Two Worlds of Email Deliverability.

Related

• Metrics and Benchmarks — the thresholds hygiene protects
• Sending Infrastructure Practices — feedback loops that feed the suppression pipeline