ESP Account Enforcement — AUP, Review States, and Reinstatement

This is the enforcement side of running a sending platform: the written policy a customer agrees to, the account states the platform can move a customer through when they breach it, the exact numeric triggers that fire those transitions, and the workflow to earn reinstatement. It complements the intake-and-triage view in Abuse Desk Operations (who receives reports and how they are prioritized), the tripwire view in Outbound Monitoring (the detection fabric and the throttle→pause→suspend response ladder), the onboarding gate in Customer Vetting, and the tenant-level auto-pause machinery in Multi-Tenant Architecture. Enforcement is what the whole apparatus exists to serve: the point where policy, detection, and consequence meet on a specific customer.

The examples are AWS SES (the most fully documented public account-level enforcement state machine, with disclosed thresholds) and Twilio SendGrid (a staged suspension ladder plus an enforced sender-consent policy). Numbers are vendor-specific and attributed; the shape generalizes to any ESP.

The acceptable use policy — structure and prohibited-use categories

Every platform's enforcement authority derives from a policy the customer accepts. The AUP defines the conduct that justifies removal, suspension, and termination, and it is the clause the abuse desk cites in every remediation notice (see Abuse Desk § Remediation workflow — "cite the specific ToS/AUP clause 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 / 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/communications system, software, or device
6	Spam / unsolicited messaging	Distributing, publishing, sending, or facilitating unsolicited mass email or other messages, promotions, advertising, or solicitations

Two structural features matter for an operator drafting their own:

• Reserved investigation-and-removal authority. AWS reserves the right to investigate suspected violations and to "remove or disable access to any content or resource that violates this Policy," and states it weighs the customer's capacity and willingness to comply when deciding the response — the written basis for graduated (rather than binary) enforcement.
• A reporting channel. Violations are reported through the provider's abuse process (abuse@ per RFC 2142 — see Abuse Desk § Mandatory role addresses). The AUP is the public face of the intake channel.

The AUP is deliberately broad; the email-specific obligations (what counts as consent, what unsubscribe must contain) live in a separate sender policy (below), and the numeric triggers live in the enforcement documentation, not the AUP itself.

The account-level enforcement state machine (AWS SES)

SES documents an explicit account-level state machine — distinct from the per-tenant reputation policies in Multi-Tenant Architecture, which pause one tenant inside an account. This is the whole-account version: the states an ESP's own upstream (its infrastructure provider) can move it through, and the reference design for what an ESP should build for its own customers.

AWS calls it the sending review process. Three states beyond healthy:

State	What it means	Sending	Trigger to enter
Healthy	Normal	Full	—
Under review	Issue detected; grace period to fix	Continues — "you can continue to send email as you normally would"	Threshold breach or manual investigation, when the problem is judged correctable
Sending paused	Sending disabled account-wide	Blocked	Review period expired uncorrected; repeat of the same issue; or a serious violation (can skip review)

Key semantics, all from AWS's enforcement FAQ:

• Under review is a warning with the lights still on. The customer keeps sending, which means they can make the problem worse — AWS explicitly advises pausing sends yourself if your situation allows. The account email address (the one on the AWS account, which may differ from the SES sending identity) receives the notice; a support case is opened on the customer's behalf.
• Review can be skipped. SES pauses 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 on serious AWS Service Terms violations. The repeat-offender rule is why 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."
• Blast radius into sibling services. While under review or paused, other AWS services still work, but quota-increase requests for other outbound-communication services (e.g., Amazon SNS) may be denied until the SES review clears — enforcement on one channel freezes expansion of adjacent ones.
• Status is observable programmatically. The Account dashboard shows Healthy / Paused; the AWS Health Dashboard logs an SES sending paused event (always with Status Closed regardless of current state) that includes a copy of the notification email — an operator building on top of a provider should ingest these events, not rely on a human reading the account mailbox.

The disclosed thresholds

SES is unusually specific about the 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 — an amount of mail representative of the sender's typical practice, sized per-sender and moving as sending patterns change (so the same guard protects high- and low-volume senders and a 2-bounce-in-10 spike 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 unverified domains. Mailbox-full, transient, and IP-block bounces do not count.
Complaint rate	below 0.1%	0.1% or greater	0.5% or greater	Percentage of complaints on mail to domains that send FBL feedback to SES. The console/GetSendStatistics complaint statistic includes only FBL complaints — not direct-to-SES or provider-reported complaints.

Other trigger classes carry no published number but their own escalation logic:

