Vetting Transactional Email Accounts

The M³AAWG Vetting BCP digested in Customer Vetting is built around a marketing sender: it audits the list, the acquisition methods, the campaign history, the complaint record. A transactional/API sender presents none of those artifacts. There is no list to review, no campaign calendar, no meaningful open-rate baseline, and often no sending history at all — just an application that will call an API when its users do things. This article covers what to vet instead, the abuse patterns unique to transactional streams, and the ongoing controls that catch a "transactional" account that stops behaving like one.

Related: Customer Vetting (the marketing-sender baseline this article diverges from), Subscription Bombing (the attack an unvetted signup form relays through you), Compromised Accounts (containment once a key or account is hijacked), Multi-Tenant Architecture (the stream/pool separation that makes transactional policy physically enforceable), Suppression-List Architecture (the transactional exception to complaint suppression).

Why transactional streams evade normal scrutiny

The standard vetting toolkit assumes artifacts a transactional sender doesn't have, and the standard monitoring toolkit assumes signals a transactional stream doesn't emit:

Marketing-vetting assumption	Transactional reality	Consequence
A list exists and can be sampled for role accounts, purchase markers, traps	No list — recipients are generated one at a time by application events	Nothing to audit pre-send; list quality is determined by the customer's signup form, which the ESP never sees unless it asks
Historical campaign metrics (opens, clicks, complaints) indicate quality	One-to-one triggered mail; engagement benchmarks for campaigns don't transfer (transactional open rates run far above marketing norms, so a "good" number proves little, and low volume makes per-send rates noisy)	Metric comparison against marketing baselines is meaningless; comparison must be against other transactional senders and against the account's own history
Complaints and unsubscribes surface problems	Recipients tolerate — and cannot practically opt out of — receipts, resets, and security notices; many jurisdictions exempt transactional mail from unsubscribe requirements (see CAN-SPAM on the primary-purpose test)	The complaint signal is structurally muted: abusive or blended traffic accumulates far longer before crossing any threshold
A test send to a list sample reveals quality (Vetting BCP methodology)	There is no list to sample; a "test send" is just the developer's own address during integration	The BCP's test-send gate cannot run; the equivalent gate is integration review (below)
Volume ramps predictably from a known list size	Volume follows the application's user activity — legitimately spiky (a product launch, a batch job) and starting from zero	Volume-anomaly detection needs application context, not list-size context

Two additional structural factors raise the stakes. First, transactional mail rides the platform's best reputation: ESPs route it through their cleanest pools precisely because it must arrive instantly (see Multi-Tenant Architecture) — so abuse through a transactional stream burns the most valuable asset. Second, self-serve API onboarding is fast by design: a free tier, a credit card, an API key in minutes. Ironscales' analysis of ESP abuse lists exactly this — free-tier/trial accounts with minimal verification, accounts bought with stolen cards, and compromised existing accounts — as how phishers obtain sending access that passes SPF/DKIM/DMARC and rides shared-pool IP reputation.

Transactional-specific risk catalog

Risk	Mechanism	Why the transactional context enables it	Primary defense
Fake-transactional phishing	Attacker signs up (or hijacks an account) and sends mail shaped like transactional traffic: password resets, invoice/payment notices, delivery notifications, document-signing requests	Transactional templates are the phisher's native genre — a fake reset or invoice is indistinguishable in form from the legitimate article, arrives fully authenticated from ESP infrastructure, and inherits shared-IP trust (Ironscales: messages "pass SPF, DKIM, and DMARC" and blend into pools carrying billions of legitimate messages)	Template review at onboarding; recipient-novelty and volume-shape monitoring; URL/domain reputation scanning on outbound content; fast abuse-desk kill path (Abuse Desk)
Relayed subscription bombing	Attacker scripts a legitimate customer's unprotected signup form; the ESP dutifully delivers thousands of confirmation/welcome messages to the victim	Every message is individually well-formed triggered mail — the ESP is the delivery arm of a DoS against a mailbox, and Spamhaus has listed ESP IPs over it. Full treatment: Subscription Bombing	Form protection (CAPTCHA + COI + rate limits) as a condition of service, verified at onboarding; fleet-wide per-target-address signup anomaly detection
API-key compromise	Key leaked in a public repo, client-side code, logs, or phished from the developer; attacker sends through the customer's warmed, authenticated identity	Keys are long-lived machine credentials outside the login/MFA perimeter; a compromised key inherits the account's full sending history and reputation. Blast radius = whatever the key is scoped to. Containment: Compromised Accounts	Scoped keys (send-only, per-stream/domain), rotation, secret-scanning partnerships — SendGrid documents automatically deleting keys its monitoring finds exposed on GitHub "within moments" and notifying the customer; velocity caps per key
Transactional/marketing blending	Customer sends newsletters, promotions, win-backs, or "product update" campaigns through the transactional stream — deliberately (to borrow its deliverability) or through drift	Transactional mail's inbox placement and exemption from unsubscribe rules make it attractive camouflage; blended traffic raises the transactional stream's complaint profile and degrades the shared transactional pool for every tenant	Policy that defines the boundary in enforceable terms (below); per-template metrics; content-drift and recipient-count detection; forced reclassification to the marketing stream
Dormant-account activation	An account integrated long ago, sending little or nothing, suddenly emits volume	Dormancy plus a valid key is exactly what a leaked-credential attacker or a sold/repurposed account looks like; the account's own baseline (near zero) makes any activity anomalous, but only if someone is watching per-account baselines	Treat activation after dormancy as a re-vetting trigger, not a growth event: hold volume at a probation cap, re-verify contact and use case, re-warm (cf. the decay principle in IP Warm-Up — trust is perishable)

