An Email Sending suppression list contains recipients that Email Service does not contact. Suppressions protect your sender reputation and help prevent sending unwanted mail.
Cloudflare creates suppressions after eligible delivery failures and spam complaints. You can also add entries for recipients who should not receive mail.
To add or remove entries, refer to Manage suppressions. Suppressions only apply to Email Sending.
Each suppression has a scope. The scope controls which sending domains the suppression applies to:
| Scope | Applies to |
|---|---|
account |
Every sending domain and subdomain in your account |
sending_domain |
One sending domain, such as mail.myappexample.com |
The sending domain of a message is the domain of its sender address. This is the from address for the REST API and Workers binding, and the envelope MAIL FROM address for SMTP.
A sending_domain suppression matches only its exact domain. A suppression for myappexample.com does not block mail from mail.myappexample.com, and a suppression for mail.myappexample.com does not block mail from myappexample.com.
Email Service suppresses a recipient if the address has an account suppression, or a sending_domain suppression for the sending domain of the message.
Bounce and complaint suppressions use the sending_domain scope, with the sending domain of the message that bounced or received the complaint. A complaint creates an account suppression when Cloudflare cannot identify the sending domain of the original message.
The following table describes automatic and manual creation rules and expiration:
| Reason | Created when | Expiration |
|---|---|---|
Manual (manual) |
You add the recipient through the dashboard or API | The time you choose, or no expiration |
Spam complaint (complaint) |
Cloudflare receives and validates a complaint from the recipient's email provider | No expiration |
Hard bounce (hard_bounce) |
Any other eligible recipient-side permanent rejection occurs | 7 days |
Hard bounce (hard_bounce) |
The recipient mailbox or domain does not exist, or a recipient-side issue persists across repeated delivery attempts | No expiration |
Soft bounce (soft_bounce) |
An eligible recipient-side temporary failure occurs, such as a full mailbox or rate limit | 24 hours by default |
The account Email Sending suppression management REST API can return Cloudflare-managed entries with a policy reason. Clients must use read_only to determine mutability, not infer it from reason.
You cannot update or delete an entry when read_only is true. To investigate one, contact Cloudflare Support.
Manual suppressions allow you to add application-level decisions that Email Service cannot observe. For example, if a user manually unsubscribes from emails in your app, you can add their email to your Email Service suppression list.
You select the expiration when creating the entry. An entry without an expiration remains active until you delete it.
You also select the scope. Manual suppressions use the account scope by default. Email Service does not check that your account sends from a sending_domain value. A suppression for a domain that you do not send from never blocks mail.
Email providers send feedback reports when recipients mark messages as spam. Cloudflare validates these reports before creating complaint suppressions.
Complaint suppressions are created without an expiration. You can change or delete one when read_only is false.
We recommend changing or deleting one only after the recipient opts in again through your application.
A hard bounce is a permanent rejection of one delivery attempt. Some addresses become valid again after their owner fixes the mailbox or domain.
Email Service creates a suppression without an expiration when the mailbox or domain does not exist. It also does this when a recipient-side issue persists across repeated delivery attempts without a successful delivery.
Other eligible hard-bounce suppressions last seven days.
A soft bounce is a temporary recipient-side failure. Examples include a full mailbox, a temporarily unavailable server, or recipient-side rate limiting.
Eligible soft-bounce suppressions last 24 hours by default. Email Service resumes sending after the suppression expires.
Not every temporary delivery failure creates a suppression. For example, Email Service does not suppress a recipient for a sender-side authentication or reputation problem.
Each sending domain has a Drop suppressed recipients setting. The setting is off by default.
| Sending method | Setting off | Setting on |
|---|---|---|
| REST API | Returns 400 and rejects the request when any recipient is suppressed. |
Removes suppressed recipients and processes the remaining recipients. |
| Workers binding | Throws E_RECIPIENT_SUPPRESSED and rejects the send() call when any recipient is suppressed. |
Removes suppressed recipients and processes the remaining recipients. |
| SMTP | Rejects the message when any recipient is suppressed. | Removes suppressed recipients and processes the remaining recipients. If none remain, SMTP may return 250 2.0.0 Ok without a Message-ID and delivers nothing. |
Suppressed recipients do not count toward your monthly quota or daily sending limits. They appear as Rejected in Email sending logs.
- Add manual suppressions for unsubscribes.
- Use the
accountscope when a recipient must not receive mail from any of your domains. Use thesending_domainscope when the decision applies to one subdomain only. - Require recipients to opt in again through your application.
- Verify addresses before deleting suppressions.
- Investigate patterns across repeated bounces.
- Let temporary suppressions expire automatically.
- Use Manage suppressions to manage entries through the dashboard or API.
- Review Email deliverability to understand bounce and complaint effects.
- Follow Email lifecycle to locate suppression checks in the sending flow.
- Review Suppression list limits for API limits.
- Use Email sending logs to investigate rejected sends.