Domain screening is not mailbox verification, and the difference decides where policy lives

MX presence cannot tell you anything about disposability, for the simple reason that a disposable provider has to accept mail to be worth using. The walkthrough's own sample makes the point without comment: `[email protected]` comes back with `hasMxRecords: true` and `disposable: true` in the same object ^[9], and the author states the general case, that a domain can have valid MX records and still be disposable ^[10]. So the DNS lookup is not a fraud signal. It is a deliverability precondition. No MX means your confirmation mail has nowhere to land, whoever the user is.

That is the case for keeping the signals apart, and the post argues it well: a Gmail address is a free provider and that alone is not suspicious ^[2], and a community site allowing every free provider needs different handling from a B2B trial that asks for extra verification on the same input ^[15]. Then the example policy consults `result.riskLevel` and nothing else, mapping LOW to ALLOW, HIGH to BLOCK, UNKNOWN to RETRY_OR_REVIEW ^[8]. Count the per-signal fields that reach that decision and you get zero out of five ^[16]. Shipped as written, the separation is decorative, and the thing you are actually deploying is a boolean with extra JSON around it, scored by someone else's list.

The part worth copying is the third risk level. A DNS error or timeout produces UNKNOWN rather than HIGH ^[6], on the stated grounds that an infrastructure error should not be treated as a fraudulent user ^[7]. Most homegrown validators do not have that state, which is how outages turn into support tickets from customers who did nothing wrong. The post also leaves the resolution open: block, retry, or allow with additional restrictions is presented as the implementer's call ^[14].

One detail in the reference handler deserves a second look. The rejection returns the vendor's `reason` string to the caller ^[12], and in the sample that string is "Disposable email detected" ^[9]. Anyone cycling through throwaway domains gets a free oracle telling them which family tripped the filter and which to try next. The key stays on the server, which the post is explicit about ^[11]; the classification logic leaks anyway, through the error body.

None of this is verification, and the post does not pretend otherwise. An MX record cannot show that the mailbox exists, that it belongs to the person typing, that the server will accept a message, or that the user will still be reachable later ^[3]. Ownership still needs a confirmation email or a one-time code ^[5]. The alternative, SMTP probing, is slow, unreliable, and rejected by mail servers ^[4], which is the actual argument here: you are not choosing between screening and verifying, you are choosing between a cheap DNS-and-list check in front of the confirmation email and an expensive handshake that most receivers will refuse. The screen's return is narrow and real. Fewer confirmation messages sent to inboxes that expire before anyone reads them, and fewer trials opened by an address that will not exist tomorrow ^[17].