Role-based Email: Why the Blanket Rule Against Them Is Wrong at the Small End

Role-based Email: Why the Blanket Rule Against Them Is Wrong at the Small End

A role-based email address identifies a function or a department rather than a named person. The familiar ones are info@, sales@, support@, admin@ and contact@, and the signal sits entirely in the local part of the address, which is the piece before the @ sign.

The definition is uncontroversial. What follows from it is where nearly every guide goes wrong, because the standard rule was written for a market that most cold outbound is no longer aimed at.

What the local part is doing

An email address has two halves, and only the domain half is a technical fact. The local part is a naming convention chosen by whoever set up the mailbox, so a role-based address is a statement of intent by the organisation rather than a property enforced by any protocol.

That intent is usually one of three things. The address is an alias forwarding to one or several real mailboxes. It is a shared mailbox that multiple staff open directly. Or it is the destination for a ticketing system, where arriving mail is turned into a queue item and a human sees a summarised version of it later.

Verification services flag these addresses on the local part alone. There is a conventional list of role tokens, the checker compares your address against it, and it returns a role flag alongside the deliverability verdict. The check is reliable in a way the disposable-domain check is not, because the signal is the address itself rather than a domain list that has to keep up with new registrations. A verifier will tell you whether a given local part is conventionally a role address, and the tools that do it are compared in email verification tools.

Notice what the flag does and does not assert. It says the local part looks like a function. It says nothing about how many people read it, whether any of them can make a decision, or whether the message will ever be seen by a human at all. Those are properties of the organisation, and the address cannot carry them.

Why they carry more risk than a personal address

The elevated risk is real, and it is worth stating properly before arguing with the rule that follows from it.

Several people may read the address and none of them individually owns replying to it. A message that would have got an answer from a named person can sit in a shared inbox where everyone assumes somebody else is handling it. That is a genuine reduction in reply probability, and it has nothing to do with the quality of what you sent.

The reader is less likely to have opted into anything. Personal business addresses appear in datasets partly because their owners handed them over somewhere. Generic addresses are typically published on a website for anyone to use, so the person opening one has no relationship with you at all and no memory of a moment that could be construed as consent.

The complaint risk is higher, and the complaint is what actually costs you. Whoever staffs a generic inbox sees far more unsolicited mail than an individual does and is correspondingly quicker to mark it as spam. That matters because complaints feed directly into how receiving providers rate a sender. Google's sender guidelines tell senders to "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher", and they warn that "Over time, user spam reports can lower your domain's reputation." Reading those numbers against your own sending is covered in Google Postmaster Tools for cold email.

Some generic addresses are monitored deliberately. An abuse@ or postmaster@ address exists specifically to receive reports about senders, and a small number of published addresses are maintained purely to catch unsolicited mail. Those are a distinct hazard from the ordinary info@ and are worth excluding categorically.

Where the rule breaks

The instruction everybody repeats is that role-based addresses should never be emailed. That instruction is inherited from enterprise email marketing, where it is broadly correct, and it is applied wholesale to markets where it throws away reachable buyers.

Consider what info@ actually is at a plumbing company with six employees, a two-partner dental practice, or a contractor whose office is a portacabin and a laptop. It is read by the owner. Or by the owner's partner, who does the books. Or by the one office manager, who prints it and walks it over. At that size there is no triage layer, no shared-inbox diffusion of responsibility, and frequently no other published address in existence. The generic mailbox is the front door because the business has exactly one door.

info@ at a five-person businessEffectively a personal inbox

• Read by the owner, their partner or the one office manager
• No triage layer between the message and a decision maker
• Often the only address the business publishes anywhere
• A reply comes from the person who can actually say yes
• Excluding it removes the business from your reachable market entirely

info@ at a large organisationGenuinely a triaged black hole

• Routed into a ticketing queue or a shared support rota
• Staffed by people with no authority over what you are selling
• Sits alongside dozens of named addresses you could have found instead
• Higher complaint rate, because the reader sees unsolicited mail constantly
• Excluding it costs you nothing you could not reach another way

The rule that treats those two identically is not cautious. It is imprecise, and the imprecision has a direction: it is systematically wrong about the smaller half of the market, which is also the half where a personal address is hardest to find and where the buyer is most likely to be the person opening the mail.

Our practice, stated plainly

