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 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 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 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. 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 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 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 on your server to check submitted addresses. Apply your acceptance rule and confirm mailbox access separately.