Why Agencies Should Pull Role Addresses Like info@ and support@ Out of Client Cold Lists

Most lists a client hands over have them. info@, sales@, support@, admin@, sometimes privacy@ or abuse@. They look valid, they usually pass verification, and they make the list feel bigger. Some enrichment tools fill them in when they cannot find a named person.

They do not belong in a cold sequence on a client's domain. This post covers why, what the major email platforms already do about them, and the rule we would set in each client's workspace.

What a role address is

A role address belongs to a function, not a person. Mailchimp describes them as company addresses "defined by a job rather than a person," often managed by several people or eventually abandoned. Klaviyo calls them shared addresses used by groups inside an organization.

That difference drives everything else. A named person decides whether your email is relevant. A shared inbox may be read by a receptionist, a support queue, a ticketing system, or nobody.

Why they hurt a client's domain

More people can complain. Klaviyo's help center says role addresses "typically don't opt-in to receive emails and generally have high spam complaint rates," and that they are more likely to bounce. Any one of the people watching a shared inbox can hit "report spam," and that counts against the sender. Google's sender guidelines ask senders to keep the spam rate reported in Postmaster Tools below 0.1% and never let it reach 0.3%. A few complaints from shared inboxes eat into that margin fast.

Some of them are traps. Spamhaus lists registration and role account addresses as a kind of live spam trap. Its examples are postmaster@, abuse@, and admin@, which are published in domain records, harvested, and mailed. Spamhaus says these "should almost NEVER be on a marketing mailing list." Mailing them suggests the list was harvested rather than built with care.

They rarely reach the buyer. A support inbox routes your email into a ticket queue. A general inbox forwards it, maybe, to someone who did not ask for it. Even when it lands well, you have learned nothing about who the buyer is.

What the big platforms already do

Marketing email platforms already handle this, and their rules are a good baseline:

• Mailchimp blocks role addresses from imports. Its list includes abuse@, admin@, billing@, compliance@, noreply@, postmaster@, privacy@, security@, support@, webmaster@, and more. A role address can still join through a signup form, which is a real opt-in.
• Klaviyo automatically skips a fixed list of role addresses, including abuse@, compliance@, noreply@, postmaster@, privacy@, and unsubscribe@, and says it cannot remove the block.

Note what is missing: neither list includes info@ or sales@. That does not make them safe for cold email. It means the platforms block the worst cases outright and leave the judgment to the sender. Cold outbound, where nobody opted in, should be stricter than a newsletter platform, not looser.

A per-client rule for role addresses

Here is the rule we would put in every client workspace before the first import:

1. Block the infrastructure addresses outright. abuse@, postmaster@, hostmaster@, noreply@, no-reply@, privacy@, security@, compliance@, unsubscribe@, webmaster@, root@. These never enter a sequence, for any client, under any campaign.
2. Hold the general inboxes. info@, hello@, contact@, sales@, support@, admin@, office@ go to a separate segment, not the main sequence. They are not deleted. They are a research lead.
3. Turn holds into named contacts. For accounts that matter, use the held address as a pointer: the company is in the ICP, so find the actual person in the right role. If you cannot find one, the account waits.
4. Do not let enrichment guess role addresses. When an enrichment step returns info@ because nothing better turned up, mark it as unfound. A guessed shared inbox is not a contact.
5. Make exceptions explicit and rare. Some tiny companies route everything through one shared address, and the founder reads it. If a client wants to reach those accounts, approve them one at a time, write the reason on the record, and keep them out of any high-volume step.

Role addresses also come up in catch-all policies. If you already run a per-client policy for catch-all addresses, put the role rule right next to it in the same import check.

Where GTM fits

GTM qualifies contacts against each client's ICP and campaign entry rules before anything is written, keeps the source of every field, and runs each client in an isolated workspace with its own suppression list. A role-address rule is just another entry rule: a contact that fails it never reaches the write step.

If you run outbound for several clients and want list rules enforced before anything sends, join the waitlist.

Sources

• Mailchimp, "Limits on Role-Based Addresses": https://mailchimp.com/help/limits-on-role-based-addresses/
• Klaviyo, "Understand role-based email addresses and their impact on deliverability": https://help.klaviyo.com/hc/en-us/articles/17976334449947
• Spamhaus, "Spamtraps – fix the problem, not the symptom": https://www.spamhaus.org/resource-hub/deliverability/spamtraps-fix-the-problem-not-the-symptom/
• Google, "Email sender guidelines": https://support.google.com/mail/answer/81126
• Google, "Email sender guidelines FAQ": https://support.google.com/mail/answer/14229414