ESP Operations

Running an abuse desk at an ESP, ISP, or hosting provider — mandatory role addresses (RFC 2142), report intake, triage priorities, auto-acknowledgement, unblocking, complaint-priority tiers, remediation workflow, ticketing, and staffing/management.

Spamhaus's three-part operational playbook for ESPs digested — set senders up for success (onboarding safeguards, mandatory authentication, cross-functional policy), monitor and educate customers (data tiers, business-impact framing), and take proactive protective measures (risk-tiered IP pools, list scanning, behavioral routing, rate-limiting as leverage); plus the hosting-provider anti-fraud-signup controls.

Detecting, containing, and remediating compromised customer accounts and outbound abuse on ESP/hosting infrastructure — M3AAWG Compromised User ID BCP, Hosting Abuse BCP, and Web Messaging Abuse BCP digested.

How major ESPs (Postmark, Amazon SES, SendGrid) actually implement customer sending-domain authentication — on-behalf-of models, CNAME-delegated DKIM, custom MAIL FROM subdomains, link branding, verification flows, and customer DNS failure modes.

The runbook for winding down a customer who is leaving on good terms — draining in-flight mail, relinquishing or quarantining their dedicated IPs, retiring their sending subdomain and DKIM selectors, reconciling suppression retention against a GDPR erasure request, and revoking access — as distinct from abuse termination.

The M3AAWG Vetting BCP digested — pre-send vetting questionnaires (corporate entity, infrastructure, sending history, list practices), red flags, the test-send methodology, ongoing post-send monitoring triggers, and vetting tools (WHOIS, D&B, PACER).

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.

The continuous-monitoring architecture of a sending platform — pre-send scanning, send-time anomaly detection against per-customer baselines, post-send feedback watchers, alert design (leading vs lagging, threshold vs trend, per-pool vs per-customer), and the graduated automated-response ladder.

How an ESP vets IP address space before sending on it — prior-use and reputation history via ARIN WhoWas/RDAP and RIPEstat, why recycled IPs inherit blocklist history, the IPv4 transfer/lease-market abuse problem, and pre/post-acquisition checklists.

How mature sending platforms structure multi-tenancy — dedicated vs managed IP pools, shared-pool fallback, per-tenant reputation tracking, and automated tenant enforcement — extracted as design evidence from AWS SES and SendGrid.

The disaster-recovery runbook for a shared IP pool torched by a bad tenant — distinguishing a poisoned pool from one struggling sender, attributing and isolating the offender, containing them, delisting the pool's IPs across blocklist zones, evacuating clean tenants to a healthy pool, and deciding whether to rehabilitate or retire the burned IPs.

How an ESP works a spam-trap-hit incident — detection signals, trap confidentiality, customer notification, acquisition audit, list-hygiene review, and escalation to termination — per M3AAWG "Help! I Hit a Spam Trap!" (Feb 2023).

How mass fraudulent form signups weaponize confirmation email as a DoS against victim mailboxes, the detection signatures of an attack in progress, and the layered defenses form owners and ESPs must run.

How a multi-tenant platform scopes suppression — global vs account vs tenant vs stream — with auto-suppression triggers, precedence and override semantics, retention, and bulk transfer, extracted from AWS SES's documented design.

The signal-vendor landscape for automating ESP customer vetting — email-risk APIs, IP/device fraud scoring, domain intelligence, payment-fraud signals, breach lookups — and the automation architecture that composes them into onboarding gates, progressive trust ladders, and continuous re-scoring.

Why transactional/API senders evade the standard vetting playbook, the transactional-specific abuse catalog (fake-transactional phishing, relayed subscription bombing, API-key blast radius, marketing-as-notification blending, dormant reactivation), onboarding checks matched to the integration, ongoing per-template controls, and the policy language that keeps the transactional/marketing boundary enforceable.