Find role emails
Separate real people from shared inboxes before you hit send: Billing@example.com is flagged as a role address in the billing category, while a named contact passes as personal. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Email address
- Billing@example.com
- Detected role
- billing
spot info@, admin@, free in your browser
Why shared inboxes need their own treatment
Sales and marketing lists collect addresses like info@, admin@, hello@ and no-reply@ through form fills, public directories and old contact exports. These mailboxes are frequently monitored by several people or by nobody at all, so a message sent there rarely reaches someone who decides and rarely gets a genuine open or click. Treating them like a named contact distorts your engagement figures and can lead to spam complaints. The check compares the part of the address before the @ with a maintained dictionary of role, department and system prefixes, in English and other languages, and tells you whether the address is a role one and which category it matched, such as administrative, support, marketing, no-reply or postmaster.
How teams use the result
Outbound sales teams strip info@ and sales@ from a cold outreach list before launch, so personalized subject lines never land in an inbox nobody reads. Support teams route messages from admin@ or support@ to a shared queue instead of a single agent. Newsletter senders split a signup list so role addresses get a general digest while personal addresses receive the tailored version. During account creation, signups from webmaster@ or postmaster@ deserve a closer look, since genuine individual users rarely register with them.
Why role addresses trip up outreach
Sales and marketing lists accumulate addresses like info@, admin@, hello@ and no-reply@ through form fills, scraped directories and old contact exports. These mailboxes are frequently monitored by several people or nobody at all, so a message sent there rarely reaches a decision-maker and rarely gets a genuine open or click. Detecting them separates real prospects from generic inboxes before you spend a send on the wrong target.
Where role detection earns its keep
Outbound sales teams use it to keep cold sequences pointed at named humans. Support platforms use it to auto-route tickets that arrive from role inboxes. List hygiene pipelines run it before every campaign so shared mailboxes get suppressed from personalized flows and redirected to newsletter-style sends instead, which respects how those inboxes are actually read.
What you can do with it
Sales sequence hygiene
Strip info@ and sales@ from a cold outreach list before launch so personalized subject lines never land in a shared inbox nobody reads.
Support ticket routing
Flag inbound emails from admin@ or support@ addresses to route them to a team queue instead of assigning them to an individual agent.
Newsletter segmentation
Split a signup list so role addresses like newsletter@ go into a generic digest send while personal addresses get the tailored version.
Fraud and abuse screening
Treat signups from webmaster@ or postmaster@ as higher risk during account creation, since legitimate individual users rarely register with those prefixes.
FAQ
Does it work for non-English prefixes?
Yes, the dictionary covers common role prefixes across several languages, not just English-only patterns like info or admin.
What happens if the task fails?
Failed tasks are retried automatically up to three times and are never charged; if all retries fail you get a clear error instead of a silent gap.
What is a role email address?
It is an address that belongs to a function rather than a person, such as info@, billing@, sales@ or webmaster@. These shared mailboxes are often read by several people or by nobody, so messages sent there rarely reach a decision-maker.
Should I delete role addresses from my list?
Not necessarily. Take them out of personalized sequences and send them newsletter-style messages instead, which matches how shared inboxes are read. Messages arriving from support@ or admin@ can go to a team queue rather than to one agent.
Why are signups from webmaster@ or postmaster@ treated as higher risk?
Because real individual users rarely register with those prefixes. When an account is created from such an address, it is reasonable to look twice before granting a trial or a bonus.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/verify/email-role \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"email":"info@example.com"}'const res = await fetch("https://api.kit.forhosting.com/verify/email-role", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"email": "info@example.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/verify/email-role",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"email": "info@example.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/verify/email-role", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"email":"info@example.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"email":"info@example.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/verify/email-role", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"email": "info@example.com"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "verify.email_role",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
A role email checker API tells you whether an address belongs to a person or to a function like billing, sales or webmaster. That distinction matters: role addresses are shared mailboxes, often unmonitored, and treating them like a named contact skews your engagement metrics and can trigger spam complaints.
How the detection works
The endpoint parses the local part of the address against a maintained dictionary of role, department and system prefixes across common naming conventions in English and other languages, then returns a boolean flag plus the matched category, such as administrative, support, marketing, no-reply or postmaster. It runs alongside format and domain checks so you can combine signals into a single verdict without stitching together separate services.
What to expect from a call
Submit the request and you get back a task_id immediately; the actual verdict arrives through your webhook or a signed link valid for 24 hours, matching how every task on this API behaves. A typical response tells you is_role true or false and, when true, the category it matched, so your logic can decide to exclude, deprioritize or route the address to a shared team inbox instead of a personal sequence.
Fitting it into an automated pipeline
Retries happen automatically up to three times before you see a clear failure, so the pipeline stays predictable. Because every call is billed only on success and results are delivered asynchronously, you can fold role detection into a larger verification chain, format check, then typo check, then role check, then MX lookup, without worrying about a single slow response blocking the rest of your workflow.
Technical questions
What counts as a role email?
Any address built around a function rather than a person, such as info@, admin@, support@, sales@, no-reply@ or webmaster@, is classified as a role email by this role email checker API.
Is the role email checker API free?
The tool above runs free in your browser. The API is paid — each call draws from your prepaid ForHosting KIT balance: top up from $10.00 (it never expires), pay each request's published price, and a call with no balance returns HTTP 402. No subscription, no tokens, and a failed task is never charged.
How much does each check cost?
Each request to /verify/email-role costs 0.002 dollars, charged only when the task completes successfully.
Does it also validate the email format or domain?
No, role detection is a focused, single-purpose check; pair it with the typo and format endpoints if you need a fuller verdict on one address.
Can I check emails in bulk?
Each call handles one address; for large lists, loop your own batching over this endpoint or use the dedicated bulk verification endpoint alongside it.
How do I get the result?
Every call returns a task_id right away; the verdict is delivered through your signed webhook or a signed link valid for 24 hours.