# Role-based email addresses and how to treat them

info@, support@, billing@ and about a thousand more belong to a function, not a person. How Spaw detects them, why senders flag them, and when to keep them.

Date: 2026-09-03

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 `support@acme.com` goes to whoever is on the support rota this week; mail to `mia.k@acme.com` 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.

```bash
curl https://spaw.co/api/v1/email \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{"email": "role@spaw.test"}'
```

```json
{
  "success": true,
  "data": {
    "email": "role@spaw.test",
    "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 }
}
```

`role@spaw.test` 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.

```bash
curl https://spaw.co/api/v1/email/bulk \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{"emails": ["info@acme.com", "mia@acme.com"], "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 [`role` reason page](/docs/reasons/role) for the exact fields and precedence.
- Run your signup list through the [batch endpoint](/docs/api/verify-email-batch) and branch on `role` before the next campaign.
- Follow the [email list cleaning checklist](/guides/email-list-cleaning-checklist) to decide what else to segment out.
- Check a single address in the [free email checker](/tools/email-checker).

Reference: https://spaw.co/guides/role-based-email-addresses