Deliverability is a segment decision

On September 1, a kidney-health supplement brand I work with recorded 7,393 email bounces in one day. Its normal range is 10 to 60. That day the brand's domain was suspended over a registration verification, and for about 30 hours its DNS was down, including the records that authenticate its email. A campaign went out during the outage and bounced in bulk.

So the trigger was a domain problem in the plainest sense. But once the domain was back, one large mailbox provider was still refusing some mail six days later. Everything we did about that was a segment decision: who got mail, and what happened after a bounce. When a brand tells me its domain has gone bad, that's where I look first.

Reading a bounce spike

Start with the baseline. 7,393 against a normal 10 to 60 is an event, and you want its cause before you change anything. Here it was the outage.

Then split what is still bouncing. After the restore, bounces settled at 16 to 57 a day. As of September 7, 87% of them (share of bounces, count) came from that one provider, and 98% (share of bounces, count) were soft. A soft bounce means the provider is refusing your mail for now. The address still works. That split told me who to stop mailing for a while, and that nobody needed deleting.

The email platform's deliverability team asked us to suppress everyone who had never engaged. We wrote back with the root cause and a plan to exclude them by segment instead. I only restore suppressed profiles by hand, one person at a time and on evidence. A segment exclusion can be lifted whenever you decide.

Who gets mail during a rebuild

On September 8 I built two segments. The first was everyone who had opened or clicked in 90 days or ordered in 180, which came to 30,788 profiles. For the rebuild, planned at two to three weeks, every bulk campaign went to that segment only, and the daily automated sends were checked against the same rule.

The second was the never-engaged: at least five emails received in 180 days, with no opens and no clicks. That was 8,457 profiles. They were excluded during the rebuild and stay excluded after it.

Small operational sends were exempt, such as failed-payment notices and messages to customers of a product being discontinued. The volume is tiny and they have to arrive.

Privacy features in some mail apps register opens no person made, so an open-based segment is looser than it looks. If the blocks had lasted past two weeks, the plan was to tighten it to clicks and orders only.

A warmup on a new platform is the same decision made in advance, covered in the last issue. A national retailer took 45 days to reach about 9 million emails a day, and an architectural products retailer needed a very conservative schedule after technical problems.

A cooldown in place of suppression

The 7,375 profiles at that provider who had bounced at least once in 14 days got their own segment, excluded from every campaign. That group was roughly the September 1 cohort, due to age out around September 15.

It is a rolling window, so it empties itself. Someone drops out 14 days after their last bounce and can be mailed again, unless they bounce again.

I didn't suppress them because soft bouncers recover as the sender's reputation does. The platform already suppresses repeated hard bounces on its own. My rule: hard bounces get suppressed, soft bounces get a cooldown.

Two welcomes on one list

Four days into the rebuild I audited the account's welcome flows. Both welcome email flows, one live and one in draft, started when someone joined the same list, and that list was the master email list of 143,520 profiles. A new subscriber with no orders qualified for both. If the second flow launched as built, they would get two sequences at once, each with about a day between emails, one standard and one offering 30% off a class. The build spec had called for an exclusion that was never added.

The SMS welcome was live with no filter and fired when anyone joined any list. Of the last 100 list-join events, 88 were the master email list and 8 were back-in-stock lists. Existing customers qualified, people could re-enter on every list join, and quiet hours were off for a US audience mostly over 60. The email welcome screened out anyone with two or more bounces or a spam complaint, while the SMS welcome screened out no one.

Nothing else stopped one person sitting in several flows. The setting that skips a message when someone has had one recently was off on every send I checked. I'd fix the filters first anyway, because that setting skips rather than delays, so a lost send makes no noise.

I recommended fixing the SMS welcome that day, since it was the one sending wrong, then adding an exclusion to the email welcome before the second flow launches and testing it on a seed profile first. A "does not equal" filter on a property most people don't have can behave unexpectedly, and this one sits in front of 143,520 people.

Longer term, give each signup point its own small list and add people to the master list at the end of the flow, so a new welcome doesn't mean editing every existing flow.

Do this Monday

On your own account:

1. Pull daily bounces for the last 90 days and note your normal range. Split any spike by mailbox provider and by hard or soft.
2. Count your never-engaged: five or more emails received in 180 days, no opens, no clicks. Exclude them from campaigns for good.
3. Build an engaged segment (opened or clicked in 90 days, or ordered in 180) and put its size next to your full mailable list.
4. Make a rolling 14-day cooldown for anyone who bounced, and exclude it from campaigns. Leave suppression to hard bounces.
5. Find out who or what sets the audience on every scheduled and automated campaign.
6. List every live welcome flow, email and SMS, with its trigger, and look up the name behind every list ID. A list in a build spec can turn out to be your master list.
7. Check that each welcome excludes past buyers and anyone with bounces or spam complaints, and that SMS quiet hours are on. Then decide on purpose whether the skip-if-recently-sent setting is on, knowing it drops messages silently.

---

In one line: when bounces spike, look at who you've been mailing and what happens after a bounce before you blame the domain.