Subdomain Verification for Email Authentication
Introduction:
Teams working in fraud prevention know that verifying whether an email address is real matters. A solid email check helps separate legitimate addresses from junk. This article describes a simple method for checking email addresses by looking at their subdomains.
Problem Definition:
A common problem in email validation is telling real corporate emails apart from junk or malicious mail. Standard verification methods often miss that distinction, which leads to false negatives or false positives.
One signal that often gets ignored is the presence of subdomains in corporate email domains. A corporate domain is likely to have multiple subdomains that support business services. These may include virtual private network (VPN) endpoints, drives, email servers, and other internal company services.
Problem Resolution:
The solution is to check whether a domain has subdomains. For that, we can use the SecurityTrails Subdomains API service. The API makes it possible to inspect subdomains linked to a given email address.
In the decision flow, the process starts by calling the SecurityTrails Subdomains API to check for subdomains linked to the domain. Then rules run based on the result of that check. The presence of subdomains can indicate that the domain belongs to a legitimate corporate entity, which improves the email verification process.
Proposed Rules for the Fraud Rule Engine:
To make this practical, the check needs to be integrated into the existing fraud rule engine. Here are rules that can be implemented:
- Data source call: Make an initial call to SecurityTrails Subdomains API to check for subdomains associated with the domain from the email address.
- Rule 1: If no subdomains are found, flag the email address as potentially fraudulent.
- Rule 2: If subdomains are detected, run additional checks for common business-related subdomains such as 'vpn', 'email', 'drive', etc.
- Rule 3: If none of these business-related subdomains are found, flag the email address as potentially fraudulent.
- Rule 4: If these business-related subdomains are present, validate the email as legitimate.
This approach uses subdomains as a criterion for email validation to separate genuine corporate emails from junk mail. Adding these rules to the fraud rule engine improves the accuracy of the email verification process and supports stronger anti-fraud operations.
Frequently asked questions
Should a subdomain check ever be enough to mark an email address legitimate?
No. A domain’s subdomains are a weak signal: legitimate businesses may have few visible subdomains, and fraudsters can use domains with business-like names. Treat the result as enrichment, then combine it with checks such as mailbox verification and the account’s other risk signals. Approving an address on subdomain presence alone can create a gap that attackers can exploit.
How should we set the cutoff for treating subdomains as a positive signal?
Do not use a minimum subdomain count as a universal cutoff. The number and naming of subdomains vary by organization, and names such as “vpn” or “drive” do not prove that a domain belongs to a legitimate business. Start by treating recognized business-related names as a modest positive signal, then adjust their weight against your own confirmed fraud and false-decline outcomes.
How should we test the rule before using it to approve signups?
Run the subdomain check in shadow mode against historical signups with known outcomes, then compare results across business and consumer email domains. Measure whether the signal changes confirmed fraud and false declines, not just how often subdomains are found. Keep a time-separated test set, since patterns that fit past data may not hold for new signups.
What should the fraud rule do when a lookup returns no data or times out?
Separate a successful lookup with no subdomains from a failed or timed-out lookup. A lack of results is not proof of fraud, and a provider failure says nothing about the email address. Send unavailable results through your existing risk checks or a neutral review path, and track provider failures separately so they do not quietly become fraud declines.
