emailmarketing.net
EnglishFrançais

Vetting Transactional Email Accounts

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.

Operational14 min read

Who it is for ESP operators

ContentsOn this page — 6 sections

If you run an email service provider (ESP), customers who send password resets, receipts and account notices through your API give you little of what a vetting review normally examines. The industry's vetting guidance, the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) Vetting Best Common Practices (BCP), is built around a marketing sender. It audits the list, how the addresses were acquired, the campaign history and the complaint record.

A transactional or API sender has none of those to show. There is no list to review, no campaign calendar, no meaningful open-rate baseline, and often no sending history at all. There is only an application that will call your API when its users do things.

You can still vet these accounts. The checks move from the list to the integration, the abuse patterns to watch for are specific to transactional mail, and the ongoing controls catch a "transactional" account that stops behaving like one. Customer Vetting covers the general process this builds on.

Why standard vetting misses transactional senders

Standard vetting looks for evidence that a transactional sender does not have, and standard monitoring looks for signals that a transactional stream does not produce:

What marketing vetting assumes What a transactional sender actually has Consequence
A list exists and can be sampled for role accounts, signs of purchase, and spam traps No list. The application generates recipients one at a time as events happen There is nothing to audit before sending. List quality depends on the customer's signup form, which the ESP never sees unless it asks
Historical campaign metrics (opens, clicks, complaints) show quality Triggered one-to-one mail. Engagement benchmarks for campaigns do not apply: transactional open rates run far above marketing norms, so a "good" number proves little, and low volume makes rates per send noisy Comparing metrics with marketing baselines is meaningless. Compare them with other transactional senders and with the account's own history
Complaints and unsubscribes reveal problems Recipients tolerate receipts, password resets and security notices, and cannot practically opt out of them. Many jurisdictions exempt transactional mail from unsubscribe requirements (see the primary-purpose test in CAN-SPAM) The complaint signal is muted by the nature of this mail. Abusive or mixed traffic builds up for much longer before it crosses any threshold
A test send to a sample of the list reveals quality (the method in the Vetting BCP) There is no list to sample. A "test send" is just the developer's own address during integration The BCP's test-send check cannot run. The equivalent check is an integration review (below)
Volume grows predictably from a known list size Volume follows the application's user activity. It is legitimately spiky (a product launch, a batch job) and starts from zero Detecting volume anomalies needs knowledge of the application, not of a list size

Two more factors raise the stakes. First, transactional mail travels on the platform's best reputation. ESPs route it through their cleanest IP pools because it must arrive immediately (see Multi-Tenant Architecture), so abuse through a transactional stream damages the platform's most valuable asset.

Second, self-service API onboarding is fast by design: a free tier, a credit card and an API key in minutes. Ironscales' analysis of ESP abuse names exactly these routes as the way phishers get sending access that passes SPF, DKIM and DMARC and benefits from the IP reputation of shared pools: free-tier and trial accounts with minimal verification, accounts bought with stolen cards, and compromised existing accounts.

Abuse patterns specific to transactional mail

