role based email detection api
Role based email detection API
Flag shared inboxes like info@, support@, and sales@ before they enter your CRM.
Role-based addresses are valid but often lower quality for lead conversion.
They can be useful for contact pages but not always for user signups.
You can warn or block depending on your product policy.
{
"success": true,
"email": "[email protected]",
"result": "valid",
"syntax_ok": true,
"mx_found": true,
"disposable": false
}What is role based?
A mailbox that represents a function, team, or department instead of a person.
How should I use the flag?
Warn in B2B contexts and block in signup flows that require a named user.
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.