# List Hygiene and Sunset Policies

> How to acquire addresses safely, validate them at signup, handle bounces and complaints operationally, and sunset unengaged recipients before they hurt reputation.

Source: emailmarketing.net — https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies

The addresses on your list decide the metrics that mailbox providers use to score you (see [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks)). Keeping those metrics healthy means managing each address through its whole life: how you acquire it, how you validate it at signup, how you handle its bounces and complaints, and when you stop mailing it because it no longer engages (sunset).

## Acquisition: dos and don'ts

**Never rent, buy or scrape email lists.** The guides from all three ESPs agree, for concrete reasons:

- Purchased lists contain large numbers of invalid addresses, which make hard bounce rates spike (AWS SES).
- They contain **spam traps**: addresses placed specifically to catch senders who are not legitimate. Hitting one can damage delivery rates and reputation "irrevocably" (AWS SES).
- Scraping or harvesting addresses (bots crawling websites for them) is especially risky, because none of the recipients opted in (SendGrid).

Grow the list legitimately instead. Give people opportunities to provide their address voluntarily: landing pages that explain what the email program offers, display ads that lead to an opt-in, and explicit, documented consent before any sending (SendGrid).

## Validation at signup

| Practice | Detail | Source |
|---|---|---|
| Double opt-in | Send a confirmation link at signup, and do **not** mail the address until it is clicked. This removes hard bounces caused by typos and proves intent. | AWS SES, SendGrid |
| Syntax and MX validation | When the form is submitted, check that the address is well formed (`recipient@example.com`) and that the domain has valid MX records. | AWS SES |
| CAPTCHA on signup forms | Prevents bots from signing up and poisoning the list. | SendGrid |
| Detection of typos and disposable addresses | Validate at signup to flag disposable domains and suggest corrections for common typos (for example, through a validation API). | SendGrid |
| Reject role and watchdog aliases | Addresses such as `postmaster@`, `abuse@` and `noc@` almost never sign up on purpose. They can be added maliciously as sabotage, and by custom they are reserved for people who watch for abuse. | AWS SES |
| Guard content generated by users | Forum registrations and form submissions can be filled with spammers' content. Never put user input into outbound mail without checking it. | AWS SES |
| Validation through the welcome email | Send a welcome email to every new address, and automatically remove addresses whose welcome email bounces. | SendGrid |

A welcome message also sets expectations. Recipients who understand why they are getting mail complain less (see [Foundations](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability)).

## Spam traps

There are two kinds (SendGrid):

- **Pristine traps (honeypots)**: addresses that never signed up for anything, placed by ISPs and anti-spam organizations. You can only get them from purchased or scraped lists.
- **Recycled traps**: real addresses that their owners abandoned and that were later turned into traps. After roughly **12 months** without activity, an abandoned address is either switched off completely (so it produces hard bounces) or converted into a spam trap.

Recycled traps are why a sunset policy based on engagement is necessary, even for lists built entirely on consent. An address that stopped engaging a year ago may now be a trap.

## Bounce handling

These rules come from AWS SES and Postmark:

- **Remove hard bounces immediately.** Never send again to an address that hard-bounces. Repeated hard bounces add up and harm your reputation with that ISP. Postmark's practice for transactional systems is to suspend delivery to the address automatically, and to require someone to reactivate it after the underlying problem is fixed.
- **Retry soft bounces, then treat them as hard.** Sending systems retry soft bounces at intervals over the following days. If an address soft-bounces repeatedly across sends, treat it as a hard bounce and suppress it.
- **A full mailbox is usually permanent in practice.** According to SendGrid, only about **8.5%** of addresses with a full mailbox become active again within 30 days. Track repeated mailbox-full responses, and suppress addresses that show the pattern consistently.
- **Make sure you receive your bounce notifications.** The address that collects bounce and complaint notifications must itself accept mail. Avoid using a mailbox hosted by an ISP for this, because a flood of bounce notifications may be sent to the spam folder or dropped. If you cannot avoid it, check the spam folder, and never mark bounce messages as spam (AWS SES).
- **Make bounces traceable.** A bounce identifies the mailbox that refused the message. To connect it to a campaign, add an X-header with a value your internal tracking system can trace (AWS SES).

### Operational tactics for transactional bounces (Postmark)

For product or transactional email, a bounce often means a user you cannot reach. That is a product problem, not only a list problem:

1. Stop delivery to the address immediately after a hard bounce or a spam complaint (this protects reputation)
2. Alert the support team automatically so they can investigate
3. Show the affected user a notice in the application when they log in ("we can't reach your email")
4. Record the bounce event on the account
5. Let the user reactivate delivery themselves after correcting their address
6. Use other channels (SMS, a secondary email address) when they are available
7. Notify account administrators and collaborators when an important user's email bounces
8. Optionally, show automatic replies (out-of-office messages) where people work together
9. Process bounce webhooks in the application code instead of polling
10. Use a sandbox environment for testing, so that test sends never reach real recipients

## Complaint handling

- Keep the complaint rate below **0.1%** (see [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks) for the full table of thresholds).
- When a recipient complains about a **marketing** email, stop sending them marketing email immediately. If the program also sends **transactional or notification** mail, it may be acceptable to keep sending those types of message to that recipient (AWS SES).
- Complaint notifications from feedback loops usually hide the address of the person who complained. Add custom X-headers or identifiers to the message body, so that you can identify and suppress the address (AWS SES).
- Check that your own systems are not filtering complaint notifications as spam.

## Unsubscribe and preference management

- One-click unsubscribe (RFC 8058 `List-Unsubscribe`) is required by Google's and Yahoo's rules for bulk senders, and it is a basic CAN-SPAM requirement (SendGrid).
- Put a clear unsubscribe link in the footer. When unsubscribing is difficult, people complain instead.
- Offer a **preference center** with control over frequency and a "down-subscribe" option (fewer emails rather than none). It keeps the subscriber while reducing 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). Addresses that do not engage pull down engagement rates, and after ~12 months without activity they may become hard bounces or recycled spam traps.

A complete sunset process, combining the sources:

1. **Define inactivity** by how recently the address opened or clicked. Remember that open tracking is inflated, so give clicks more weight (see [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks)).
2. **Reduce frequency first** for segments that are cooling, rather than cutting them off.
3. **Check the address's status through other channels** where possible, such as website logins or purchase history, before you mail an address that has been dormant for a long time (AWS SES).
4. **Run a re-engagement campaign** as the last step: a message saying you have not heard from the recipient and asking them to confirm they still want the mail. AWS calls this a *win-back* campaign, and SendGrid a *re-engagement campaign*, "one last chance".
5. **Remove the people who do not respond.** After the win-back campaign, remove every recipient who did not respond (AWS SES).
6. If you mail a list that has not been contacted for a long time, send a welcome-style message first, reminding recipients who you are and why they receive your mail. This reduces complaints (AWS SES).

Sending less often to fewer, better recipients usually increases delivery to the inbox (see [Two Worlds of Email Deliverability](https://emailmarketing.net/learn/strategy/two-worlds-of-email-deliverability)).

## Related articles

- [Metrics and Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks), the thresholds that list hygiene protects
- [Sending Infrastructure Practices](https://emailmarketing.net/learn/operations/sending-infrastructure-practices), including the feedback loops that feed suppression