Risk How it works Why transactional mail makes it possible Main defense
Fake-transactional phishing An attacker signs up, or takes over an account, and sends mail that looks like transactional traffic: password resets, invoice or payment notices, delivery notifications, requests to sign documents Transactional templates are exactly what phishers imitate. A fake reset or invoice has the same form as a real one, arrives fully authenticated from ESP infrastructure, and inherits the trust of shared IP addresses. Ironscales reports that such messages "pass SPF, DKIM, and DMARC" and blend into pools that carry billions of legitimate messages Template review at onboarding. Monitoring of new recipients and of the shape of volume. Reputation scanning of the URLs and domains in outbound content. A fast shutdown path at the abuse desk (Abuse Desk)
Relayed subscription bombing An attacker runs a script against a legitimate customer's unprotected signup form, and the ESP delivers thousands of confirmation and welcome messages to the victim Each message on its own is well-formed triggered mail. The ESP becomes the delivery channel for a denial-of-service (DoS) attack on a mailbox, and Spamhaus has listed ESP IP addresses for it. See Subscription Bombing Form protection (CAPTCHA, confirmed opt-in (COI) and rate limits) as a condition of service, verified at onboarding. Detection of signup anomalies per target address across the whole platform
API key compromise A key leaks in a public repository, client-side code or logs, or is phished from the developer. The attacker sends through the customer's warmed, authenticated identity Keys are long-lived machine credentials outside the login and multi-factor authentication (MFA) perimeter. A compromised key inherits the account's full sending history and reputation, and the damage is limited only by what the key is allowed to do. For containment, see Compromised Accounts Scoped keys (send-only, limited to a stream or domain), rotation, and partnerships for secret scanning. SendGrid documents that it automatically deletes keys its monitoring finds exposed on GitHub "within moments" and notifies the customer. Velocity caps for each key
Marketing mixed into the transactional stream A customer sends newsletters, promotions, win-back campaigns or "product update" campaigns through the transactional stream, either on purpose (to borrow its deliverability) or by gradual drift Transactional mail's inbox placement and its exemption from unsubscribe rules make it attractive cover. Mixed traffic raises the complaint rate of the transactional stream and degrades the shared transactional pool for every tenant A policy that defines the boundary in enforceable terms (below). Metrics for each template. Detection of changes in content and in recipient counts. Forced reclassification to the marketing stream
Dormant account activation An account integrated long ago, sending little or nothing, suddenly sends volume A dormant account with a valid key is exactly what an attacker with leaked credentials, or a sold or repurposed account, looks like. Against the account's own near-zero baseline any activity is anomalous, but only if someone watches each account's baseline Treat activation after dormancy as a reason to vet the account again, not as growth: hold volume at a probation cap, confirm the contact and use case again, and warm up again (compare the decay principle in IP Warm-Up: trust fades)

Several of these have marketing counterparts among the post-send triggers in the Vetting BCP: sending that stops and starts, sudden list growth, and content that changes after metrics change. The transactional versions differ because there is no list or campaign history to examine, so detection has to rely on data about individual messages.

Onboarding: vet the integration, not the list

The Vetting BCP asks a sender to show its list and its history. Ask a transactional sender a different question: does the use case it describes match the integration you are about to connect? A claim such as "a software-as-a-service (SaaS) app sending password resets" can be checked against concrete evidence.

The checks on corporate identity, WHOIS records and fraud signals in Customer Vetting still apply unchanged, because an API customer is still a customer. The table below covers only what is different.

Check What to ask or inspect Red flags
The application exists A live product URL, an app store listing or a staging demo. Does the business plausibly generate the message types it claims? No product you can inspect. A product category that does not match the message types (a content site that "needs" payment-failure notices). A brand-new domain combined with an urgent go-live
Template review Ask for the actual templates, or review them from the first sends. Each should name a specific trigger, use the customer's own brand and domain, and link only to domains the customer controls Templates that imitate other brands (banks, delivery companies, document-signing services, mailbox providers), which is the fake-transactional phishing kit. URL shorteners or third-party redirect domains. "The templates aren't ready" while volume is needed now
Legitimate trigger events For each message type: what user action sends it, roughly how often per user, and would the recipient expect it? Postmark's published definition is the clearest test: transactional mail is "one-to-one unique messages the recipient is expecting to receive," triggered by the user 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 or referral flow is a spam vector that needs its own limits (compare the web-messaging distribution controls in Compromised Accounts)
Expected volume and recipient profile Projected messages per day, the expected share of new and repeat recipients, and the expected mix of recipient domains. Record the answers: they become the baseline the ongoing controls compare against Volume that implies more users than the product can plausibly have. "Recipients are mostly new every day" for anything other than signup confirmation. Refusal to estimate
Form protection as a condition of service If a public web form triggers any message type (signup, invite, tell-a-friend, contact), require CAPTCHA and rate limiting, and COI for list additions, before you provision the account. Spamhaus explicitly expects ESPs to push customers to secure their signup forms, so make this a contract term, not advice (Subscription Bombing) Unprotected forms with "we'll add CAPTCHA later". Forms that send mail to any address a user enters (invite flows) with no deduplication or caps per address
Credential hygiene requirements Scoped API keys for each environment. No keys in client-side code. A documented ability to rotate keys. A named security contact for compromise notifications. This applies to keys the principle, from M3AAWG's Hosting Abuse Best Common Practices, of making security a contract term A single full-permission key shared across environments and staff. A key requested for an off-the-shelf script the customer cannot describe
Suppression practice How will the customer handle the bounces and complaints your webhooks return? Transactional streams still hard-bounce, and a sender who ignores bounce webhooks accumulates bounces without noticing No plan to consume bounce events. An expectation that the ESP's suppression can be bypassed freely (see the narrowly scoped stream override in Suppression-List Architecture)