• Spamtraps. SES does not disclose the hit count that triggers action ("even a small number … can have a very negative effect"). A severe trap problem can pause the account immediately without a review. Because trap hits are reported with delay, it "may take three weeks or more" to confirm a fix worked — a timeline an operator must plan reinstatement around.
• Direct complaints & provider-reported complaints (the three-week rule). For complaints recipients file directly with the platform, or that a mailbox provider reports out-of-band, 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 non-remediation.
• Manual investigation. A human investigator can place an account under review or pause it for: AUP violation, mail that "appears to be unsolicited," phishing content including simulated/authorized phishing tests, or "a use case that SES doesn't support." Correctability is judged on whether the sender has "a history of good sending practices" and can isolate the bad stream while continuing the rest (e.g., stop one of three email types) — the same logic an ESP applies before choosing suspension over termination.

The operator-built kill switch (design evidence)

SES also documents how a customer wires automatic account pausing themselves, which doubles as the reference architecture for an ESP's own auto-enforcement: a CloudWatch alarm on the Reputation.BounceRate or Reputation.ComplaintRate account metric fires an SNS topic that invokes a Lambda calling UpdateAccountSendingEnabled(Enabled=false); re-enabling is the same API with Enabled=true (or aws ses update-account-sending-enabled --enabled). AWS's stated guidance: set the alarm thresholds below the enforcement lines (below 5% bounce / 0.1% complaint) so you pause yourself before the platform pauses you. The generalizable lessons: (1) expose a single idempotent enable/disable primitive per account, (2) drive it from rate metrics with a minimum-volume guard, and (3) set the self-pause line inside the provider's enforcement line so you never cede the decision. The provider gives you the throttle; you decide where to trip it — the platform-side twin of the response ladder in Outbound Monitoring § Automated responses.

The SES pause line is not a deliverability-safe target. SES's 0.5% complaint pause (and 10% bounce pause) is an upstream-infrastructure line measured at network/pool scope (per AWS account) — the point where AWS protects its own shared IP reputation, not where your mail still reaches the inbox. It is a different measurement from the per-domain mailbox-provider ceiling (see Metrics & Benchmarks § Reading thresholds by scope). It sits far above the mailbox-provider reality: Gmail and Yahoo treat 0.3% complaints as a hard violation ceiling (see Gmail Sender Requirements and Yahoo Sender Requirements), and the cross-source consensus healthy target is < 0.1% (Metrics & Benchmarks § canonical threshold table). An ESP building its own complaint auto-pause should therefore trip it at or below the 0.3% Gmail/Yahoo ceiling — ideally around 0.1% — well inside SES's 0.5% line. "Inside the provider's enforcement line" means inside the tightest line that governs your deliverability, not merely inside AWS's infrastructure pause.

The staged suspension ladder (Twilio SendGrid)

Where SES models the review/pause boundary, SendGrid's account-under-review documentation models the graduated ladder — four progressively harsher states, each changing what still works. SendGrid reviews accounts showing "apparent abnormal activity" to preserve sender reputation (it does not publish the specific volume/complaint/bounce triggers, unlike SES).

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

The ladder's design is instructive: Suspended is reversible without data loss — mail is buffered for 72 hours, so a customer who resolves the review quickly loses nothing, but a slow responder silently loses the backlog. Deactivated crosses the line where queued mail is destroyed and tracking links break (so links in already-delivered mail stop resolving). Banned is terminal — IPs are relinquished (mirroring the abuse-desk termination step in Abuse Desk § Termination) and billing behavior flips. Each rung raises the cost of non-response, which is the point of a graduated ladder: give the salvageable customer room while making continued abuse progressively more expensive.

The reinstatement workflow

Both platforms gate resumption behind the same human-reviewed loop — the counterpart to the abuse desk's remediation workflow, seen from the customer's side.

What the customer must submit (SES, and generalizable):

1. Root cause of the event that triggered enforcement.
2. A list of changes already implemented — 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 recurrence — the forward-looking guarantee, distinct from the fix itself.
4. Any specifically requested evidence. For a bounce case: the bounce-tracking method and how new addresses are validated before first send. For an unsolicited-mail case: whether every message was recipient-requested and AUP-compliant, how the list was acquired, and the actual subscribe/unsubscribe (opt-in/opt-out) links.

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

What reviewers check. The provider typically gives "only a high-level overview" of the issue (e.g., "you have a problem with bounces") and will not enumerate the offending addresses — root-cause diagnosis is the customer's job, by design, so the fix addresses the process rather than the symptom. SES states 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:

• No fixed review duration is published by either vendor. SES notes some categories (spamtraps, delayed-reporting complaints) need three weeks or more before a fix can even be confirmed — reinstatement can lag the actual remediation.
• A rejected request can be resubmitted once the customer can demonstrate the issue is resolved and recurrence prevented; SES responds with why a request was declined.
• Fixing a problem just before a review period expires still requires replying to the case to flag it resolved — the clock does not credit an unreported fix.

