Role-based email addresses
A role-based address names a function rather than a person — info@, sales@, support@. Several people read it and nobody owns it, which is why it produces more complaints and less engagement than a named address. Some of them are also required to exist by RFC 2142, so they are not a defect.
Written by the SieveGuard team from the checks our own free tools run. Last reviewed .
The problem is shared ownership, not the name
Every difficulty with these addresses follows from one fact: no individual is responsible for the inbox. Nobody subscribed, so nobody feels they can unsubscribe, and the person who opens your message on Tuesday is not the one who opened it on Monday.
- Higher complaint rate. The reader did not sign up, so "report spam" feels more legitimate than unsubscribing on a colleague's behalf. Complaints are the heaviest negative input into sender reputation, and Gmail's stated ceiling is 0.3%.
- Lower engagement. Shared inboxes get triaged, not read. Low opens on a segment teach a filter that your mail is unwanted — which then affects your named recipients too.
- Consent is genuinely ambiguous. One person entering
info@into a form has not obtained consent from everyone who reads it. Under GDPR that is a real question, not a technicality. - Some are monitored by people looking for problems.
abuse@andpostmaster@exist to receive complaints. Marketing to them is the fastest route to being reported by someone whose job is reporting.
Not all role addresses are equal
Blanket blocking is the usual implementation and it is too blunt. These behave very differently:
| Address | What it is | Marketing to it |
|---|---|---|
abuse@ | Required by RFC 2142. Receives complaints | Never |
postmaster@ | Required by RFC 5321. Mail operations | Never |
noreply@ / no-reply@ | Usually unmonitored, often unable to receive | Never — likely to bounce |
security@ | Vulnerability reports | Never |
info@ / contact@ / hello@ | The company’s front door | Often the only address a small business has |
sales@ | Staffed, and wants to be sold to less than you think | Legitimate for B2B, with care |
support@ / help@ | Staffed by people with a queue | Poor fit for marketing |
billing@ / accounts@ | Finance | Fine for invoices, wrong for marketing |
The last row is the one blanket rules break. Transactional mail — invoices, receipts, renewal notices — belongs at billing@ or accounts@, and a signup form that refuses those addresses is refusing the correct answer.
When blocking costs more than it saves
The case against a hard block, which is stronger than most implementations assume:
For many businesses it is the only address
A two-person consultancy publishes info@ and nothing else. Refusing it at signup refuses the customer, and they will not hunt for an alternative — they will leave, and you will never learn why.
B2B lead capture depends on them
If you sell to companies, a meaningful share of genuine inbound arrives from a shared address. Blocking at the form is choosing list hygiene over pipeline, which is rarely the trade you meant to make.
Transactional mail must reach them
Even where marketing to accounts@ is wrong, invoicing it is right. A block applied at the account level rather than the mailing level breaks billing.
The policy that actually works
Separate the decision to accept an address from the decision to market to it. Those are different questions and most systems conflate them.
| Context | Recommended policy |
|---|---|
| Account signup | Accept everything except abuse@, postmaster@, security@, noreply@ |
| Transactional mail | Send to any address the customer nominated, including billing@ |
| Marketing list | Accept, but segment separately and watch complaints closely |
| Cold outreach | Do not include role addresses at all |
| Bought list containing them | The role address is the least of the problems |
The four never-send addresses are worth hard-coding: three of them exist specifically to receive complaints, and noreply@ frequently cannot receive at all, so it turns into a hard bounce. Everything else is a segmentation decision, not a validity one.
Detecting them
Straightforward — match the local part against a known list, case-insensitively, before any other checks. Two cautions worth building in:
- Match exactly, not by prefix.
info@is a role address;infoteam@andinformation.services@may be real people or real departments. Substring matching produces false positives on names. - Personal domains change the reading.
sales@gmail.comis an individual who chose a username, not a shared inbox. The role signal only means anything on a domain the organisation controls — which, confusingly, is also often a catch-all.
Sources
FAQ
What is a role-based email address?+
One that names a function rather than a person — info@, sales@, support@, billing@. Several people read it and no individual owns it, which is what makes it behave differently from a named address for both consent and engagement.
Should I block role-based addresses at signup?+
Only abuse@, postmaster@, security@ and noreply@. The first three exist to receive complaints and the fourth often cannot receive at all. Everything else, including info@, is frequently the only address a small business publishes — blocking it refuses the customer.
Why do role addresses hurt deliverability?+
Because the person reading did not sign up, so marking it as spam feels more reasonable than unsubscribing on a colleague’s behalf. Complaints are the heaviest negative reputation input, and shared inboxes also get triaged rather than read, which drags engagement down.
Can I send transactional email to billing@ or accounts@?+
Yes — that is exactly where it belongs. The distinction is between accepting an address and marketing to it. Invoices and renewal notices should go to whatever address the customer nominated; a policy that blocks these at account level breaks billing.
How do I detect a role address?+
Match the local part against a known list, case-insensitively, and match it exactly rather than as a prefix. infoteam@ and information.services@ are not info@, and substring matching turns real names and departments into false positives.
Is sales@gmail.com a role address?+
Not meaningfully. On a consumer domain that is an individual who happened to pick that username, not a shared company inbox. The role signal only carries weight on a domain the organisation actually controls.
Check it on a real domain
Free, no signup, DNS-only. Nothing you type leaves the lookup.