Email policy
Allow or deny domains and local-parts after EmailGuard classification, from the dashboard overlay.
Team email policy is an overlay on GET /api/v1/emails/detect. Global intelligence still runs. Then your team's allow and deny rules can change how that result is applied.
Open Team → Email policy in the dashboard. Members with account:read can list rules. Creating or deleting a rule needs account:update (Owner and Admin). Creates and deletes are recorded in Team → Security audit logs (EMAIL_TEAM_POLICY_RULE_CREATED / EMAIL_TEAM_POLICY_RULE_DELETED).
This is not a mailbox allowlist. It does not probe SMTP.
Rule shape
Each rule has:
| Field | Values |
|---|---|
| Action | allow or deny |
| Match | domain or local_part |
| Pattern | Domain host or local-part string, stored lowercase |
A team can store at most 100 rules.
How overlay applies
- EmailGuard classifies the address as usual (syntax, disposable, relay, and the rest).
- Matching team rules run.
- Deny wins if both an allow and a deny match.
- Allow turns
disposableoff for that response and setspolicy_actionandsuggested_actiontoallow. - Deny sets
policy_actiontodenyandsuggested_actiontoblock. It does not flipdisposableto true. Your app should treatsuggested_action: blockas the overlay decision.
policy_action and suggested_action are omitted when no overlay rule matched. suggested_action is not a global risk score. It only reflects this team's overlay.
When to use it
Use allow for a partner domain that looks disposable in global data but you still accept. Use deny for a local-part (info, admin) or a domain you never want, even when it is not disposable.
Do not try to encode your whole signup matrix here. Keep hard blocks on syntax_validation and disposable in application code, then add overlay rules for exceptions.