how to detect role based emails
How to detect role based emails
Use local-part rules and a role-prefix list to identify shared inboxes reliably.
Role prefixes are simple and fast to check.
A good classifier should also support custom exceptions for your domain rules.
The result is usually a warning, not a hard failure.
{
"success": true,
"email": "[email protected]",
"result": "valid",
"syntax_ok": true,
"mx_found": true,
"disposable": false
}What should I check first?
Start with the local part before the @ sign and compare it to a role list.
Can users override it?
Yes, in enterprise workflows you may want manual approval for shared inboxes.
Shared inbox detection
Role-based addresses such as info@, support@, or sales@ are usually valid mailboxes, but they do not behave like individual user inboxes. That difference matters when you need a named owner, a direct contact, or a clean CRM identity.
Policy choices
Some products should warn, others should block, and enterprise systems may allow overrides. The value of the flag comes from matching the result to your business policy rather than treating every mailbox type the same.
FAQ
How do I use this page?
Use it as a quickstart reference and link it from your docs, onboarding flow, or marketing page.
What should I do next?
Create an account, try the demo, and move the integration into your backend with a real API key.
Are role-based emails bad?
Not always. They are just less useful for some workflows.
Can I still accept them?
Yes, if your product accepts team inboxes or support contacts.