Email Risk Signals
What an email address reveals about the person behind an account: age, history, domain type, structure, deliverability, relay use, and links to other accounts.
What it measures
| Feature | What it captures | Read |
|---|---|---|
| Age and history | First-seen date across the web or a consortium; activity breadth | Real people accumulate email history; new addresses created for a sign-up have none |
| Domain type | Major consumer provider, ISP, corporate, education, disposable or temporary, newly registered domain, privacy relay | Disposable and freshly registered domains carry high abuse rates; relays do not |
| Structure | Name-like vs random strings, digits appended to a name, sub-addressing variants, dot variants on providers that ignore dots | Machine-generated patterns and variant farming |
| Deliverability | Mailbox exists, domain has valid mail records, bounces | Undeliverable addresses on a funded account are a red flag |
| Name match | Similarity between the local part and the account holder's name | Weak alone; useful as a consistency check |
| Internal linkage | Accounts, devices, instruments sharing the address or its normalized form | Feeds Entity Link Analysis |
Normalize addresses before you count them. Case, dot variants and sub-addressing ("plus" tags) let one mailbox appear as many addresses. Store both the raw and the canonical form, but only apply provider-specific rules where the provider documents them.
Why it matters
Email is the cheapest identity element to create and is used as the account key for most consumer products. In transaction fraud, it matters most at three points:
- Incentive-gated sign-up and redemption. Bonus, referral and promo abuse rely on producing many "new customers" (Sign-Up Bonus Abuse, Referral Abuse, Promo Code Abuse). Email age and canonicalization are the first filters that catch them. In cashback apps, email is often the only identity element at sign-up, so it carries more weight than elsewhere.
- Account changes before cash-out. An email change to a brand-new address, followed by a password reset and a payout change, is a standard ATO shape (Account Takeover (ATO), Account Recovery Abuse). See Account Change Events and Contact Change Cooling-Off Periods.
- CNP and onboarding. At ecommerce checkout, an email with no history paired with a high-value basket is a classic Card-Not-Present Fraud feature. At neobank or brokerage onboarding, a new email plus a new phone plus a thin bureau file is a Synthetic Identity Fraud pattern.
How to collect it
- Buy email intelligence (age, history, domain risk, deliverability) from identity-data and fraud-network providers. Coverage is strongest for major consumer domains and weakest for corporate and regional providers.
- Build disposable and newly registered domain lists (from public lists plus your own observations), canonicalization logic, and internal linkage counts.
- Verify reachability with confirmation codes. NIST SP 800-63A-4 caps email confirmation-code validity at 24 hours, a reasonable baseline.
- Record the email's first-seen date in your own system as a separate feature from external age.
How to use it
- Score email in context. An old email on a new device is ATO context; a new email on a new device on a new account is fake-account context; a new email on an old device with a long-tenured account is often a customer who changed providers.
- Combine it with phone and identity. A disposable email with an old, consistent phone and a bureau match is a different case from a disposable email with a VoIP number. See Phone Risk Signals and Identity Element Consistency.
- Use it for incentive eligibility. Restrict incentive eligibility based on email quality instead of blocking sign-up. The customer can still join, and the bonus waits for stronger evidence (Promotion Design Guardrails, Reward Vesting and Clawback).
- Count canonical forms in Velocity Signals: accounts per canonical email, per domain per hour, per local-part pattern.
Strengths and limitations
Strengths: universal, cheap, available before any money moves; excellent at bulk fake-account detection.
Limitations:
- Aged email accounts can be bought and farmed, so age is evidence but not proof of a real person. See Account Farming and Resale.
- ATO of the email account itself defeats email-based recovery and notification. A notification to a compromised inbox reaches the attacker.
- Coverage gaps for regional, corporate and new legitimate providers.
- Assume any structural heuristic will eventually be gamed; layer it with device and behavior.
False positives and fairness
- Privacy relays and alias services produce new, random-looking addresses on purpose. Apple's Hide My Email creates a unique forwarding alias per service. In August 2026 Apple dropped plans to move Hide My Email to a separate domain after users raised concerns that a distinct domain would make blocking easy; aliases stay on icloud.com, while newly created Sign in with Apple addresses move to private.icloud.com (existing privaterelay.appleid.com addresses keep working). Treat relay addresses as privacy behavior, not risk, and don't block relay domains.
- Young people, new immigrants and newly online older adults often have new email addresses for legitimate reasons.
- Corporate addresses usually have no consumer history.
- Name-match features perform worse for names that are transliterated, hyphenated, or don't follow Western ordering. Test for disparate performance before relying on them.
Privacy and compliance considerations
- Email addresses and derived attributes are personal information. Sending them to third-party scoring services is a disclosure that belongs in privacy notices and vendor contracts. See Privacy and Data Use in Fraud Prevention.
- Hash or tokenize emails where linkage doesn't need the plaintext. Be aware that hashed emails are still personal data.
- Don't weaponize email-domain lists against relay users in a way that contradicts the platform's terms (e.g., Sign in with Apple requirements for apps that offer it).
- Apple relay mechanics for domain rules. Apple's developer documentation says Sign in with Apple relay addresses can end in @private.icloud.com, @privaterelay.appleid.com or @icloud.com. The same address is used across all apps from one development team, and it differs across teams. Each relay address is capped at 100 emails a day, and to email relay users you must register your outbound domains and authenticate with SPF. Apple's August 24, 2026 developer notice said new Sign in with Apple addresses would move to private.icloud.com "later this year" (no date given), while existing privaterelay.appleid.com addresses keep working. Accept all three domains, and don't treat a domain switch mid-cohort as a risk signal. Because the address is stable per development team, you can still count accounts per relay address for multi-accounting checks.
Mechanisms it helps detect
Fake Account Creation (Bots) · Multi-Accounting · Sign-Up Bonus Abuse · Referral Abuse · Promo Code Abuse · Synthetic Identity Fraud · Account Recovery Abuse · Account Takeover (ATO) · Card-Not-Present Fraud
Related signals and controls
- Signals: Phone Risk Signals, Identity Element Consistency, Account Change Events, Velocity Signals, Entity Link Analysis, Customer Tenure and History
- Controls: Contact Change Cooling-Off Periods, Promotion Design Guardrails, Reward Vesting and Clawback, Secure Account Recovery Design
- Playbooks (members): Playbook - Sign-Up Bonus and Promo Abuse Members, Playbook - Fake Account and Bot Defense Members
Sources and further reading
- Apple won't change Hide My Email domain after backlash (MacRumors, Aug 2026): domain plans for Hide My Email and Sign in with Apple, and the blocking concern.
- How Apple Private Email Relay works (Bird): per-service forwarding aliases that users can disable.
- Apple Developer: Communicating using the private email relay service: relay domains, per-team address stability, 100-email daily cap, domain registration and SPF.
- PPC Land: Apple keeps Hide My Email on icloud.com (Aug 2026): August 24, 2026 notice; new Sign in with Apple addresses move to private.icloud.com; existing addresses keep working.
- NIST SP 800-63A-4: email confirmation code validity; device and account tenure checks (including email account age) as recommended fraud checks.
- NIST SP 800-63-4 overview slides: email and address risk checks among recommended fraud controls.