---
title: "Should you block role-based email addresses at signup? | Emvero"
description: "Learn when to accept or restrict role-based email addresses at signup, and how to keep verification results, access rules and mailbox confirmation separate."
url: https://emvero.io/blog/block-role-based-email-signups/
language: en
updated: 2026-10-10
---

Blog

# Should you block role-based email addresses at signup?

Decide whether a role address belongs in a login or contact field. Keep address checks, your access rules and mailbox confirmation separate.

Published 2026-10-10

For a B2B signup, accept role-based email addresses unless your product specifically requires each account holder to use an individual address. An address such as `support@example.com` may be the contact a customer wants to use. If email is used for login or account recovery, require confirmation before enabling those functions.

If you require an individual address, explain the requirement and provide a separate field for shared billing or operational contacts. A restriction imposed by your product does not make a technically usable address invalid.

## What the role name can tell you

A role-based email address is named for a function, such as support or sales. [RFC 2142, section 3](https://www.rfc-editor.org/rfc/rfc2142.html#section-3) describes business mailbox names including INFO, SALES and SUPPORT. Recognising the name does not establish that an organisation has created that mailbox.

The organisation might route its messages to one person, a shared inbox or a ticket system. Classifying the address by its name cannot reveal which arrangement applies. The [role-account glossary](https://emvero.io/glossary/role-account/) explains the definition and the signal’s limits.

Emvero compares the part before `@` with its dataset of role names. A match sets `checks.role_account` to `true` and adds `ROLE_ACCOUNT` to the reason codes. When comparing names, Emvero ignores letter case and removes any plus tag: `support+trial@example.com` can match the base name `support`. It leaves the submitted recipient address unchanged. Keep that original address for confirmation and future messages; the [plus-addressing guide](https://emvero.io/blog/email-address-with-plus-sign/) explains why removing the tag can change the destination.

The role flag does not tell you how many people read the mailbox. An address without the flag may also be shared. Neither result identifies a person, gives permission to send a campaign or demonstrates trial abuse.

## Choose the rule for the field’s purpose

An email field might collect a login address, an address for invoices or a support contact. Set the rule according to what the field is for. The following policies are recommendations for your application; Emvero does not apply them automatically.

| What you are collecting | Suggested policy for a role address | What remains to check |
| --- | --- | --- |
| A contact for invoices or service updates | Accept the address the customer chose for that purpose. | Check the customer’s request and whether the address is usable. Confirm mailbox access if the workflow depends on it. |
| A login for an account where shared mailbox access is acceptable | Allow signup, but require confirmation before enabling login or recovery through email. | Whether someone can complete the confirmation sent to that address. |
| A login for an account intended for one named user | Ask for an individual work address under an explicit account rule. Keep the shared contact separately. | Check identity and authorisation through your account controls. The address name cannot establish either. |
| A trial where you want to identify repeat registrations | Do not reject solely because the address names a function. | The account history and other relevant abuse evidence. One role address does not prove abuse, and another address does not prove a new person. |

For example, a customer may want `alex@example.com` for login and `billing@example.com` for invoices. Store the contact purpose explicitly. A restriction on the login field should not remove the billing contact from the customer record.

Even when you require an individual address, keep your identity and access checks. An address that looks like a person’s name gives you no stronger proof of identity than `support@`.

## Read ROLE_ACCOUNT alongside the verification result

In Emvero’s current policy, the role flag alone changes neither `status` nor `action`. This shortened, synthetic example shows a completed result with the role flag set. It omits other fields and is not a live response:

```
{
  "status": "deliverable",
  "action": "allow",
  "checks": {
    "smtp": "accepted",
    "role_account": true
  },
  "reason_codes": ["SMTP_RCPT_ACCEPTED", "ROLE_ACCOUNT"]
}
```

`allow` recommends continuing based on what the check found about the address. Your application may still require confirmation or an individual contact under its own access rules. Store the returned result and your application’s decision separately. Do not change `deliverable` to `undeliverable` to record a business restriction.

Other findings can change the overall result. A mailbox check for a role address may be inconclusive, or the address may belong to a catch-all domain. Read `status`, `action`, `checks` and `reason_codes` together, as explained in [interpreting a verification result](https://emvero.io/blog/reading-a-verification-result/). In particular, `risky` does not imply one fixed action.

## Keep confirmation separate from eligibility

Confirmation shows that someone accessed the message and completed your confirmation step at that time. It does not establish exclusive access to the mailbox or identify a particular employee. Emvero’s address check sends no confirmation message; your application must send the message and validate the response separately. The [verification and confirmation comparison](https://emvero.io/blog/email-verification-vs-email-confirmation/) explains what each step establishes.

On your server, store separately what the verification found, whether your rules permit the address and whether it has been confirmed. Bind confirmation to the exact address being confirmed. If the person changes that address, require a new confirmation for the replacement.

For a completed `unknown` result, the check could not reach a clear conclusion about the address. If mailbox access is what you need to establish, let the person continue with registration and require confirmation before granting email-dependent access. The action `allow_with_email_confirmation` recommends this path. Your application still performs the confirmation step; `unknown` does not establish that the address is invalid.

`pending` means the check is unfinished. Request the result again after the returned interval, and limit how long your application waits. An HTTP error indicates a request or service problem. Neither an error nor `pending` establishes that an address is `undeliverable`. The [signup-form validation guide](https://emvero.io/guides/signup-form-validation/) covers the server flow and what to do when you cannot wait any longer.

## Make a restriction easy to resolve

If an individual-address rule blocks signup, explain the requirement in the form. For example:

> This account needs your individual work email address for login. You can add a shared billing or support address after registration.

Use this wording only if the product provides that separate contact field. Otherwise explain the correction or contact option that is available. Keep the entered value so the person can edit it.

Avoid a message such as “This email address is invalid” when the only cause is your role-address rule. That would give a customer who uses the mailbox every day the wrong explanation. Enforce your acceptance rules on the server, even if the browser also displays feedback. Keep API credentials on the server.

## Check the policy before enabling it

Test each decision with synthetic inputs and predefined verification results. The cases below assume that your application has received the stated result; no example mailbox needs to be contacted.

| Case | Expected application behaviour |
| --- | --- |
| A role flag with `deliverable` and `allow`, shared contacts permitted | Continue; require mailbox confirmation if access depends on it. |
| The same result, but the login must use an individual contact | Explain the account rule and ask for another login address. Retain the original as a separate contact only if the customer chooses it. |
| A role flag with `unknown` | Keep the inconclusive result and require confirmation where appropriate. |
| An unfinished `pending` check | Keep verification marked as unfinished. Request the result again while your application can wait; use its fallback rule when the deadline expires. |
| No role flag | Apply the normal access and confirmation rules; do not infer personal identity. |

After enabling the rule, review where people abandon signup or correct their address, and whether they complete confirmation. Check that customers can still use their chosen billing contacts. Use those observations to decide whether the restriction helps meet the access requirement that justified it.

Once you have chosen the rule, use the [email verification API](https://emvero.io/email-verification-api/) on your server to check submitted addresses. Apply your acceptance rule and confirm mailbox access separately.

## Terms used here

### Role account

An address named for a function, such as support or billing, which may be read by one person or several.

### Catch-all domain

A domain that accepts arbitrary recipient names, so an accepted address may have no individual mailbox.

### Disposable email address

An address from a temporary-mail provider that can receive mail while active but may not remain available.

## Situations this applies to

### Validating an address in a signup form

Somebody is waiting on the other side of the request, so latency decides the design and a wrong rejection costs you the customer.

### Email validation at checkout

Check the address before payment, offer a correction and decide what happens if email is the only way to deliver the order. Uncertain evidence should not become a false address error.

[All articles](https://emvero.io/blog/)

## Choose what to check next.

Run a check from your account and inspect the evidence in its result.

Start for free