The verification email is a reflection primitive

An email verification flow that sends mail to any address submitted, without proof the requester controls that address and without a per-destination rate limit, is a reflection primitive. The flaw is not in the SMTP daemon. It sits one layer up, in the application that decides to send. The flood that lands in the victim’s inbox is assembled from legitimate transactional mail - every message SPF-aligned, DKIM-signed, DMARC-passing, dispatched by a vendor the victim already trusts. There is no CVE for this. That absence is the finding.

The pattern is old. Verification by spam means treating the act of sending as the act of checking. A service wants to confirm an address is real and reachable, so it mails a confirmation link and waits for a click. Reasonable in isolation. Weaponizable at scale, because the address that receives the message is chosen by the requester, and the requester is rarely the owner. The send is unauthenticated intent acting on an authenticated channel.

Three weaknesses combine. CWE-770, allocation of resources without limits or throttling - the endpoint accepts an unbounded rate of send requests. CWE-799, improper control of interaction frequency - throttling, where present, keys on source IP rather than destination address, so rotation defeats it. CWE-204, observable response discrepancy - the verification response differs for a known account versus an unknown one, which leaks account existence and converts the same endpoint into an enumeration oracle. Each is individually mundane. Together they turn a signup form into a directed-send machine.

The worst offenders are single-opt-in flows and password-reset forms. A double-opt-in newsletter at least caps its damage at one confirmation per request and discards the address if the link is never clicked. A reset form that mails a link regardless of whether the account exists sends on every request, confirms or denies the account in the same response, and is reachable without authentication by definition. Those endpoints exist on nearly every service on the internet. The set of cooperating senders an attacker can recruit is effectively the entire population of sites that mail a human after a form submission.

The exploit path needs no memory corruption and no credential. A script submits the victim’s address to a large set of unrelated services that each mail a confirmation or reset link. Each service contributes one or a few messages. None of them is compromised. None of them misbehaves by its own logic. The aggregate is thousands of messages to one mailbox inside a short window. The victim’s own vendor relationships supply the volume. The attacker supplies only the target address and the list of endpoints.

Source-IP rate limiting is the control that fails first. It assumes abuse concentrates at one origin. Residential and mobile proxy pools price a clean IP at a fraction of a cent, so the per-service request count stays under any threshold the service bothers to enforce, and the destination - the only field that actually identifies abuse - is never aggregated across origins. Reputation systems fail next. The sending IPs belong to the legitimate vendors, sit on allow-lists, and carry years of clean history. Nothing in the message warrants a low score.

Email bombing is rarely the objective. It is cover. The flood is usually concurrent with a single message the attacker needs buried - a fraud alert, a card-not-present transaction confirmation, a password-change notice, a wire approval. The target message arrives in the same window and is lost under hundreds of confirmations. By the time the inbox is triageable, the fraudulent action has cleared. Krebs documented subscription bombing used exactly this way in 2016: place a fraudulent order, then list-bomb the victim to drown the merchant’s confirmation and the dispute-window notices.

Black Basta operators ran the same primitive as a social-engineering opener through 2024. They bombed a target’s inbox with subscription confirmations, then contacted the same person over Microsoft Teams from external tenants, impersonating internal IT or a help desk responding to the spam incident. The flood manufactures the pretext. The call closes it. Rapid7 and ReliaQuest both documented operators walking victims into Quick Assist and AnyDesk sessions from there. The chain maps to T1566.004, spearphishing voice, and T1656, impersonation. The bombing is the resource-exhaustion stage that makes the victim receptive - closest enterprise-technique fit is T1499, endpoint denial of service, applied to a human inbox rather than a daemon.

The same logic exists below the application, in sender callback verification. A receiving server, handed an inbound message, opens an SMTP session back to the purported sender’s MX and issues RCPT TO to confirm the sender address resolves. Spoof MAIL FROM as the victim across many such servers and each one independently opens a probe against the victim’s MX. The verification mechanism becomes a reflected, distributed load against a domain that sent nothing. Backscatter from misdirected bounces is the older cousin of the same fault - verification work performed on behalf of an attacker-chosen address. VRFY and EXPN did this overtly and are disabled almost everywhere now. Callback verification does it quietly and is still deployed.

In telemetry the attack is near-invisible at the message layer, and that is the entire point. Every confirmation email is real. SPF passes. DKIM validates. DMARC aligns. The sending IPs hold clean reputation. A secure email gateway scoring messages individually finds nothing to quarantine, because nothing about any single message is wrong. The signal lives only in aggregate. The detections that work are volumetric and behavioral: inbound message rate to a single mailbox exceeding its baseline by orders of magnitude; a sharp rise in the proportion of messages classed as list-subscription or double-opt-in confirmations; high sender-domain diversity with low per-domain volume, which is the inverse of an ordinary spam campaign. A SIEM rule counting confirmation-class inbound mail per recipient per five minutes catches the flood.

The correlation that catches the intrusion is the next step - an inbound Teams message or external phone contact to the same identity within hours of the spike. That join, mail-volume anomaly to external collaboration contact, is where the social-engineering chain becomes visible. Few shops build it. The mail-volume rule and the collaboration-platform logs usually live in different pipelines owned by different teams, and the window between the two events is short enough that an analyst working the mail alert alone closes it as nuisance spam before the call lands.

On the sending side - the abused service’s own view - the evidence is in application and WAF logs, not endpoint EDR. There are no Sysmon process events here; nothing executes on a host. The marker is a burst of POST requests to the verification or registration endpoint, one destination address repeated across rotating source IPs, or many destinations from a narrow ASN, returning 200 or 202 with a send enqueued each time. An endpoint that emits outbound mail per request and logs only HTTP status is blind to its own use as a relay.

The enumeration variant leaves a quieter trace. Differential responses - distinct status codes, distinct response bodies, or measurable timing deltas between known and unknown addresses - are individually valid HTTP transactions. The pattern is the tell: thousands of verification or reset requests walking an address list, most returning the negative response, a minority returning the positive. Under the Privacy Act, the account-existence disclosure is itself the issue; a verification endpoint that confirms which addresses hold accounts is leaking personal information through a side channel, before any flood is sent.

The correction is not at the mail server and not a content filter. Sending must require proof of intent before it happens, not after. Per-destination rate limiting, not per-source - one address receives a bounded number of verification messages per hour regardless of how many origins request them. A challenge on the send-triggering endpoint, Cloudflare Turnstile or equivalent, that raises the cost of scripted submission above the value of a single reflected message. Uniform, constant-time responses to every verification and reset request, so existing and non-existing accounts are indistinguishable and the enumeration oracle closes. And the architectural fix the title states: do not treat sending as verifying. Validate syntax and MX, then issue a tokenized challenge the requester completes through a channel already bound to them.

Residual exposure survives all of it. Even with per-destination limits and challenges across one service, the attacker needs only enough cooperating services to clear the bar, and no single endpoint sees abusive volume because the abuse is distributed across thousands of compliant senders. The defense cannot be unilateral at the application and complete at the same time. Detection stays volumetric, on the receiving side, because the messages remain individually legitimate and authenticated. A confirmation flood against a named user is a precursor, not a nuisance - the inbox event is stage one, and the contact attempt that follows is the one that matters. Route it to the security team while the spike is still live, not after the call comes in.