Role address

Personalised mail to a shared mailbox reads as a mistake to whoever opens it, and a message addressed to a first name derived from the word info is worse than one addressed to nobody. Reply rates on role addresses are poor and complaint rates are high, because the people reading them are the ones most exposed to unsolicited mail.

Some role addresses are also monitored by abuse teams — abuse@ and postmaster@ exist for exactly that purpose — and a marketing sequence landing in one is the fastest complaint you will ever generate.

The specific error is inventing a person. A pipeline that derives names from local parts turns [email protected] into Careers at Acme, and that record then flows through a sequence with merge tags. Every stage after the mistake amplifies it.

The fix is a rule at ingest, not a filter at send time: drop role local parts entirely, and only derive a name when the local part is plausibly one. A record dropped at ingest costs nothing; a fabricated person costs a reply, a complaint and a cleanup.

There are cases: a genuine partnerships@ inquiry, a support escalation, a vendor onboarding process that publishes an address for exactly that purpose. The distinction is whether the address was published as the correct route for what you are writing about.

If it was, write to the function rather than to a person — no first name, no personalisation, a clear subject stating the purpose. That is a different message from a prospecting email, and it should be sent as one.

SalesShift drops role accounts during enrichment rather than converting them into people, and only derives a name when the address's local part plausibly is one. Nothing is invented to fill a field.