Cloudflare’s Email Sending service now supports a per‑domain suppression scope, allowing you to target suppressions at a specific sending domain rather than the entire account. This change matters because it prevents a problem with one domain—such as a bounce or complaint—from unintentionally silencing recipients for all other domains you manage.
New Suppression Scope Options
Two scope types are available:
- account – The default behavior; the suppression applies to every sending domain and sub‑domain under the account.
- sending_domain – The suppression is limited to the named sending domain only. For example, a suppression for
mail.myappexample.comdoes not affectmyappexample.comor any other domain.
Automatic bounce and complaint suppressions are now generated at the sending_domain level, giving you finer‑grained control over delivery health.
Using the Scope via Dashboard and API
In the Cloudflare dashboard, navigate to Email Sending → Suppressions and select Sending domain from the Scope dropdown. When importing suppressions, each row can specify a scope, or you can set a default for the whole import.
When creating a suppression programmatically, include a scope object in the JSON payload. Example:
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/email/sending/suppressions \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--header "Content-Type: application/json" \
--data '{
"email": "user@example.net",
"scope": { "type": "sending_domain", "value": "mail.myappexample.com" }
}'Listing suppressions for a single domain adds scope_type=sending_domain&scope_value=mail.myappexample.com to the query string. Omitting the scope field retains the legacy account behavior, so existing scripts continue to work unchanged.
Operational Impact
The per‑domain scope reduces the blast radius of a bad address list or a misbehaving mail server. Teams can now isolate problematic recipients to the offending domain without affecting other services that share the same Cloudflare account. Automation pipelines that bulk‑import suppressions should be reviewed to ensure they set the intended scope, especially if they previously relied on the default account‑wide behavior.
Because the API still defaults to account when scope is omitted, there is no immediate breakage for legacy integrations. However, adopting the new scope where appropriate can improve deliverability metrics and simplify troubleshooting.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
• Update any suppression import scripts to explicitly set scope.type to sending_domain when domain‑level granularity is required.
• Review existing suppressions to identify any that should be narrowed from account‑wide to domain‑specific.
• Adjust monitoring and alerting to differentiate between account‑level and domain‑level suppression events.
• Verify that your CI/CD pipelines and IaC templates include the new scope field where relevant.
