> ## Documentation Index > Fetch the complete documentation index at: https://docs.politicalcomms.com/llms.txt > Use this file to discover all available pages before exploring further. # Bounces, complaints, and suppressions > What happens when a message bounces or is marked as spam, how unsubscribes are recorded, and how suppression keeps an address from being mailed again. Every mailbox provider judges you on the same two numbers: how many of your messages bounce, and how many people mark them as spam. Both are handled for you here, and the handling is deliberately conservative, because the cost of mailing an address you should not have mailed is much higher than the cost of skipping one you could have. ## Bounces A bounce is the receiving server refusing the message. There are two kinds and they are treated very differently. ### Hard bounce (permanent) The address does not exist, or the domain does not. It will never work, and retrying it damages your reputation. Three things happen at once: 1. The message is marked **bounced**. 2. The address is **suppressed platform-wide**, so no sender in any organization mails it again. 3. The **list contact is marked** `bounced`, so it disappears from the sendable set of every list it is on. Platform-wide is the right scope here because a nonexistent mailbox is a fact about the address, not about your relationship with it. It is also why a clean list borrows the accumulated knowledge of every list before it. ### Soft bounce (transient) The mailbox was full, the server was busy, the message was greylisted. The message is marked **deferred** and a counter goes up. Nothing is suppressed on the first one, because a transient failure is usually exactly that. **After three soft bounces the address is suppressed for that sender identity.** Three consecutive transient failures is no longer a busy server; it is an address that does not accept your mail. The suppression stays with the one identity rather than going platform-wide, because unlike a hard bounce this is a fact about the relationship, not the address. A deferral is never charged a second time. The send was already billed when it went out. ## Complaints A complaint is a recipient pressing "report spam". It is the single most expensive event in email, and it is treated accordingly: the address is suppressed at **three scopes at once**, for the sender identity, for your organization, and platform-wide. That is deliberately heavier than an unsubscribe. Someone who unsubscribes is telling you they do not want this mail. Someone who reports spam is telling Gmail you should not be sending mail at all, and the only correct response is to make certain it cannot happen again from anywhere. The list contact is marked `complained` and is never sent to again. ## Unsubscribes There are three ways a recipient can opt out, and all three work on every message you send: | Route | How it works | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **One-click** | The mailbox provider's own unsubscribe button, powered by the `List-Unsubscribe` and `List-Unsubscribe-Post` headers. Required by Gmail and Yahoo for bulk senders. No confirmation page, no chance to mail again. | | **Hosted preferences page** | The footer link opens a page where the recipient can opt out and give a reason, and choose to leave everything from your organization rather than just this sender. | | **The mailto address** | The `List-Unsubscribe` header also carries a per-message mailbox address, which some clients use instead of the URL. Mail sent to it is received and processed the same way, with no human in the loop. | **The default scope is the sender identity**, since that is the relationship the recipient acted on. The hosted page is where they can widen it to the whole organization if what they want is to hear from you not at all. **An email unsubscribe never affects texting consent, and a text STOP never affects email.** They are separate channels with separate consent, separate records, and separate legal regimes. Someone who leaves your email list is still a valid text recipient, and the reverse. If you want them off both, remove them from both. Unsubscribes are honored synchronously. There is no batch window in which a recipient who just opted out can still receive a queued message. A provider retrying a one-click request does not produce a second unsubscribe event either; a recipient unsubscribes from one send exactly once. ## When suppression is applied Twice, on purpose: 1. **When the campaign's audience is compiled.** Suppressed addresses are removed before the recipient count you see is calculated, which is why the number in the builder is often lower than the list total. 2. **Again at send time, per message.** A campaign that was compiled an hour ago and is still sending re-checks each address as it goes. The second check is the one that matters. Without it, a person who unsubscribed from message one of a large send would still get message eight hundred thousand, because the audience was fixed before they acted. ## Suppression scopes Suppressions live at three scopes and you can manage them yourself: | Scope | Blocks sending | | ---------- | -------------------------------------------------------- | | `org` | Everywhere in your organization | | `identity` | From one sender identity, where a recipient unsubscribed | | `domain` | From every sender on one sending domain | All three apply automatically. There is nothing to attach to a campaign and so nothing to forget. Writes are bulk, up to 5,000 addresses per call, malformed addresses come back in an `invalid` array rather than failing the batch, and lifting a suppression that was never set is not an error. ### Uploading a do-not-mail file To load your own do-not-mail file, go to **Assets > File Uploads** and pick **Email unsubscribes**. Choose whether it applies to the whole organization or to one sending domain, and every campaign in that scope skips those addresses from then on. Uploading also marks those people unsubscribed on your lists, so the counts you see are the counts that will actually send. ### Holding out a list from one campaign To exclude a set of people from a single campaign without suppressing them everywhere, attach an ordinary email list as a **suppression list** on the campaign. Any list can be used this way, exactly as a texting project holds out a contact list: both pickers on the campaign read from the same set of lists, and the campaign decides which are the audience and which are held out. Suppression rows can be exported from the suppressions page, so your own system of record can be reconciled against what the platform is actually blocking. ## Why removing a contact does not delete it Removing an address from a list **unsubscribes it rather than deleting the row**, and that surprises people often enough to be worth explaining. The row is what carries the bounce and complaint history. Delete it, re-import the same file six weeks later, and you have resurrected an address that already complained, and you will mail it again. Keeping the row is the entire mechanism that makes suppression durable across imports. To erase an address completely, use [forget this address](/help/email/compliance-and-link-tagging#forget-this-address), which is a deliberately heavier and irreversible operation for genuine deletion requests. ## The sunset policy Mailing people who never open anything is the fastest way to lose a sending reputation, because that is precisely the pattern mailbox providers use to identify senders who are not paying attention. The sunset policy handles it, per list, controlled by `sunset_enabled`: | Stage | What happens | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **90 days** with no engagement | The contact is **held out of sends**. It stays on the list and still counts in the total, but is not mailed. Any engagement resets the clock. | | **180 days** with no engagement | The contact's status becomes `sunset` and it leaves the sendable set for good. | Contacts added in the last 90 days are never held: someone who has not had the chance to engage yet is not an unengaged contact. ### Winning people back before the drop The window between the hold and the drop is your chance to recover the people worth recovering. There is a **re-permission** starter template for exactly this: one short message asking whether they still want to hear from you. A campaign marked as a re-permission send is the one case that is **allowed to reach held contacts**, and it also ignores the frequency cap, because a message asking permission is worthless if the policy protecting you from over-mailing prevents it from arriving. Keep it plain, keep it short, and make the "yes, keep me" action a click, since a click is what resets engagement. Everyone who ignores it was going to cost you deliverability anyway. Letting them sunset is the right outcome, not a failure. ## Rate alarms Two thresholds pause a campaign automatically, well below the point at which the sending infrastructure would intervene: | Breaker | Threshold | Provider acts at | | -------------- | --------- | ---------------- | | Bounce rate | **3%** | around 5% | | Complaint rate | **0.08%** | around 0.1% | Neither is judged until at least **500 messages** have been sent, so a handful of early bounces on a small send cannot trip them. See [Campaigns and deliverability](/help/email/campaigns-and-deliverability#deliverability-breakers) for what happens when one trips and how to resume. Separately, if our sending infrastructure disables one of your sender identities, every in-flight campaign on that identity is **paused automatically** and your organization is notified, rather than the sends failing message by message. See [Sender identities](/help/email/campaigns-and-deliverability#when-sending-is-paused-for-you).