Vetting Automation & Third-Party Risk Signals

Customer Vetting covers what to check — the M³AAWG questionnaires, red flags, and manual-review methodology. This article covers with what tools and how to automate it: the third-party signal vendors an ESP can wire into its signup and onboarding flow, and the architecture that composes those signals into risk scores, gates, and progressive trust. The M³AAWG Hosting Abuse BCP already mandates the endpoints ("fraud-score prospective accounts and auto-reject below threshold," "put limits on new accounts," "tiered rights allocation" — see the fraud-prevention practices); this article is the implementation layer.

Provenance note for the whole article: there is no published industry standard for composing vetting signals — the composition patterns below are practitioner consensus and inference from what major platforms publicly document about their own onboarding (attributed by name throughout). Vendor capability claims are taken from vendor documentation; where accuracy or effectiveness is asserted only by the vendor's marketing, that is flagged. No third-party risk score has independently audited accuracy figures — treat every vendor accuracy claim as marketing.

Related: Outbound Monitoring (the post-onboarding behavioral signals that feed re-scoring), Multi-Tenant Architecture (per-tenant reputation policies and automated pausing — the enforcement side of the same machinery), Compromised Accounts (registration-abuse patterns; distinguishing hijacked customers from fraudulent signups), Subscription Bombing (why the ESP's own signup form needs the same defenses it demands of customers).

Two different questions, two different signal sets

Vetting automation answers two distinct questions that are easy to conflate:

1. Is this signup a fraudulent/abusive actor? (spammer, snowshoe operator, stolen-card fraudster, phisher) — answered by IP/device intelligence, payment-fraud signals, domain history, and identity checks on the customer.
2. Is this customer's data dangerous? (purchased lists, harvested addresses, trap-laden files) — answered by email-validation/risk APIs run against the customer's uploaded lists, plus the acquisition questions from the vetting questionnaire.

A customer can be legitimate with terrible data, or superficially clean with fraudulent intent. Automation must score both axes; conflating them produces gates that pass polished fraudsters and reject honest small businesses with old lists.

The signal-vendor landscape

Email-address validation vs. risk scoring

Two overlapping product classes that vendors bundle but that serve different vetting purposes:

• Deliverability validation — "will this address accept mail?": syntax, MX existence, SMTP-level mailbox probing, catch-all detection, role-account and disposable flags. This is list-hygiene tooling (see List Hygiene) repurposed for vetting: run it on a customer's uploaded list sample and the aggregate profile (invalid %, role-account %, disposable %, catch-all %) is a strong proxy for acquisition quality — high invalid rates indicate old or purchased data, per the same logic Mailchimp documents for Omnivore (below).
• Risk scoring — "is this address likely to hurt me?": trap likelihood, complaint history, engagement prediction. Inherently probabilistic and vendor-proprietary; useful as a relative ranking signal, not a verdict.

Vendor (class exemplar)	Documented capabilities	Notes
Kickbox	Result classes deliverable / undeliverable / risky / unknown with reason codes; proprietary Sendex quality score (0–1) per address	Score semantics documented; specific cut-off thresholds circulating in reviews (e.g., "0.7 = safe") are practitioner heuristics, not vendor-published guarantees
ZeroBounce	Statuses valid / invalid / catch-all / spam_trap / abuse / do_not_mail / unknown; "AI scoring" 0–10 engagement prediction; activity data (past-year engagement)	The abuse status (habitual spam-button clickers) and spam_trap flag are vendor-proprietary datasets — coverage and accuracy are marketing claims, not independently verified; genuine trap operators do not sell trap lists (see Spam Traps)
BriteVerify (Validity)	Deliverability-focused verification: valid / invalid / accept-all / unknown	Representative of the pure-validation class (with NeverBounce, Emailable, etc.) — no fraud-risk layer

Vetting usage pattern (practitioner consensus): validate a random sample of any list a prospect brings (mirroring the M³AAWG test-send methodology's sampling logic); gate on the aggregate profile, not individual addresses. A list that is 15% undeliverable was not built by confirmed opt-in, whatever the questionnaire says.

IP, device, and identity fraud scoring

Scores the signup itself: the IP, device, email, and identity the prospect used to register.

Vendor	Documented capabilities	Score model
IPQualityScore (IPQS)	Proxy/VPN/Tor detection, IP reputation, "abuse velocity" (recent abusive activity from the IP), device fingerprinting, email risk API (disposable detection, "history of fraudulent behavior online"), phone reputation	0–100 fraud score; IPQS's own docs treat ≥90 as high risk (vendor-recommended threshold, tune to your own outcomes)
MaxMind minFraud	Transaction risk scoring over IP + email + address + payment fields; email/domain intelligence including domain first_seen on the minFraud network (recorded since 2019) and a domain risk score; IP geolocation lineage (GeoIP)	Risk score 0.01–99, documented as calibrated probability of fraud (score 20 ≈ 20% chance)
Sift	Per-abuse-type ML scores — payment fraud, account abuse, content abuse — trained on the customer's own event stream plus Sift's cross-customer network; event-driven API (you send signup/login/content events, poll or receive scores)	0–100 per abuse type; a user can score high for one abuse type and low for another

Cross-network vendors (minFraud, Sift, IPQS) derive their value from seeing the same actor across many customers — which is also their weakness: coverage claims ("data from hundreds of millions of users") are unverifiable marketing, and false-positive behavior on your population is unknowable until you measure it. The independently documented facts are the API contracts and score semantics above.

Deliverability-specific overlays on the same signals: signup IP on Spamhaus AuthBL (credential-stuffing sources — see Blocklists & Spamhaus) or signing up through an anonymizing proxy are the automated equivalents of the Hosting Abuse BCP's registration-abuse red flags described in Compromised Accounts.

Disposable / temporary-domain detection

Signups using throwaway mailboxes correlate strongly with trial abuse and snowshoe registration (practitioner consensus; no published base rates).

• Open-source lists: the community-maintained disposable-email-domains blocklist (maintained since 2014, evidence-required submission process) is the de-facto free baseline; several auto-generated forks track fast-churning providers.
• Commercial detection (IPQS, ZeroBounce, Kickbox, UserCheck-class) claims fresher coverage of churning disposable providers — plausible but unaudited.
• Design caveat: disposable-domain providers rotate domains precisely to evade static lists; treat list-miss as "unknown," not "clean." A newly registered domain signal (below) catches much of the churn the lists miss.

Domain intelligence: the customer's sending domain

The domain a prospect wants to send as is the richest single vetting object. Checks, all automatable:

Check	Mechanism	Signal
Registration age	RDAP/WHOIS creation date	Domains registered days ago claiming years of sending history contradict the questionnaire; new domains carry near-zero reputation (Sending Infrastructure Practices)
Zero-reputation window	Spamhaus ZRD lists newly registered and previously dormant domains for 24 h, with return codes encoding domain age in hours	Documented Spamhaus dataset (DQS-exclusive); a prospect whose domain is on ZRD at signup is by definition un-vettable on history
Blocklist history	Spamhaus DBL (spam domains, with return codes distinguishing spam / phish / malware / abused-legitimate), SURBL-class equivalents, via DQS or data feeds	Spamhaus explicitly markets domain-reputation data for ESP prospect vetting and risk-based customer pooling; the abused-legit distinction matters — it flags a compromised customer, not a bad one
DNS posture	SPF/DKIM/DMARC records present and sane; MX exists; nameserver quality	A prospect with no DNS control cannot authorize the ESP (Customer Domain Authentication); DMARC at enforcement on a domain the prospect claims not to control is an impersonation tell
Web presence	HTTP fetch of the domain: real site vs parked page vs template; content-category match against stated business	Parked or empty domains claiming an established business are a classic snowshoe pattern (practitioner consensus)
Prior-IP reputation	Blocklist and SNDS/reputation lookups on the IPs the prospect says it mailed from	Automates vetting-questionnaire question "which IPs did you previously mail from"
Corporate registry / WHOIS transparency	RDAP registrant data (post-GDPR: heavily redacted), business-registry APIs	Automates entity verification; expect low WHOIS yield and fall back to registry/manual checks — see the 2011-caveat in Customer Vetting

Payment-fraud signals as spam predictors

Stolen-card signups and spam operations overlap heavily — spammers don't pay with their own cards, and serial rebillers churn payment identities (the Hosting Abuse BCP's "frequent changes of payment information" trigger). If the ESP takes payment at signup, the payment processor's fraud stack is a free vetting signal:

• Stripe Radar (class exemplar): documents a 0–99 ML risk score per payment, with normal / elevated / highest risk levels (Radar for Fraud Teams defaults: elevated ≥65, highest ≥75) and risk insights explaining contributing factors; trained across Stripe's network. Adyen, Braintree, and Kount publish equivalent scores.
• Signals worth piping into vetting: payment risk score/level, BIN country vs claimed business country mismatch, prepaid/virtual-card BINs, card-testing velocity, and later chargebacks (a chargeback on an active sending account is a strong terminate-and-review trigger).
• The correlation "payment fraud predicts spam" is practitioner consensus, not a published study — but it is baked into the M³AAWG Hosting Abuse BCP's registration-abuse guidance (stolen/disposable cards as the paid-account abuse signature).

Breach and abuse-history lookups

• Have I Been Pwned (HIBP): documented v3 API — breaches/pastes/stealer-logs by email address, domain search for owned domains; keyed subscription tiers. Vetting relevance is indirect: a signup email appearing in recent stealer logs raises account-takeover risk (require stronger auth), and it is a standard input to fraud stacks. An email appearing in no breach ever can paradoxically indicate a newly minted identity — several fraud vendors (IPQS, minFraud first_seen) use "digital footprint age" this way; the interpretation is industry practice, not documented fact.
• Internal deny-history: the highest-value "abuse-history lookup" is your own — the Hosting Abuse BCP's "keep records of previously terminated fraud accounts and match new signups against them." Match on email, domain, payment fingerprint, device fingerprint, and (with care) IP range. No vendor sells this; build it. Terminated-customer re-signup under a fresh identity is the single most common vetting failure mode reported by abuse-desk practitioners.

Automation architecture

Composing an onboarding risk score

The pattern used across the industry (inference from platform behavior plus fraud-stack convention — no published ESP scoring formula exists):

1. Collect signals at signup (synchronous, budget ~1–2 s): IP/proxy score, disposable check, domain age/ZRD/DBL, payment risk if applicable, internal deny-history match.
2. Enrich asynchronously (minutes): web-presence fetch, prior-IP reputation, breach lookups, list-sample validation once a list is uploaded.
3. Combine into a single score plus hard-fail overrides. Two composition rules matter more than the weighting math:
   • Hard fails bypass the score: internal deny-list match, DBL-listed sending domain (non-abused-legit codes), confirmed stolen card. No weighted average should launder these.
   • Weight by evidenced predictiveness, then recalibrate: start with vendor-recommended thresholds, log every signal on every signup, and after enough outcomes (terminations, complaint-rate breaches, chargebacks) re-weight against your own abuse labels. A score you cannot back-test is theater. Do not import anyone else's numeric thresholds — including the vendor examples quoted above — without local validation.
4. Record the full signal snapshot with the decision — required for appeals, recalibration, and for the abuse desk when the account later misbehaves.

Gate design: four bands

Practitioner-standard band structure (the bands are consensus; the boundaries are yours to calibrate):

Band	Action	Design notes
Auto-approve	Full provisioning at the entry rung of the trust ladder (never unlimited)	Auto-approve ≠ unmonitored: every approved account still enters outbound monitoring and the ladder below
Sandboxed / limited send	Account active but capped: low daily volume, verified-recipient-only or own-domain-only sending, shared low-tier IP pool, restricted API scopes	The SES sandbox is the canonical documented example (below); routes risk into a quarantine pool per Spamhaus's risk-based pooling guidance and Multi-Tenant Architecture
Manual review	Queue for a human with the full signal snapshot; account inert or sandboxed while pending	The vetting questionnaire from Customer Vetting is the review script; SLA matters — review queues that take days leak legitimate customers to competitors
Reject	Decline service	For fraud-scored rejects, follow the abuse-desk rule: no data retrieval, no explanation of which signal fired (Abuse Desk Operations); for policy rejects (prohibited content category), state the policy plainly

Two structural rules: the reject band should be narrow and dominated by hard fails (weighted scores near the boundary belong in manual review — the cost asymmetry between rejecting a good customer and sandboxing a bad one favors sandboxing); and band thresholds must be tunable at runtime without a deploy, because attack waves require tightening within hours (compare the fleet-wide response patterns in Subscription Bombing).

Progressive trust ladders

The M³AAWG "tiered rights allocation" principle, automated: initial caps lifted on demonstrated clean history rather than on request alone. Documented examples at major platforms:

Platform	Documented mechanism
AWS SES	Every new account starts in the sandbox: max 200 messages/24 h, 1 msg/s, recipients restricted to verified addresses/domains. Production access requires a human-reviewed request describing use case and mail practices (typically 24–48 h); typical initial production quota 50,000/day, later raised automatically or on request based on sending metrics. Per-region — trust does not transfer.
Mailgun	New/flagged accounts get probation: hourly sending limitation (commonly cited at 100 messages/hour/domain) until the customer completes business verification — a human identity/use-case review.
Postmark	Every new account is manually reviewed; until approved, sending is restricted to the account's own verified domains. Review typically <24 h weekdays. Post-approval there is no fixed daily cap — enforcement is metric-based (complaint <0.1%, bounce <10%).
Mailchimp Omnivore	Data-side gating rather than volume gating: on every import or first-send to new addresses, the Omnivore system predicts trap/bounce/complaint likelihood for the cohort and blocks sending to audiences whose predicted rates are too high — i.e., the list itself must earn trust.

Design lessons from the set: (a) the entry rung restricts recipients and rate, not just volume — own-domain-only sending (Postmark) is a cheap, strong fraud filter because spammers need to reach strangers; (b) promotion combines automated metric checks with a human touchpoint for the big step (sandbox→production); (c) ladders also go down — Mailgun re-flags established accounts back into probation, and SES pauses tenants on findings (Multi-Tenant Architecture). Rungs above entry (larger caps, dedicated IPs, elevated API scopes, DKIM for arbitrary domains) should each carry their own metric prerequisites; the Hosting Abuse BCP's ~12-months-clean bar for elevated privileges is the only published tenure number in this space.

Continuous re-scoring

Onboarding vetting is a snapshot; the risk score must be a living value. Feed it from outbound monitoring:

• Behavioral deltas as re-score triggers: the M³AAWG ongoing-monitoring triggers (Customer Vetting) — sudden list growth, content/privacy-policy changes after metric shifts, payment-info churn, stop-start sending — plus bounce/complaint/trap telemetry and per-tenant reputation findings.
• Vendor re-query on trigger, not on schedule: re-running paid fraud lookups on every customer nightly is expensive and low-yield; re-query when a behavioral trigger fires (new sending domain added → domain-intelligence battery; new card → payment signals; anomalous login → IP/device signals).
• Score movements re-enter the same gate bands: a degraded score moves an account down the trust ladder (tighter caps, quarantine pool, strict reputation policy) or into manual review — reusing onboarding machinery for lifecycle enforcement keeps one policy surface instead of two.
• Route by prior use: before enforcement, run the compromised-vs-malicious differential from Compromised Accounts — a pattern of previous good behavior means account-recovery flow, not fraud flow.

Integration patterns

• Synchronous gate at signup: only signals that answer within the page-load budget; everything else async. Fail open into the sandbox band, never into auto-approve — a vendor outage should degrade to "more accounts start limited," not "vetting off." (Practitioner consensus.)
• Asynchronous enrichment via queue + webhook: vendors with event models (Sift's event API, Stripe Radar's webhook events, HIBP polling) push score changes; your consumer maps them onto the customer risk record. Idempotency and out-of-order handling are the usual webhook disciplines.
• Batch re-validation: list-validation vendors operate file-batch APIs (submit list, poll, fetch results) — wire list uploads through this path with the send blocked or sampled until results return, Omnivore-style.
• Cache with TTLs matched to signal volatility: domain age is immutable; blocklist status changes hourly (Spamhaus DQS answers propagate in minutes); IP fraud scores decay in days. Do not cache hard-fail signals past their volatility window.
• One internal risk-record schema: normalize every vendor's score into your own record (signal, raw value, normalized contribution, timestamp, vendor) so vendors are swappable and the appeal/audit trail is uniform. Vendor lock-in through score semantics is real — a "90" means different things in every API above.
• Contractual/ToS check: most fraud and validation vendors restrict resale and retention of their data; suppress vendor raw data from customer-facing surfaces and appeals messaging (which also avoids teaching fraudsters your signal set).

False positives and appeal paths

Every automated gate wrongly rejects some legitimate customers — shared-IP/VPN users, new businesses with new domains, nonprofits with old-but-consented lists. Design for it:

• Appeal = escalation to manual review with the signal snapshot attached, worked by staff who can override any automated decision. The overwhelmingly common practitioner pattern; there is no published standard.
• Tell the customer what to provide, not what fired: request the vetting-questionnaire evidence (business registration, consent records, prior metrics) rather than disclosing which signal tripped — disclosure teaches evasion, the same logic as vague rate-limit pages in Compromised Accounts.
• Measure the false-positive rate: track appeal volume, appeal-overturn rate, and post-overturn behavior (overturned accounts that later stay clean are your false-positive ground truth); feed both directions into recalibration.
• Time-box the sandbox: a legitimate customer stuck at the entry rung with clean metrics and no promotion is a silent false positive — alert on accounts that stall on the ladder despite clean history.

Where human review must remain

Automation narrows the human queue; it does not empty it. Keep humans on:

• Edge cases and boundary scores — anything the score cannot place confidently; the score's job is to make the human queue small and well-briefed, not to eliminate it.
• High-value and high-volume accounts — a prospect wanting millions/month deserves the full M³AAWG questionnaire and a compliance conversation regardless of a clean automated score; the blast radius of a wrong auto-approve scales with volume (Multi-Tenant Architecture: aggregate liability is never delegated).
• Regulated and sensitive content categories — financial services, health, political, adult, gambling, CBD: category-policy judgment plus jurisdictional rules (compliance/) that no fraud score encodes; automated content-category classification can route to the right reviewer but should not decide.
• The sandbox→production promotion at meaningful volume — the step every documented platform above human-gates.
• Appeals and terminations — both directions of the highest-stakes decisions.
• Recalibration itself — someone must own the score: review weights against outcomes, watch for drift and for demographic skew in false positives, and decide when a vendor signal has stopped earning its cost.