Role addresses
How role_address flags shared inboxes like admin@ and support@, with example patterns and signup policy guidance.
Loading article…
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.
Role inboxes behave differently from personal mailboxes:
EmailGuard exposes the signal so you can route, block, or segment in your signup or CRM sync without maintaining your own prefix list.
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):
[email protected]+ — [email protected]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.
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
}
}| 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.