---
title: "What is a role based email address? - Emvero"
description: "A role based email address serves a function such as support or billing. Learn what ROLE_ACCOUNT identifies and what it leaves open about delivery and ownership."
url: https://emvero.io/glossary/role-account/
language: en
updated: 2026-10-10
---

All terms

Glossary

# Role account

A role account is an email address named for a function, such as support or billing. One person or several people may read it; the name does not establish mailbox existence or ownership.

## 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](https://www.rfc-editor.org/rfc/rfc2142.html#section-3) 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](https://emvero.io/glossary/catch-all-domain/), may change the overall result. The [verification result guide](https://emvero.io/blog/reading-a-verification-result/) 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](https://emvero.io/blog/block-role-based-email-signups/).

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.

## Related reason codes

The API uses these identifiers to explain a check. The notes identify values that the current verification policy or probe does not return.

`ROLE_ACCOUNT`

Address uses a role name

## Related terms

### Spam trap

An address used to identify problematic sending practices. A verification check cannot certify that an address is not a trap.

### Catch-all domain

A mail server accepts arbitrary recipients, so acceptance alone cannot establish whether a particular mailbox exists.

## Compared side by side

### Email verification vs list hygiene

Technical address evidence and ongoing subscription, suppression and engagement records answer different sending questions.

### Domain check vs full verification

Domain depth checks syntax and routing without SMTP. Full verification may add recipient evidence when the destination permits it.

### Disposable-domain lists vs API checks

A reference list identifies known disposable domains. Current DNS and SMTP evidence answer different questions about an address.

[All terms](https://emvero.io/glossary/)

## Try a check in your account.

Choose the check that fits your question and inspect the result.

Start for free