The marketing-side analogues of several of these (stops-and-starts, sudden list growth, content change after metric change) already appear in the Vetting BCP's post-send triggers — the transactional versions differ in that the absence of list and campaign artifacts moves detection onto message-level telemetry.

Onboarding: vet the integration, not the list

The organizing question replaces the BCP's "show me your list and history" with: does the claimed use case match the integration you're about to connect? A "SaaS app sending password resets" claim is checkable against concrete artifacts. (The corporate-identity, WHOIS, and fraud-signal checks from Customer Vetting still apply unchanged — an API customer is still a customer; this section covers only what's different.)

Check	What to ask / inspect	Red flags
The application exists	Live product URL, app-store listing, or staging demo; does the business plausibly generate the claimed message types?	No inspectable product; product category mismatched to message types (a content site "needing" payment-failure notices); brand-new domain + urgent go-live
Template review	Request the actual templates (or review them from the first sends). Each should name a specific trigger, reference the customer's own brand/domain, link only to customer-controlled domains	Templates imitating other brands (banks, delivery firms, document-signing, mailbox providers — the fake-transactional phishing kit); URL shorteners or third-party redirect domains; "templates aren't ready" but volume is needed now
Trigger-event legitimacy	For each message type: what user action fires it, roughly how often per user, and can the recipient have expected it? Postmark's published definition is the cleanest test — transactional mail is "one-to-one unique messages the recipient is expecting to receive," user-triggered	Triggers that are really schedules ("we notify users weekly about deals"); triggers fired by someone other than the recipient with no prior relationship ("our users invite contacts" — an invitation/referral flow is a spam vector needing its own limits, cf. the web-messaging distribution controls in Compromised Accounts)
Expected volume and recipient profile	Projected messages/day, expected ratio of new-vs-repeat recipients, expected recipient-domain mix. Record the answers — they become the baseline the ongoing controls compare against	Volume implying more users than the product can plausibly have; "recipients are mostly new every day" for anything but signup confirmation; refusal to estimate
Form protection as a condition of service	If any message type is triggered by a public web form (signup, invite, tell-a-friend, contact), require CAPTCHA + rate limiting, and COI for list additions, before provisioning — Spamhaus explicitly expects ESPs to push customers to secure signup forms; make it contract, not advice (Subscription Bombing)	Unprotected forms with "we'll add CAPTCHA later"; forms that mail arbitrary user-supplied addresses (invite flows) with no per-address dedup or caps
Credential hygiene requirements	Scoped, per-environment API keys; no keys in client-side code; documented rotation ability; a named security contact for compromise notifications (the Hosting Abuse BCP's contract-for-security principle applied to keys)	Single full-permission key shared across environments and staff; key requested for an off-the-shelf script the customer can't describe
Suppression posture	How will they handle bounces/complaints returned by your webhooks? Transactional streams still hard-bounce; a sender who ignores bounce webhooks accumulates them silently	No plan to consume bounce events; expectation that the ESP's suppression can be freely bypassed (see the tightly-scoped stream-override semantics in Suppression-List Architecture)

Probationary limits do the rest. Where the marketing playbook uses a statistically sized test send, the transactional equivalent is the tiered-rights ladder from the Hosting Abuse BCP (see Customer Vetting): provision new API accounts with low daily caps and restricted capabilities, raise limits against demonstrated clean behavior and credible need, and keep limit-raise requests as re-vetting touchpoints. A limit-raise request that outruns the product's plausible growth is itself a signal.

Ongoing controls

The specific metrics below are industry practice assembled from practitioner consensus and the vendor behaviors documented above, not from a published BCP — no numeric thresholds are standardized; calibrate against your own fleet.

• Per-template / per-message-type metrics, not per-account. A transactional account is a bundle of streams with different risk. Track volume, bounce rate, complaint rate, and recipient-domain mix per template or message type (tag-based, as with the platform event systems in Multi-Tenant Architecture). Blending and abuse show up as one template diverging while the account aggregate still looks healthy. Postmark's published account-quality gates — complaint rate below 0.1%, bounce rate below 10% — show a transactional-focused ESP enforcing numeric floors even on transactional traffic.
• Content drift detection. The templates reviewed at onboarding are the contract. Alert when a "transactional" stream's content changes shape: message size or link count jumping, new outbound link domains appearing, template similarity across messages rising (identical bodies to many recipients is a broadcast signature), or subject lines acquiring promotional vocabulary. This is the transactional restatement of the Vetting BCP's "content changes following significant changes in metrics" trigger — except here content change is the leading indicator, because complaints lag.
• Recipient-novelty ratio. Genuinely transactional mail overwhelmingly addresses recipients the account has mailed before (an existing user resets a password, gets a receipt); only signup-confirmation flows skew new. A stream whose share of never-before-seen recipients surges — especially with a widening recipient-domain spread — is either a purchased list being run through the transactional lane, a relayed subscription-bombing flood, or a compromised key. Baseline the ratio per message type at onboarding (the "expected recipient profile" answer) and alert on divergence.
• Volume-shape and per-key velocity caps. Triggered mail follows the application's diurnal user-activity curve; batch blasts don't. Cap non-triggered burst capacity: a hard messages-per-minute/hour ceiling per API key sized to the account's stated use case turns a leaked key or a smuggled campaign from a fleet incident into a throttled trickle. Legitimate batch needs (digests, ToS notices) should be declared and routed to the broadcast stream — which is exactly what caps incentivize.
• Dormancy watch. Flag accounts idle beyond a set period; on reactivation, apply a probation cap and a human or automated re-verification step before restoring prior limits. Pair with forced rotation or expiry of long-unused API keys — an unused live credential is pure liability.
• Signup-form telemetry, fleet-wide. For hosted or webhook-visible signup flows, monitor confirmation sends per target address and per target domain across all customers — the per-address suppression and anomaly-detection duties detailed in Subscription Bombing.
• Outbound content scanning on the transactional path. Because complaint feedback is muted and slow, phishing caught only by FBLs is phishing that already landed. Run link/domain reputation and brand-impersonation checks inline on transactional streams (the content-filtering layer from Compromised Accounts), with the challenge/quarantine/reject ladder for grey-area hits.

Policy language: keeping the boundary enforceable

The transactional/marketing boundary only works operationally if the terms of service define it in decidable language and reserve the right to act on it. Documented patterns:

• Define transactional by trigger and expectation, not by topic. Postmark's public definition — one-to-one, unique, recipient-expecting, user-triggered, generally needing no unsubscribe link — plus its explicit negative ("multiple recipients receiving the same content" that isn't event-triggered fails the test) gives support and compliance staff a test they can apply to a message sample without litigating intent. A definition by content category ("receipts, resets…") invites the "product update = notification" argument; a definition by trigger does not.
• Make the separation physical, then require it contractually. Postmark's Message Streams model: transactional and broadcast traffic "does not mix… including IP ranges," and policy states bulk messaging "should not be sent through Transactional Message Streams." The AUP clause then has an operational referent — you sent broadcast-shaped mail through the transactional stream — rather than an argument about whether a newsletter is "really" a notification. (The pool mechanics: Multi-Tenant Architecture.)
• Reserve reclassification, not just termination. The useful enforcement action against blending is usually moving the offending traffic to the marketing stream (with its consent, unsubscribe, and suppression obligations — List-Unsubscribe, Consent Methods), with suspension reserved for refusal. Policy should state the ESP classifies streams, may reclassify traffic, and may require unsubscribe headers on messages it deems non-transactional. Practitioner consensus; ESPs publish an inquiry path for edge cases (Postmark: send a sample for classification) rather than exhaustive category lists.
• Anchor to the legal definition where one exists. US CAN-SPAM's "transactional or relationship" category and primary-purpose test (CAN-SPAM) give the boundary statutory teeth: a customer disguising commercial mail as transactional isn't just violating the AUP, it's misclassifying mail the law says needs opt-out — a compliance argument that lands with customer legal teams when deliverability arguments don't.
• Condition service on form security and credential hygiene. Contract clauses requiring bot protection on mail-triggering forms, prompt breach/key-compromise notification, and cooperation with remediation (the Hosting Abuse BCP's contract-for-security practice) convert the onboarding requirements above into enforceable obligations — and give the abuse desk clean ToS citations for the notify-remediate-suspend loop in Abuse Desk Operations.
• State the numeric floors. Publishing hard complaint/bounce ceilings for transactional streams (as Postmark does) removes the "but it's transactional" defense from enforcement conversations: the stream label changes routing, not the quality bar.

---

Provenance: the M³AAWG Vetting BCP and Hosting Abuse BCP material is used as digested in Customer Vetting; neither document addresses transactional/API senders specifically — the gap is the reason this article exists. Postmark's definitions, stream-separation policy, and quality thresholds are from its published support articles. The ESP-abuse phishing pattern is from Ironscales' published analysis; API-key exposure handling from Twilio SendGrid's support documentation and GitGuardian's remediation guidance. Sections marked as practitioner consensus reflect common ESP operating practice without a single authoritative published source; no thresholds beyond the cited vendor figures are asserted.