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.
Suppressions are account-scoped. Once an email address is on the suppression list, Email Service suppresses sends to that address from every domain in your account.
If you need separate suppression lists for different use cases, consider using separate Cloudflare accounts.
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.
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.
- 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.