Email address profiling
Email profiling is a practical way to assess customer quality across industries. In fintech and insurance, it can support credit risk management and actuarial machine learning models.
Each part of an email address tells you something different. The username shows naming patterns, transparency, nicknames, and randomness. The domain, the part after @, provides operational and ownership signals.
Username profiling produces features you can use for scoring and for detecting gibberish email addresses. Feature creation often focuses on these:
- First name present
- Last name present
- Number present
- First name only
- Levenshtein distance from first name
- Levenshtein distance from last name
These indicators are useful, but they are not simple good or bad signals. Combine them with other attributes in predictive modeling.
Domain name profiling usually comes down to a few checks:
- DNS information (MX records, domains)
- Disposable, junk, or temporary email detection
- Email provider
Some domain-based rules are simple. If an address is not deliverable, do not send to it. Check MX DNS records and WHOIS. MX records work like postal routing codes. They define where mail should go. If none exist, the email will not be delivered. WHOIS shows whether the domain exists and who owns it. If the domain does not exist, do not send the email.
Next, detect disposable or temporary mailboxes. If someone provides a temporary mailbox like Guerrilla Mail, they likely do not plan a long-term relationship. These services are common in anti-fraud work because they are easy to use, and users can create many addresses quickly.
Then detect the email provider. Free email differs from business-hosted services. You can score identification of, for example:
- Free email provider (Gmail, Hotmail, …)
- Educational institution
- Business Outlook
- Business G Suite
- Generic web hosting email provider
- Self-hosted Outlook
- Other self-hosted email server
The service type behind the email can signal cost and operational maturity. Free email has no direct cost. Cloud solutions for companies add subscription costs. Running a self-hosted Outlook server requires licenses and IT support. For that reason, provider type can be a useful predictor in your models.
Lastly, consider catch-all email addresses. Some domains route all incoming emails to one mailbox. That can be negative if fraudsters reuse many domains in a short period. It can also be positive if someone owns a personal domain but does not run a full mail system.
Frequently asked questions
How should I use username and provider signals in a fraud score?
Treat username structure, provider type, and domain checks as supporting features, not standalone proof of fraud. Test whether each feature adds predictive value beyond your existing device, payment, and account signals, then keep the features that improve decisions on later data. Recheck performance by channel and customer segment because email habits vary.
Where should I set the cutoff for an email-based fraud score?
Set the cutoff against the expected loss from fraud and the cost of reviewing or declining legitimate customers. Compare candidate cutoffs on data that was not used to train the model, and check both fraud capture and false declines. There is no reliable universal cutoff for email features because their value depends on the product, fraud mix, and other controls.
Should a free or disposable email address trigger a decline?
Use a disposable address as a reason for additional verification or a tighter transaction limit when the rest of the application also looks risky. A free email provider alone is weak evidence and can exclude legitimate customers. Keep disposable-domain lists current, and measure whether the added check reduces losses enough to justify the friction.
How should I check whether an email address can receive mail?
Check the address syntax and the domain’s DNS mail routing before sending a message. A domain with no MX record is not automatically undeliverable because mail systems can use the domain’s address records as a fallback. DNS checks establish routing information, not that a specific mailbox exists, so treat the result as a data-quality signal rather than a fraud verdict.
How should I score a catch-all email domain?
Treat catch-all status as ambiguous and let other evidence determine its weight. A catch-all domain can belong to a legitimate personal domain, but repeated use of related addresses across suspicious applications may add useful context. Test the feature against confirmed outcomes and monitor false positives, since catch-all behavior alone does not identify who controls a mailbox.
