Public domains
When public_domain is true, how freemail providers are classified, and using the flag in B2B signup and lead routing.
The public_domain field is true when the domain belongs to a consumer or freemail mailbox provider: Gmail, Outlook, Yahoo, iCloud, Proton free tiers, regional webmail hosts, and similar.
This is a classification signal, not a syntax error. [email protected] is valid and deliverable; the flag tells you the address is not hosted on the registrant's corporate domain.
Why track public domains
Product teams use public_domain to:
- Gate B2B trials ("work email required")
- Route leads (consumer vs business CRM queues)
- Weight fraud scores (disposable + public vs corporate)
- Skip domain-based enrichment that expects a company-owned hostname
EmailGuard maintains a curated provider list covering major consumer mailbox hosts worldwide, updated as new freemail services launch. Domains are tagged with stable provider labels you can use in analytics and routing rules.
Relationship to other signals
| Signal | Overlap |
|---|---|
| Syntax validation | Required first; public check runs only when syntax passes |
| Role address | [email protected] can be both public and role |
| Relay domain | Relay services use their own domains (mozmail.com); not the same as public freemail |
| Disposable | Most freemail is not disposable; do not treat public_domain as throwaway |
Corporate Google Workspace addresses use custom domains ([email protected]); those return public_domain: false even though Google hosts the mailbox.
API examples
curl -sS \
-H "Authorization: Bearer YOUR_KEY" \
"https://emailguard.co/api/v1/emails/detect?email=alex%40gmail.com"{
"data": {
"email": "[email protected]",
"syntax_validation": true,
"public_domain": true,
"domain": "gmail.com"
}
}Work email:
{
"data": {
"email": "[email protected]",
"public_domain": false,
"domain": "acme.com"
}
}Standards note
Mailbox provider classification is operational data, not defined by email RFCs. Address structure still follows RFC 5322. Domain names are compared after IDNA normalization.
Policy patterns
| Use case | Typical rule |
|---|---|
| B2B only signup | Reject or waitlist when public_domain is true |
| Mixed B2B/B2C | Allow; use flag for analytics |
| Enterprise SSO | Often irrelevant once IdP owns identity |
Combine with normalized when deduplicating consumer signups that use subaddressing.