Practical guide

Role addresses need context, not a blanket verdict

Last materially reviewed 2026-09-27

Quick answerA role flag describes an address characteristic; it does not settle your organisation’s permission or business need.
What to know

Separate characteristic from action

A shared functional inbox can be relevant to an existing relationship, or it can be inappropriate for the proposed message. The technical role classification alone does not resolve that distinction. Preserve the flag as an observation and make any business decision through the authorised process.

What to know

Avoid guessed owners

Do not infer a named individual, demographic profile or personal preference from a role address. The contact owner should be able to explain the relationship and intended communication without inventing facts.

What to know

A review example

A fictional maintenance contract uses a team inbox for service coordination. That does not automatically authorise promotional mail to the same inbox. Keep the operational record and marketing decision separate. If the verifier also reports uncertainty, that technical issue remains independent of the communication-purpose question.

What to know

Put it into practice

Imagine an organisation that communicates with a supplier through a functional team inbox. The address belongs in an operational relationship record, but that does not settle whether it belongs in a marketing audience. A role classification may help the record owner understand the contact format; it should not invent a person or permission. Keep the technical attribute, business purpose and exclusion state separate. If a platform has additional rules for role addresses, read those rules for the exact workflow instead of applying a universal ban or approval. A fictional acceptance test can include a role flag alongside both a favourable and an uncertain technical outcome. The mapping should preserve both pieces of information and route the action through the reviewed policy. Do not erase a legitimate service relationship simply because an address looks less personal, and do not infer demographic facts about its users.

Continue when useful

Next: Keep permission evidence separate from technical status

Never let a verification label rewrite whether a particular message is permitted.

Open Keep permission evidence separate from technical status →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Bouncer API introduction — Merchant documentation · docs.usebouncer.com · Merchant-controlled · checked 2026-09-27