Probation limits do the rest. For a marketing sender, the vetting process uses a test send sized by statistics. The transactional equivalent is the ladder of tiered rights from the Hosting Abuse BCP (see Customer Vetting). Give new API accounts low daily caps and restricted capabilities, raise the limits as the account shows clean behavior and a credible need, and treat each request for a higher limit as a moment to vet the account again. A request for a higher limit that outpaces the product's plausible growth is itself a warning sign.

Ongoing controls

The metrics below are industry practice, drawn from practitioner consensus and from the vendor practices documented above, not from a published BCP. No numeric thresholds are standardized, so calibrate them against your own platform.

  • Metrics for each template or message type, not for the account. A transactional account is a bundle of streams with different risks. Track volume, bounce rate, complaint rate and the mix of recipient domains for each template or message type, using tags as the event systems in Multi-Tenant Architecture do. Mixed traffic and abuse show up as one template diverging while the account as a whole still looks healthy. Postmark publishes account quality requirements, a complaint rate below 0.1% and a bounce rate below 10%, which shows an ESP focused on transactional mail enforcing numeric limits even on transactional traffic.
  • Detect changes in content. The templates reviewed at onboarding are the contract. Alert when the content of a "transactional" stream changes shape: message size or link count jumps, new outbound link domains appear, messages grow more similar to each other (identical bodies sent to many recipients are the mark of a broadcast), or subject lines pick up promotional words. This is the transactional version of the Vetting BCP trigger "content changes following significant changes in metrics". Here, though, a change in content is the leading indicator, because complaints arrive late.
  • Share of new recipients. Real transactional mail mostly goes to recipients the account has mailed before: an existing user resets a password or receives a receipt. Only signup confirmation flows lean toward new recipients. If a stream's share of never-seen recipients surges, especially while its recipient domains spread more widely, it is one of three things: a purchased list sent through the transactional stream, a relayed subscription-bombing flood, or a compromised key. Set a baseline for this share for each message type at onboarding (the "expected recipient profile" answer), and alert when it diverges.
  • Volume shape and velocity caps for each key. Triggered mail follows the daily curve of the application's user activity; batch sends do not. Limit the capacity for bursts that are not triggered. A hard ceiling on messages per minute or per hour for each API key, sized to the account's stated use case, turns a leaked key or a hidden campaign from a platform-wide incident into a throttled trickle. Legitimate batch needs, such as digests or notices of new terms of service, should be declared and routed to the broadcast stream, which is exactly what the caps encourage.
  • Watch for dormancy. Flag accounts that have been idle longer than a set period. When one becomes active again, apply a probation cap and a human or automated verification step before restoring its previous limits. Combine this with forced rotation or expiry of API keys that have gone unused for a long time, because an unused live credential is only a liability.
  • Signup form telemetry across all customers. For hosted signup flows, or flows visible through webhooks, monitor confirmation sends per target address and per target domain across all customers. Subscription Bombing details the related duties: suppression for each address and anomaly detection.
  • Scan outbound content on the transactional path. Complaint feedback is muted and slow, so phishing that only feedback loops (FBLs) catch has already reached inboxes. Run link and domain reputation checks and brand impersonation checks inline on transactional streams (the content-filtering layer in Compromised Accounts), with a ladder of challenge, quarantine and reject for borderline hits.

