Role addresses
How role_address flags shared inboxes like admin@ and support@, with example patterns and signup policy guidance.
The role_address field is true when the local part matches a role prefix: shared mailboxes such as admin@, support@, billing@, or noreply@ rather than a named person.
Role detection runs after syntax validation. It does not inspect message content or MX records.
Why role addresses matter
Role inboxes behave differently from personal mailboxes:
- Multiple people read the same queue
- Ownership is organizational, not individual
- They are common in B2B contact forms but poor fit for product accounts tied to one login
- Lead scoring models often down-rank them relative to named inboxes
EmailGuard exposes the signal so you can route, block, or segment in your signup or CRM sync without maintaining your own prefix list.
Matching rules
EmailGuard lowercases the local part and compares it against a curated prefix list maintained by EmailGuard—shared inboxes such as admin, support, sales, info, contact, noreply, and postmaster, plus common variants.
Examples of what we flag (not an exhaustive list):
- Exact local part —
[email protected] - Subaddress before
+—[email protected] - Prefix with separator —
support-team@,billing-dept@
There is no single RFC that defines "role address," but the local part still must conform to RFC 5322 addr-spec grammar before this check runs.
API examples
curl -sS \
-H "Authorization: Bearer YOUR_KEY" \
"https://emailguard.co/api/v1/emails/detect?email=admin%40example.com"{
"data": {
"email": "[email protected]",
"syntax_validation": true,
"role_address": true,
"public_domain": false
}
}Personal mailbox on the same domain:
{
"data": {
"email": "[email protected]",
"role_address": false
}
}Policy patterns
| Goal | Approach |
|---|---|
| B2B SaaS self-serve signup | Allow role addresses but flag for sales review, or require personal email when role_address is true |
| Consumer product | Often allow; role addresses are rare |
| High-trust KYC flows | Reject or step-up verification when role_address is true |
| CRM enrichment | Store the flag; do not infer job title from it alone |
role_address is independent of public domain ([email protected] can be both role and public) and disposable checks.