Role account

What a function name tells you

Prefixes such as info@, support@, sales@, admin@ and billing@ describe a function within an organisation. Each needs a domain to form a complete address. The organisation may route it to one person, several recipients, a shared inbox or a ticket system.

RFC 2142 describes business mailbox names including INFO, SALES and SUPPORT. A familiar name indicates an intended use, but does not establish that the organisation has created the mailbox.

How the role flag fits into verification

Emvero matches the local part, before the at sign, against its role-name dataset. A match sets checks.role_account and adds ROLE_ACCOUNT. It cannot establish who controls the address or how many people read its messages.

The flag alone changes neither the status nor the recommended action. A mailbox check can return deliverable and allow alongside the role code. Other evidence, such as an accept-all domain, may change the overall result. The verification result guide explains how to read these fields together.

Deciding whether to use the address

A customer may choose billing@ for invoices because that is where the organisation handles them. For a login or personal message, you may need evidence that the requester controls the mailbox. Have your application send confirmation when that access matters.

For registration rules and separate login and billing contacts, see whether to block role-based addresses at signup.

The role name supplies no evidence of campaign consent, likely complaints or a spam trap. Base those decisions on the person’s request and your sending rules. A positive technical check also cannot guarantee that a future message will arrive.