This is the customer-facing mirror of Abuse Desk § Remediation workflow: validate → notify with the cited clause → grant remediation time → confirm resolved → close. Fraudulent accounts are the exception in both directions — they skip the courtesies and are not helped back in (see Abuse Desk and Compromised Accounts for distinguishing malicious from compromised).

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

Beyond the broad AUP, a sending platform enforces an email-specific consent policy — the standard against which "unsolicited" enforcement is judged. SendGrid's is a concrete model of what an ESP requires of every sender.

Consent (opt-in):

• Affirmative consent is required for all email except transactional. Transactional = "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 cannot come from purchased lists, third-party lead generators, or affiliates; scraping addresses from social media, LinkedIn, or the web is prohibited. The sender who mails must be the party that obtained the consent.
• Disclosure at collection. The sender must identify themselves when gathering consent, maintain that identity across communications, and tell recipients how their email will be used and its subject matter.
• Opt-in strength (definitions the platform recognizes): single opt-in (permission requested only at registration), double opt-in (permission requested, then verified by a confirmation email), confirmed opt-in (periodically asking recipients to confirm continued interest). See Consent Methods for the full opt-in quality spectrum and complaint-risk profiles.
• Reconfirmation for stale contacts. Senders must re-obtain affirmative consent before mailing a recipient "after an extended period of non-engagement"; SendGrid's guidance sets that at recipients not corresponded/interacted with in over 3 months. This is the policy-level version of the sunset discipline in List Hygiene & Sunset Policies.

Opt-out (unsubscribe):

• Every non-transactional email must contain a physical mailing address, a clear unsubscribe hyperlink, and a privacy-policy link (aligns with the mechanics in List-Unsubscribe & One-Click).
• Opt-out requests must be honored within the applicable legal timeframe or 10 days — whichever is shortest. (Compare CAN-SPAM's 10-business-day statutory ceiling in CAN-SPAM; the platform contractually adopts the shorter of law-or-10-days.)
• Recipients may revoke consent at any time; the sender must reconfirm before any further mail.

This policy is the substance behind the AUP's category 6 ("unsolicited") and behind every SES manual-investigation "appears to be unsolicited" finding — the abuse desk cites the AUP, but adjudicates against this consent standard.

Design lessons for an ESP

1. Three documents, three jobs. The AUP defines terminable conduct in broad strokes and grants investigation/removal authority; the sender consent policy defines the email-specific standard that "unsolicited" is measured against; the enforcement documentation defines the numeric triggers and states. Keeping numbers out of the contract lets you tune thresholds without a policy amendment.
2. Publish where the lines are, hide the rest. SES discloses bounce (5%/10%) and complaint (0.1%/0.5%) thresholds so senders can self-govern, but withholds spamtrap counts and representative-volume sizing so they cannot game the edge. Disclose the metrics a good-faith sender needs; keep the ones only an abuser would exploit.
3. A warning state must stop the bleeding. SES's "under review" keeps sending on and warns the customer to pause themselves — a real risk. If your warning tier leaves sending fully enabled, pair it with an automatic throttle (see Outbound Monitoring) so a customer cannot worsen the problem during their grace period.
4. Grade the ladder by cost of non-response, and make early rungs reversible. SendGrid's Suspended state buffers 72 hours with no data loss; only Deactivated destroys queued mail; only Banned relinquishes IPs. Give the salvageable customer a lossless rung and reserve destructive steps for the terminal ones.
5. Reinstatement demands implemented fixes and a recurrence guarantee, not intentions — and the burden of root-cause diagnosis stays with the customer. Both are deliberate: they force the process fix over the symptom fix, and repeat offenders lose the grace period entirely.
6. Enforcement on one channel should constrain adjacent ones. SES freezes SNS quota increases during a review. A multi-product platform that lets a customer route around an email suspension into SMS or push has not enforced anything.

Related articles

• Abuse Desk Operations — report intake, triage priorities, and the remediation/suspension/termination loop this article's states plug into.
• Outbound Monitoring — the detection fabric and the throttle→pause→suspend response ladder that fires these state transitions.
• Multi-Tenant Architecture — per-tenant reputation findings and auto-pause policies (the surgical, sub-account version of this account-level machinery).
• Customer Vetting — the onboarding gate and tiered-trust model that sets each customer's enforcement sensitivity.
• Consent Methods · List-Unsubscribe & One-Click — the opt-in spectrum and unsubscribe mechanics the enforced sender policy relies on.
• Metrics & Benchmarks — the sender-side bounce/complaint thresholds these enforcement lines mirror.