Checking an address never emails it, not even by accident. Here’s why that holds

Start for free

Glossary

Role account

An address that reaches a function rather than a person — info@, support@, sales@.

A role account is addressed to a job rather than to an individual: info@, support@, sales@, admin@, billing@. It usually reaches a shared mailbox, a ticketing system, or a distribution list with several people behind it.

Role accounts are almost always deliverable, and that is precisely why they need their own treatment. Nothing is wrong with the address. The question is not whether mail arrives but whether sending it is a good idea, and that depends entirely on what you are sending.

For transactional mail a role account is often the right destination — an invoice to billing@ reaches whoever is handling invoices this week. For marketing it is a liability. Nobody consented individually, several people may see it, and shared mailboxes are complained about at a much higher rate than personal ones. Complaints are what mailbox providers weigh most heavily, so a small number of role accounts can cost more deliverability than their share of a list suggests.

They are also a common source of recycled spam traps, because a departing employee’s role alias tends to outlive the role.

The verdict is risky rather than a filter. Whether a role account belongs in a particular send is a decision about the send, not a fact about the address, and the result exists to inform that decision rather than to make it for you.

What the service returns

Reason codes from the closed vocabulary in the API response. These are the exact strings an integration writes an if against.

What the service returns
ROLE_ACCOUNTRole account, not a person

See it on a real address.

The free checker returns the whole result — every stage, every reason code, nothing held back.