# ESP Account Enforcement — AUP, Review States, and Reinstatement

> How sending platforms police customers at the account level — acceptable-use-policy structure and prohibited-use categories, the review/pause/shutdown state machine and the exact bounce/complaint/spamtrap thresholds that trigger it (AWS SES), the account-under-review reinstatement workflow and staged suspension ladder (Twilio SendGrid), and the opt-in/opt-out policy the platform enforces on senders.

Source: emailmarketing.net — https://emailmarketing.net/learn/esp-operations/account-enforcement

When a customer of your sending platform breaks your rules, you need four things in place: a written policy the customer agreed to, a set of account states you can move the customer through, numeric triggers that move an account from one state to the next, and a process the customer follows to be reinstated. This is where policy, detection and consequences meet on a specific customer.

Other parts of the platform feed enforcement. [Abuse Desk Operations](https://emailmarketing.net/learn/esp-operations/abuse-desk) covers who receives abuse reports and how they are prioritized. [Outbound Monitoring](https://emailmarketing.net/learn/esp-operations/outbound-monitoring) covers detection and the ladder of responses (throttle, then pause, then suspend). [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting) covers the gate at onboarding, and [Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture) covers automatic pausing of a single tenant.

The examples come from AWS SES, which publishes the most complete account-level enforcement states, with their thresholds, and from Twilio SendGrid, which publishes a staged suspension ladder and the consent policy it enforces on senders. The numbers are specific to each vendor and attributed to it. The overall structure applies to any ESP.

## The acceptable use policy: structure and prohibited-use categories

A platform's authority to enforce comes from a policy the customer accepts. The acceptable use policy (AUP) defines the conduct that justifies removal, suspension and termination. The abuse desk cites it in every remediation notice. [Abuse Desk Operations](https://emailmarketing.net/learn/esp-operations/abuse-desk) explains, under its remediation workflow, that citing the specific clause of the terms of service or AUP that was breached protects the provider against litigation from either side.

The **AWS Acceptable Use Policy** (last updated 2021-07-01 in the version reviewed) is a compact model. It prohibits using the services for:

| # | Prohibited-use category | Scope (AWS wording, condensed) |
|---|---|---|
| 1 | **Illegal or fraudulent activity** | Any illegal or fraudulent activity |
| 2 | **Rights violations** | Violating the rights of others |
| 3 | **Violence & serious harm** | Threatening, inciting, promoting, or actively encouraging violence, terrorism, or other serious harm |
| 4 | **Child sexual exploitation** | Any content or activity promoting child sexual exploitation or abuse |
| 5 | **System security** | Violating the security, integrity, or availability of any user, network, computer or communications system, software, or device |
| 6 | **Spam and unsolicited messaging** | Distributing, publishing, sending, or facilitating unsolicited mass email or other messages, promotions, advertising, or solicitations |

If you are drafting your own AUP, two features of its structure matter:

- **A reserved right to investigate and remove.** AWS reserves the right to investigate suspected violations and to "remove or disable access to any content or resource that violates this Policy." It also states that it weighs the customer's capacity and willingness to comply when it decides how to respond. That statement is the written basis for enforcement in steps, rather than a choice between all and nothing.
- **A reporting channel.** Violations are reported through the provider's abuse process (`abuse@`, as RFC 2142 requires; see the mandatory role addresses in [Abuse Desk Operations](https://emailmarketing.net/learn/esp-operations/abuse-desk)). The AUP is the public face of that intake channel.

The AUP is broad on purpose. The obligations specific to email, such as what counts as consent and what an unsubscribe must contain, belong in a separate sender policy (below). The numeric triggers belong in the enforcement documentation, not in the AUP.

## The account-level enforcement state machine (AWS SES)

SES documents explicit enforcement states for a **whole account**. They are different from the reputation policies for each tenant described in [Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture), which pause one tenant inside an account. These are the states an ESP's own infrastructure provider can move the ESP through, and they are a reference design for what an ESP should build for its own customers.

AWS calls this the **sending review process**. It has three states:

| State | What it means | Sending | Trigger to enter |
|---|---|---|---|
| **Healthy** | Normal | Full | None |
| **Under review** | An issue was detected, and there is a grace period to fix it | **Continues**: "you can continue to send email as you normally would" | A threshold breach or a manual investigation, when the problem is judged correctable |
| **Sending paused** | Sending is disabled for the whole account | **Blocked** | The review period expired without a fix, the same issue happened again, or there was a serious violation (which can skip the review) |

All of the following comes from AWS's enforcement FAQ:

- **Under review is a warning, and sending stays on.** The customer keeps sending, which means it can make the problem worse. AWS explicitly advises you to pause your own sending if your situation allows it. The notice goes to the account email address, the one on the AWS account, which may differ from the SES sending identity. AWS opens a support case on the customer's behalf.
- **The review can be skipped.** SES pauses an account without a prior review when the issue is "very serious", when the account "has been placed under review for the same issue multiple times", or when AWS Service Terms are seriously violated. Because of the rule on repeat offenders, the FAQ insists on fixing the underlying process, not just stopping the one campaign: "if a particular campaign caused us to place your account under review, you have to do more than simply stop that campaign."
- **Enforcement reaches other services.** While an account is under review or paused, other AWS services still work, but **requests to raise quotas on other outbound-communication services (for example, Amazon SNS) may be denied** until the SES review is cleared. Enforcement on one channel stops growth on the channels next to it.
- **Status can be read by software.** The Account dashboard shows `Healthy` or `Paused`. The AWS Health Dashboard logs an **`SES sending paused`** event, always with the Status `Closed` whatever the current state, that includes a copy of the notification email. An operator that builds on a provider should ingest these events rather than rely on a person reading the account mailbox.

### The disclosed thresholds

SES is unusually specific about its numbers, which makes it the best public reference for where to set enforcement lines. All rates are computed over a **representative volume**, not a fixed calendar window. That is an amount of mail typical of the sender's usual practice, sized for each sender and adjusted as sending patterns change. The same guard therefore protects senders with high and low volumes, and a spike of 2 bounces in 10 messages cannot trip anyone.

| Metric | Best-practice target | **Under review at** | **May be paused at** | Counting rule |
|---|---|---|---|---|
| **Hard bounce rate** | below 2% | **5% or greater** | **10% or greater** | Only hard bounces (permanent, "address does not exist") to domains that are not verified. Bounces for a full mailbox, transient bounces and IP blocks do **not** count. |
| **Complaint rate** | below 0.1% | **0.1% or greater** | **0.5% or greater** | The percentage of complaints on mail to domains that send feedback loop (FBL) reports to SES. The complaint statistic in the console and in `GetSendStatistics` includes **only** FBL complaints, not complaints made directly to SES or reported by a mailbox provider. |

Other kinds of trigger have no published number, but each escalates in its own way:

- **Spamtraps.** SES does not disclose how many hits trigger action ("even a small number … can have a very negative effect"). A severe trap problem can pause the account immediately, with no review. Trap hits are reported with a delay, so it "may take three weeks or more" to confirm that a fix worked, and an operator must plan reinstatement around that timeline.
- **Direct complaints and complaints reported by providers (the three-week rule).** For complaints that recipients file directly with the platform, or that a mailbox provider reports through another channel, SES gives a concrete deadline: "if you don't request a review within three weeks, and we continue to receive [complaints], we might pause your account's ability to send email." Silence is treated as a failure to remediate.
- **Manual investigation.** An investigator can place an account under review, or pause it, for an AUP violation, for mail that "appears to be unsolicited", for phishing content, **including simulated or authorized phishing tests**, or for "a use case that SES doesn't support." Whether the problem can be corrected depends on whether the sender has "a history of good sending practices" and can isolate the bad stream while continuing the rest (for example, stopping one of three email types). An ESP applies the same logic before it chooses suspension over termination.

### The operator-built kill switch (design evidence)

SES also documents how customers can set up **automatic** pausing of their own account, which doubles as a reference architecture for an ESP's own automatic enforcement. A CloudWatch alarm on the `Reputation.BounceRate` or `Reputation.ComplaintRate` account metric notifies an SNS topic. The topic invokes a Lambda function that calls **`UpdateAccountSendingEnabled(Enabled=false)`**. Sending is turned back on with the same API and `Enabled=true` (or with `aws ses update-account-sending-enabled --enabled`).

AWS advises setting the alarm thresholds below the enforcement lines (below 5% for bounces and 0.1% for complaints), so that you pause yourself before the platform pauses you. Three lessons apply to any platform: (1) expose a single idempotent operation for each account that enables or disables sending, (2) drive it from rate metrics, with a guard for minimum volume, and (3) set your own pause line inside the provider's enforcement line, so that the decision always stays with you. The provider gives you the switch, and you decide when to use it. This is the platform-side counterpart of the automated responses in [Outbound Monitoring](https://emailmarketing.net/learn/esp-operations/outbound-monitoring).

> **The SES pause line is not a safe target for deliverability.** The SES pause at **0.5%** complaints (and at **10%** bounces) is a line set by the infrastructure provider and measured at the **scope of a network or pool** (each AWS account). It is the point where AWS protects **its own** shared IP reputation, not a point where your mail still reaches the inbox. It measures something different from the ceiling mailbox providers apply to each **domain** (see how to read thresholds by scope in [Metrics & Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks#reading-thresholds-by-scope-read-this-first)). It sits far above what mailbox providers accept: Gmail and Yahoo treat a complaint rate of **0.3%** as a hard ceiling (see [Gmail Sender Requirements](https://emailmarketing.net/learn/providers/gmail-sender-requirements) and [Yahoo Sender Requirements](https://emailmarketing.net/learn/providers/yahoo-sender-requirements)), and the healthy target that sources agree on is **< 0.1%** (see the threshold table in [Metrics & Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks#canonical-threshold-table)). An ESP that builds its own automatic pause on complaints should therefore trip it **at or below the 0.3% ceiling set by Gmail and Yahoo, and ideally around 0.1%**, well inside the SES line of 0.5%. Staying "inside the provider's enforcement line" means staying inside the tightest line that governs your deliverability, not only inside the line where AWS pauses its infrastructure.

## The staged suspension ladder (Twilio SendGrid)

SES documents the boundary between review and pause. SendGrid's documentation on accounts under review describes a ladder of steps instead: four states, each harsher than the last, and each changing what still works. SendGrid reviews accounts that show "apparent abnormal activity" to protect sender reputation. Unlike SES, it does not publish the specific triggers for volume, complaints or bounces.

| State | Sending | Queued mail | Tracking | Subusers | Dedicated IPs | Billing |
|---|---|---|---|---|---|---|
| **Warned** | Full functionality retained | Not stated | Active | Can still create; plan upgrades allowed | Retained | Standard |
| **Suspended** | Mail **accepted and queued**, not delivered | Held until the issues are resolved, **up to 72 hours** from sending, and expires undelivered after 72h | Still works (opens and clicks) | Not stated | Retained | Continues (auto-renews) |
| **Deactivated** | **Cannot accept mail** | Queued mail **deleted** | **Disabled** | Can log in directly, but the parent account cannot "log in as" | Not stated | Continues (auto-renews) |
| **Banned** | Cannot access the system or send; requests rejected | Not stated | Not stated | Cannot send or access the account | **Removed** | Auto-renewal stops; overages charged |

The design of this ladder is instructive. **Suspended can be reversed without losing data**: mail is held for 72 hours, so a customer who resolves the review quickly loses nothing, while a customer who responds slowly loses the backlog without warning. **Deactivated** is the point where queued mail is destroyed and tracking links break, so links in mail already delivered stop working. **Banned** is final. The IP addresses are taken back, as in the termination step in [Abuse Desk Operations](https://emailmarketing.net/learn/esp-operations/abuse-desk), and billing changes. Each step raises the cost of not responding. That is the purpose of a graduated ladder: it gives a customer who can be saved room to fix things, while making continued abuse more and more expensive.

## The reinstatement workflow

Both platforms require the same process, reviewed by people, before sending resumes. It is the abuse desk's remediation workflow seen from the customer's side.

**What the customer must submit (SES, and applicable to any platform):**

1. **The root cause** of the event that triggered enforcement.
2. **A list of changes already made.** SES is explicit: "only include the steps you've already implemented, not the steps you plan to implement in the future." Intentions do not clear a review.
3. **How those changes prevent the problem from happening again.** This is a commitment about the future, separate from the fix itself.
4. **Any evidence specifically requested.** In a bounce case, that means the method for tracking bounces and how new addresses are validated before the first send. In a case about unsolicited mail, it means whether every message was requested by the recipient and complied with the AUP, how the list was acquired, and the actual subscribe and unsubscribe (opt-in and opt-out) links.

The channel is the support case the platform opened on the account's behalf, and the customer replies to it. SendGrid says the same: "the fastest way to get your account reactivated is to respond directly to the ticket sent to your email address", answering every question in the notice.

**What reviewers check.** The provider typically gives "only a high-level overview" of the issue (for example, "you have a problem with bounces") and does not list the addresses at fault. Finding the root cause is the customer's job by design, so that the fix addresses the process rather than the symptom. SES states that it will cancel the review or lift the pause only "if we agree that the changes you've made appropriately address the issue."

**Timelines & retries:**

- Neither vendor publishes a fixed review duration. SES notes that some categories (spamtraps, and complaints that are reported late) need **three weeks or more** before a fix can even be confirmed, so reinstatement can come well after the actual remediation.
- A rejected request can be **submitted again** once the customer can show that the issue is resolved and will not recur. SES explains why it declined a request.
- A customer who fixes a problem just before a review period expires must still reply to the case to report it resolved. The review does not count a fix that nobody reported.

This is the customer's view of the remediation workflow in [Abuse Desk Operations](https://emailmarketing.net/learn/esp-operations/abuse-desk): validate the report, notify the customer and cite the clause, allow time to remediate, confirm the problem is resolved, and close the case. Fraudulent accounts are the exception on both sides. They get none of these courtesies and are not helped back onto the platform (see [Abuse Desk](https://emailmarketing.net/learn/esp-operations/abuse-desk), and [Compromised Accounts](https://emailmarketing.net/learn/esp-operations/compromised-accounts) for telling malicious accounts from compromised ones).

## The enforced sender policy (opt-in / opt-out)

Besides the broad AUP, a sending platform enforces a **consent policy specific to email**. It is the standard used to judge whether mail was "unsolicited". SendGrid's policy is a concrete model of what an ESP requires of every sender.

**Consent (opt-in):**

- **Affirmative consent is required for all email except transactional email.** SendGrid defines transactional email as "non-marketing email … about an action or transaction that a recipient has taken or agreed to."
- **Consent must be first-party and specific.** It cannot be blanket consent, and it cannot come from **purchased lists, third-party lead generators or affiliates**. **Scraping** addresses from social media, LinkedIn or the web is prohibited. The sender that sends the mail must be the party that obtained the consent.
- **Disclosure at collection.** Senders must identify themselves when they collect consent, keep that identity across their messages, and tell recipients how their email address will be used and what the messages will be about.
- **Strength of opt-in (the definitions the platform recognizes):** single opt-in asks for permission only at registration. Double opt-in asks for permission and then verifies it with a confirmation email. Confirmed opt-in periodically asks recipients to confirm that they are still interested. See [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods) for the full range of opt-in quality and the complaint risk of each method.
- **Reconfirmation for stale contacts.** Senders must obtain affirmative consent again before mailing a recipient "after an extended period of non-engagement". SendGrid's guidance defines that as recipients you have not written to or interacted with in **over 3 months**. This is the policy version of the sunset practice in [List Hygiene & Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies).

**Opt-out (unsubscribe):**

- Every **non-transactional** email must contain a physical mailing address, a clear unsubscribe link and a link to the privacy policy (consistent with the mechanics in [List-Unsubscribe & One-Click](https://emailmarketing.net/learn/list-management/list-unsubscribe)).
- **Opt-out requests must be honored within the applicable legal timeframe or 10 days, whichever is shorter.** Compare the legal maximum in [CAN-SPAM](https://emailmarketing.net/learn/compliance/can-spam), a 10-business-day period. By contract, the platform adopts whichever is shorter: the legal period or 10 days.
- Recipients may withdraw consent at any time, and the sender must obtain it again before sending any more mail.

This policy gives substance to category 6 of the AUP ("unsolicited") and to every finding in an SES manual investigation that mail "appears to be unsolicited". The abuse desk cites the AUP, but it judges the case against this consent standard.

## Design lessons for an ESP

1. **Use three documents, each with its own job.** The AUP defines, in broad terms, the conduct that can lead to termination, and grants the right to investigate and remove. The sender consent policy defines the standard specific to email that "unsolicited" is measured against. The enforcement documentation defines the numeric triggers and the states. Keeping numbers out of the contract lets you tune thresholds without amending the policy.
2. **Publish where the lines are, and keep the rest private.** SES discloses its bounce thresholds (5% and 10%) and complaint thresholds (0.1% and 0.5%) so that senders can govern themselves, but it keeps spamtrap counts and the sizing of the representative volume private, so that senders cannot game the edge. Disclose the metrics a sender acting in good faith needs, and keep private the ones only an abuser would exploit.
3. **A warning state must stop the damage.** The SES "under review" state keeps sending on and advises the customer to pause, which is a real risk. If your warning state leaves sending fully enabled, pair it with an automatic throttle (see [Outbound Monitoring](https://emailmarketing.net/learn/esp-operations/outbound-monitoring)), so that a customer cannot make the problem worse during the grace period.
4. **Order the ladder by the cost of not responding, and make the early steps reversible.** SendGrid's Suspended state holds mail for 72 hours with no data loss. Only Deactivated destroys queued mail, and only Banned takes back IP addresses. Give a customer who can be saved a step with no loss, and keep the destructive steps for the final states.
5. **Reinstatement requires fixes already made and a commitment against recurrence, not intentions.** The burden of finding the root cause stays with the customer. Both rules are deliberate: they force a fix to the process rather than to the symptom, and repeat offenders lose the grace period entirely.
6. **Enforcement on one channel should limit the others.** SES stops SNS quota increases during a review. A platform with several products that lets a customer get around an email suspension through SMS or push notifications has not enforced anything.

## Related articles

- [Abuse Desk Operations](https://emailmarketing.net/learn/esp-operations/abuse-desk), on report intake, triage priorities, and the loop of remediation, suspension and termination that uses these states
- [Outbound Monitoring](https://emailmarketing.net/learn/esp-operations/outbound-monitoring), on detection and the ladder of responses (throttle, pause, suspend) that triggers these state changes
- [Multi-Tenant Architecture](https://emailmarketing.net/learn/esp-operations/multi-tenant-architecture), on reputation findings and automatic pausing for a single tenant
- [Customer Vetting](https://emailmarketing.net/learn/esp-operations/customer-vetting), on the onboarding gate and the tiered trust that sets how sensitive enforcement is for each customer
- [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods)
- [List-Unsubscribe & One-Click](https://emailmarketing.net/learn/list-management/list-unsubscribe)
- [Metrics & Benchmarks](https://emailmarketing.net/learn/operations/metrics-and-benchmarks), on the bounce and complaint thresholds for senders that these enforcement lines mirror