Bounces and complaints

A permanent bounce and a spam complaint both stop an address being mailed, and they stop it in different places. A permanent bounce suppresses the address across the whole of Issue Mint, because a dead mailbox is dead for every publisher. A complaint suppresses it for your newsletter only, because somebody who marked you as spam may genuinely want somebody else’s newsletter.

What a permanent bounce does

A permanent bounce means the mailbox does not exist, so the subscriber moves to Bounced, stops being mailable, and the address goes onto the platform suppression list.

All of that happens on the event, within seconds of the report arriving, and there is nothing for you to do about it. The address stays on your list with its status showing rather than vanishing, so you can see what happened and when. Undeliverable addresses covers what your list looks like afterwards.

Why a transient bounce changes nothing

A transient bounce is a full mailbox, a server having a bad afternoon or a temporary refusal, and Issue Mint does nothing with it.

Only permanent failures suppress an address. A subscriber whose mailbox was full stays active and gets the next issue, and a transient bounce is not counted towards the hard bounce rate that pauses sending. A mailbox that is full today may be fine tomorrow, and dropping subscribers on a temporary failure is how a list quietly shrinks for no reason.

What a complaint does

A complaint means a reader pressed the spam button, so the subscriber moves to Complained and the address is suppressed for the newsletter it was aimed at.

A complaint is a fact about a relationship rather than about a mailbox, which is why it stops where it does. It also outranks a bounce and is never walked back: the resubscribe button on the unsubscribe page will not undo it, a signup form will not undo it, and re-importing the address will not resurrect it.

The suppression split, and why it is not symmetrical

Bounces are suppressed platform-wide; complaints are suppressed per publisher.

Mailing a dead address from a different newsletter damages the shared sending reputation exactly as much as mailing it from the first one, so a permanent bounce recorded anywhere on Issue Mint stops everybody. A complaint says only that this reader does not want this publication, so stopping every other publisher on the strength of it would be us overreaching.

The list is consulted on the way in as well as on the way out. Adding a suppressed address by hand is refused with a message saying it has previously hard-bounced or reported spam, and it deliberately does not say which of the two, because a platform-wide suppression may have been recorded by a different publisher entirely and which one is not your business. Complaints do still count towards the risk score on a large import, wherever they were recorded, because that question is about the list you are uploading rather than about permission.

An address suppressed during a send

An address suppressed while a send is still running is skipped rather than mailed.

The commonest case is the sharpest one: a reader receives the issue at 09:01 and reports it as spam while the rest of a five thousand address send is still queued. Issue Mint reads the suppression list once for each batch of 200 addresses, so at most one batch’s worth of messages can go out after a complaint lands, and the next issue’s list excludes them from the start.

A skipped address is not a failure and is not treated as one. It is left out of the issue’s recipient count, out of the monthly hosted allowance and out of the daily ceiling, on the principle that a suppressed address is not a recipient of that issue. That is why a send can finish a few short of your active count with nothing wrong.

When bounces and complaints pause your sending

Hosted sending pauses when your complaint rate reaches 0.1 per cent or your hard bounce rate reaches 5 per cent, with warnings earlier at 0.05 per cent and 2 per cent.

Rates are not calculated at all until an issue has reached 500 delivered addresses, because a percentage of twenty people is noise. The rates are reassessed on each event rather than overnight, because Amazon is watching the same numbers and does not wait for our timetable. A pause stops the send between batches, never mid-message, and nothing releases it on a timer: a person here does that, which when sending is paused explains. These thresholds apply to hosted sending only. On your own sending account the reputation is yours, so the decisions are too, and only the suppression list still applies.

One thing that looks like a bounce is not treated as one. A message your provider accepts and then refuses to send, which usually means it objected to something in the content, is recorded as a failure rather than as a bounce, because it is your content being refused rather than a mailbox rejecting you. Counting it as a bounce would push an account towards a pause over something that says nothing about its list.

What an SMTP send never reports

Bounces and complaints from a send through your own SMTP server never reach Issue Mint at all.

SMTP tells us that the server accepted the message and nothing after that, so those sends cannot clean your list and cannot add anything to the suppression list. On Amazon SES, ours or your own, Issue Mint sets up the notification topic and event destination for you, so bounce and complaint reports arrive without you configuring anything. It is the main reason the sending page treats SES and SMTP as different propositions rather than two ways of doing the same thing.