For local-business and small-business audiences, we treat a business's generic address as a legitimate fallback when no personal address is found. It is a fallback rather than a shortcut, so it applies only after the normal address-finding work has genuinely missed. Where we know the owner's name we address the message to them by name, so the mail arrives as a message for a person that happened to come through the general inbox. And we never send two of our messages into one generic inbox, so two contacts at the same business are never both allowed to fall back to the same address.

For mid-market and enterprise audiences the fallback does not apply at all. There the generic inbox genuinely is a triaged black hole, a named contact almost always exists and can be found, and a message into info@ buys nothing but a complaint risk.

That is a segment-dependent judgment rather than a new rule replacing the old one. The question to answer is not whether an address is role-based. It is how many people stand between that mailbox and the person who could say yes, and at the small end of the market the answer is usually none. What outbound into that market looks like in practice is covered in lead generation for a small business, and two vertical guides where this shape is the norm rather than the exception are cold email for HVAC companies and cold email for dental practices.

The mechanics this forces

Accepting generic addresses in a segment creates two build-time problems that have nothing to do with copy quality, and both fail silently if nobody handles them.

What has to be true before a generic address is safe to send to

• ✓Yes: The address-finding work genuinely ran and missed a personal address first
• ✓Yes: The greeting is resolved at build time, with a real value written into the message
• ✓Yes: Exactly one address per business survives into the send, with the more senior contact kept
• ✓Yes: The audience is small-business or local-business rather than mid-market or enterprise
• ✓Yes: Deliverability outcomes are tracked separately for generic and personal addresses
• ✕No: A role token has been written into the first-name field to make a template work
• ✕No: abuse@, postmaster@ and similar monitored addresses are included

The greeting has to be resolved before the message is built. An address like info@ has no first name attached to it. A template that opens with a merge field for the first name will render an empty value and produce a greeting with a comma and nothing before it, and that failure happens at send time, outside every check that ran earlier. So the greeting has to be decided while the list is being prepared: the owner's name where it is known, a neutral opening where it is not, written into the message as a real value rather than left to a field that may be empty. The failure mode this prevents is not subtle. It is a message that opens with a punctuation mark, sent to a stranger, at scale.

The related trap is writing the role token into the name field to stop the template breaking. That produces an opening line addressed to a person called Info, which is worse than the empty greeting because it looks deliberate.

One generic address per business. Two contacts at the same company will resolve to the same info@ if you let them, and the outcome is two of your messages arriving in one inbox, which is the fastest way to convert a plausible prospect into a complaint. Systems that key records by email address make this worse, because the second row overwrites the first rather than being visibly rejected, so nobody sees a duplicate anywhere. The deduplication has to happen while the list is being prepared, keeping whichever contact is more senior, and the dropped rows are worth recording so the decision is auditable later.

Measuring whether it works

The honest position is that a generic address performs worse than a personal one on average, and the segment argument is that it performs well enough in the right segment to be worth sending. That is a claim you should verify on your own audience rather than accept from anyone.

The way to do it is to carry a tier marker on every row, distinguishing a personal address from a generic address where the owner's name is known from a generic address where it is not. Push that marker through to your sending platform so it sits alongside each record, then read reply rate, complaint rate and bounce rate separately by tier. The three tiers behave differently, and a programme that measures them as one number cannot tell which part of the policy is earning its place. If a tier reads badly on your audience, cut that tier rather than abandoning the approach.

1. Step 1Run the personal-address work first

   The fallback only opens once the normal address finding has genuinely missed. It is never a way to skip that work.

2. Step 2Check the segment

   Small-business and local-business audiences qualify. Mid-market and enterprise audiences do not, because a named contact exists and can be found.

3. Step 3Resolve the greeting and deduplicate

   Write a real opening into the message, and keep exactly one generic address per business, preferring the more senior contact.

4. Step 4Mark the tier and measure it

   Carry personal, named-generic and unnamed-generic as separate markers so reply and complaint rates can be read per tier.

That measurement matters more than usual on shared sending infrastructure, because a complaint rate driven by one segment lands on domains that may be carrying other campaigns. The cost of getting this wrong is not confined to the campaign that got it wrong.

Judging tier by tier which generic addresses are worth a message is ongoing work rather than a setting, and our pay-per-qualified-meeting outbound carries it as part of the engagement.

Verified as of August 2026. Verify current terms with the vendor before relying on them.