Policy terms that keep the boundary enforceable

The line between transactional and marketing mail only works in practice if your terms of service define it in terms that can be decided, and reserve your right to act on it. These are the documented approaches:

  • Define transactional mail by its trigger and the recipient's expectation, not by topic. Postmark's public definition says transactional mail is one-to-one, unique, expected by the recipient, triggered by the user, and generally does not need an unsubscribe link. It adds an explicit exclusion: "multiple recipients receiving the same content" that is not triggered by an event fails the test. Support and compliance staff can apply that test to a sample of messages without arguing about intent. A definition by content category ("receipts, resets…") invites the argument that a product update is a notification; a definition by trigger does not.
  • Make the separation physical, then require it in the contract. In Postmark's Message Streams model, transactional and broadcast traffic "does not mix… including IP ranges," and its policy states that bulk messaging "should not be sent through Transactional Message Streams." The acceptable use policy (AUP) clause can then point to something observable, that the customer sent broadcast-style mail through the transactional stream, instead of an argument about whether a newsletter is "really" a notification. For how the pools work, see Multi-Tenant Architecture.
  • Reserve the right to reclassify, not only to terminate. Against mixed traffic, the most useful enforcement action is usually to move the offending traffic to the marketing stream, where the obligations for consent, unsubscribe and suppression apply (List-Unsubscribe, Consent Methods). Keep suspension for customers who refuse. The policy should state that the ESP classifies streams, may reclassify traffic, and may require unsubscribe headers on messages it considers non-transactional. This is practitioner consensus. ESPs publish a way to ask about edge cases (Postmark asks for a sample message to classify) rather than exhaustive lists of categories.
  • Tie the policy to the legal definition where one exists. The US CAN-SPAM Act's category of "transactional or relationship" messages and its primary-purpose test (CAN-SPAM) give the boundary legal force. A customer who disguises commercial mail as transactional is not only breaking the AUP. It is misclassifying mail that the law says needs an opt-out, and that compliance argument persuades customers' legal teams when deliverability arguments do not.
  • Make form security and credential hygiene conditions of service. Contract clauses that require bot protection on forms that trigger mail, prompt notice of a breach or key compromise, and cooperation with remediation turn the onboarding requirements above into enforceable obligations. This is the Hosting Abuse BCP's practice of making security a contract term. These clauses also give the abuse desk clear terms of service to cite when it notifies, asks for remediation and suspends, as described in Abuse Desk Operations.
  • Publish the numeric limits. Publishing hard ceilings on complaint and bounce rates for transactional streams, as Postmark does, removes the "but it's transactional" defense from enforcement conversations. The stream label changes how mail is routed, not the quality it must meet.

Sources. The material from the M3AAWG Vetting BCP and Hosting Abuse BCP follows the summary in Customer Vetting. Neither document addresses transactional or API senders specifically, which is the gap this guidance fills. Postmark's definitions, stream separation policy and quality thresholds come from its published support articles. The pattern of phishing through ESP abuse comes from Ironscales' published analysis. The handling of exposed API keys comes from Twilio SendGrid's support documentation and GitGuardian's remediation guidance. Sections described as practitioner consensus reflect common ESP operating practice without a single authoritative published source. No thresholds are stated beyond the cited vendor figures.

Check your own record

The free check reads what your domain publishes in DNS.

In this topic

All 16 in ESP Operations →