How to Set a Team Email Validation Policy

by EmailGuard Marketing

Unsplash

September 18, 2026marketing8 min read

Share this article

Enjoyed this article?

More notes on building products, infrastructure, and teams.

A team email validation policy is an allow or deny overlay on top of global classification. EmailGuard still runs syntax, disposable, role, relay, and the rest. Then your team's rules can change how that result is applied. Deny wins if both match. Allow can turn disposable off for that response. Deny sets suggested_action to block and does not pretend the domain is disposable.

Configure this under Team → Email policy. Field-level contract: team email policy in the knowledge base. This page is the signup and RevOps playbook.

What you'll accomplish

Separate global intelligence from your exceptions.
Write allow/deny rules on domain or local-part without building a mailbox allowlist.
Read policy_action and suggested_action in the detect body.
Avoid using confidence as a fake per-customer score.

Prerequisites: Owner or Admin (account:update) to create or delete rules. account:read can list them. Creates and deletes land in Team → Security audit logs as EMAIL_TEAM_POLICY_RULE_CREATED and EMAIL_TEAM_POLICY_RULE_DELETED.

Why a global blocklist is the wrong exception path

You will get a legitimate case that looks like abuse.

A partner still uses a domain that sits on a disposable-adjacent cluster you want to allow for this team only.
A consumer product wants to deny info@ and admin@ even when you allow role addresses on the sales form. That is a role-based signup policy plus, if needed, a local-part deny.
A B2B workspace wants to deny a few public domains on the billing form only. That is closer to require a work email. Put the job on the right form. Use team policy for exceptions that must live in the API response, not only in one app.

Do not encode those exceptions by asking us to delete a domain from the global catalog. The catalog is shared. The overlay is yours.

This is not SMTP. It is not a list of mailboxes we probed. Patterns are stored lowercase. A team can keep at most 100 rules.

Rule shape

Field	Values
Action	`allow` or `deny`
Match	`domain` or `local_part`
Pattern	Hostname or local-part string

How the overlay applies, in order:

Global detect runs (syntax, disposable, relay, and the rest).
Matching team rules run.
Deny wins if an allow and a deny both match.
Allow turns disposable off for that response and sets policy_action and suggested_action to allow.
Deny sets policy_action to deny and suggested_action to block. It does not set disposable to true.

When no overlay matches, policy_action and suggested_action are omitted. suggested_action is not a global risk score. It is this team's overlay.

confidence stays high, medium, or low for the classification path. Do not stretch it into a per-tenant grade. If you need an exception, write a rule.

Worked cases

Allow a vendor domain you trust. Pattern partner-temp.example, action allow, match domain. A signup that would have been disposable for everyone else is allowed for your team. Your app should honor suggested_action: allow even if you usually block disposable. After the overlay, disposable is already false on the body.

Deny a local-part on every domain. Pattern noreply, action deny, match local-part. Useful when role_address is too wide or too narrow for one form. Still store role_address for analytics.

Deny a public domain on one product. Prefer the public_domain flag and a form-level rule. A team deny on gmail.com will also hit people you might want on a consumer surface that shares the same API key. Split keys or split apps if the jobs disagree.

Allow plus deny on the same address. Deny wins. Do not build a mental model of "more specific wins" unless we document that later. Today it is deny-wins.

What your app should branch on

type Detect = {
  disposable: boolean;
  suggested_action?: "allow" | "block";
  syntax_validation: boolean;
};
 
export function applyTeamOverlay(d: Detect): "reject" | "create" {
  if (!d.syntax_validation) return "reject";
  if (d.suggested_action === "block") return "reject";
  if (d.suggested_action === "allow") return "create";
  if (d.disposable) return "reject";
  return "create";
}

If you only look at disposable and ignore suggested_action, you will miss denies that never flipped the disposable bit. That is the footgun.

Transport errors still follow fail open vs fail closed. An overlay cannot run if detect never returned 2xx.

Dashboard vs API

Rules live in the dashboard overlay. Detect is still GET /api/v1/emails/detect. SDKs expose the same field names as the OpenAPI detect body.

Members who can only read rules should not be your only reviewers. Owners and Admins create and delete. Every mutation is auditable. If a partner is suddenly allowed, you want the log row, not a Slack guess.

Free and paid plans that include detect can use the overlay. Volume still follows pricing. The 100-rule cap is a product limit, not a billing joke.

When not to use the overlay

Per-form jobs. Consumer signup vs sales demo vs billing contact should differ in application code. Sharing one API key and then stacking 40 denies that only apply to billing will surprise the consumer form. Use public_domain and role_address in the handler that owns the form.

Trying to simulate SMTP. Allowing random@customer.com because "they are catch-all" is not something the overlay can know. We do not probe catch-all. Send a confirmation email.

Replacing disposable detection. If you deny mailinator.com by hand, you will miss the next host on the same farm. Let global disposable run. Use allow only for a named exception you can defend in the audit log.

Local-part allows that mint aliases. Allowing admin globally is how you re-open a role hole you just closed. Prefer deny on local-part, allow on domain.

Rollout

Week 0: list rules, create none. Confirm detect bodies omit suggested_action.
Week 1: one deny you already enforce in code. Compare overlay block rate to the old handler.
Week 1: one allow for a known partner domain. Confirm disposable is false and suggested_action is allow on that domain only.
Week 2: point production signup at suggested_action first. Keep a metric for overlay blocks vs global disposable blocks.
Anytime: after an allow, watch the dashboard mix so a partner exception does not become your new top "disposable" source in disguise.

Staff audit events are documented with the other team actions in audit log events. If a rule appears without a ticket, revert it.

Permissions live with other team roles. People with account:read can see the list. They cannot silently add an allow.

Multiple apps, one team

The overlay is per team, not per API key. A mobile app and a web app that share the team inherit the same allow/deny set. If mobile must stay open and web must deny gmail.com, you need two teams or you need the deny in the web handler only.

SDKs do not configure rules. They only read detect. Humans change policy in the dashboard. That is deliberate. A compromised email:detect key should not also rewrite your allow list.

Wildcard patterns are not documented as supported. Send the exact domain or local-part. If you need *.temp.partner.com, that is not this overlay. File it as application code or wait for a richer matcher.

DNS flags (mx_present, wildcard_dns) are unchanged by overlay. An allow does not invent MX. A deny does not clear mx_present. See MX vs validation if you were about to mix those fields.

Common mistakes

Using allow as a silent SMTP pass. We still have not pinged the mailbox.

Expecting deny to mark disposable. Support will look at disposable: false and think the rule failed. Read suggested_action.

Copying the same deny list into the browser. Users bypass it. Enforce on the server.

Treating team policy as a replacement for role or work-email articles. Those flags still exist. Overlay is for exceptions and extra denies.

Skipping audit review. If you allow a true throwaway farm for one customer, write down why in your own ticket. The product log only records that the rule was created.

FAQ

What is a team email validation policy?

An allow or deny list your team attaches to detect. Global classification still runs. Matching rules change policy_action, suggested_action, and sometimes disposable.

Does allow mean the inbox exists?

No. It means your team overrode the overlay for that pattern.

Who can edit rules?

Owners and Admins (account:update). Listing is account:read.

What happens if allow and deny both match?

Deny wins.

Is this the same as confidence?

No. Confidence is high/medium/low on the classification. Overlay is your exception list.

Next steps

Open Team → Email policy and add one deny you already enforce in application code.
Point staging signup at suggested_action before disposable.
Keep form-level jobs on work email and role policy.
Read features when you are mapping every flag, not only the overlay.