A role-based email address is one whose username names a job or a group rather than a person: info@, support@, sales@, billing@, admin@, noreply@. The mailbox is usually real and usually monitored, but by a rotating set of people, through filters and forwarding rules you cannot see, which is why marketing senders treat it differently from mia@.
What is a role-based address?
The distinction is purely about the part before the @. A role address is addressed to a function. Mail to [email protected] goes to whoever is on the support rota this week; mail to [email protected] goes to Mia. The domain, the mail server and the handshake are identical for both.
Because the local part is the only signal, detection is a list lookup. Spaw uses the open role-address list maintained by Mixmax, synced weekly and unioned with a bundled seed, and matches the lowercased username exactly. The list has grown past a thousand entries, from the obvious info and sales to abuse, postmaster, accessibility, hr, jobs, press, security and dozens of localized variants.
| Group | Typical usernames |
|---|---|
| Front door | info, hello, contact, enquiries, office, mail |
| Sales and marketing | sales, marketing, partnerships, press, media |
| Support and operations | support, help, helpdesk, service, ops, it |
| Money | billing, invoices, accounts, finance, payments |
| Technical and abuse | admin, administrator, webmaster, postmaster, abuse, security, noc |
| People | hr, jobs, careers, recruiting, team |
| Machines | noreply, no-reply, donotreply, mailer-daemon, bounce, notifications |
Why do senders treat role addresses differently?
Four practical reasons, all of them about outcomes rather than the address itself.
Nobody opted in. A person who types sales@ into your form is often not the person who will read your mail, and the people who do read it did not ask for it. That is the setup for spam complaints, and complaints are the metric mailbox providers weigh most heavily.
They churn silently. Role inboxes are forwarded, split, auto-replied and abandoned as teams change. The address keeps accepting mail long after anyone reads it, so engagement drops without a bounce to warn you.
They are shared. One person unsubscribing does not stop the others from seeing the next message, and one person reporting spam counts against you regardless.
Sending platforms police them. Several email service providers refuse role addresses on list import, hold them for review, or exclude them from campaigns by default. A list heavy with info@ addresses can fail an import before you send anything.
None of this means role addresses bounce more. Many are the most reliable mailboxes at a company. The problem is consent and engagement, not deliverability.
What does Spaw return for a role address?
The verdict is risky with reason: "role" and role: true, and the mailbox is still probed, so mailbox_exists can be true. The role flag adds 30 to the risk score, which is the medium band on its own.
curl https://spaw.co/api/v1/email \
-H "Authorization: Bearer sk_live_…" \
-H "Content-Type: application/json" \
-d '{"email": "[email protected]"}'
{
"success": true,
"data": {
"email": "[email protected]",
"deliverable": "risky",
"reason": "role",
"risk_score": 30,
"risk_level": "medium",
"role": true,
"smtp_checked": true,
"mailbox_exists": true,
"// 19 more fields": "see the endpoint reference"
},
"meta": { "credits_used": 0, "credits_remaining": 10, "cache_hit": false }
}
[email protected] is a fixed test address and free. A real role address is billed like any risky answer: 1 credit, repeats free for seven days.
Precedence matters when several signals apply. A role address at a disposable domain is reported as disposable, and a role address on a catch-all server is reported as role because the role flag ranks above catch-all in Spaw's verdict order; both flags still appear as booleans, and both weights are added to the score.
When should you keep role addresses?
Keep them wherever the function is the point.
| Context | Treatment |
|---|---|
| B2B contact and quote forms | Accept. procurement@ is exactly who you want. |
| Support ticket systems | Accept. Role inboxes are the normal case. |
| Transactional mail: receipts, invoices, alerts | Accept. billing@ is the correct recipient for an invoice. |
| Newsletter and marketing signups | Ask for a personal address, or accept and segment out of promotional sends. |
| Purchased or scraped lists | Drop. Role addresses on a cold list are the fastest route to complaints. |
| Cold outreach sequences | Drop or route to a manual step. Personalized sequences to info@ read as spam. |
A useful rule for signup forms: accept the address, since blocking info@ at a B2B company loses real leads, but mark the contact as role-based and keep it out of drip campaigns until a person replies.
How do you find role addresses in an existing list?
Verify the list. Every answer carries role: true or false, so a bulk run gives you the segment as a column, alongside the verdict and the risk score. From the dashboard, upload the file and filter the results; from the API, create a bulk job and download the CSV with the verdict columns added to your own.
curl https://spaw.co/api/v1/email/bulk \
-H "Authorization: Bearer sk_live_…" \
-H "Content-Type: application/json" \
-d '{"emails": ["[email protected]", "[email protected]"], "webhook_url": "https://www.example.com/hooks/spaw"}'
The job answers 202 with an id and a signing secret shown once; the completion webhook is signed with it. Undeliverable answers in the run are free, and addresses already on your suppression list are answered without any work.
What to do next
- Read the
rolereason page for the exact fields and precedence. - Run your signup list through the batch endpoint and branch on
rolebefore the next campaign. - Follow the email list cleaning checklist to decide what else to segment out.
- Check a single address in the free email checker.