- Help & API
Using Suppression Lists
Last Updated: Jan 25, 2017 06:34PM EST
Protecting your sender reputation is essential to maximizing your email deliverability. Many inbox providers, e.g. Yahoo, Gmail, Hotmail/Outlook.com, or AOL, opt to limit or refuse message traffic based on it. Continuing to send messages to invalid email addresses or to recipients who no longer want to receive your emails can negatively impact your sender reputation. By maintaining an up-to-date suppression list, you can avoid sending unwanted messages. A suppression list — or exclusion list, as it is sometimes called — is a list of recipient email addresses to which you do NOT want to send email.
SparkPost supports two types of suppression lists: one (available via the Suppression List API) is specifically for your account, and a global suppression list. SparkPost maintains a global suppression list across all customers. .
When a message is injected either using SMTP or HTTP, SparkPost will check the email address against the account-specific and global suppression lists. If an email address for a recipient matches an address on the list, that message will be rejected for delivery by SparkPost automatically.
Note: each subaccount has its own separate suppression list which is separate from the master account suppression list.
How are recipients added to suppression lists?
- When a recipient clicks the “this is spam” button provided by the ISP, the ISP sends a Spam Complaint or FBL message to SparkPost. SparkPost will automatically add the recipient's email address to your suppression list.
- When messages bounce, the ISP will include a message that lets the sender know whether it was a “Soft Bounce” or a “Hard Bounce”. A “Soft Bounce” is a temporary error or delay indicating that the message was set to a valid recipient address, while a “Hard Bounce” indicates that the message was sent to an invalid email address that should not be retried. SparkPost will automatically add any email address associated with a “Hard Bounce” to your suppression list.
- The unsubscribe header is not added automatically for transactional messages (using the option transactional=true) Recipients can request to be unsubscribed by clicking the SparkPost-provided unsubscribe link in the message or by using the List-Unsubscribe header. SparkPost will automatically add the recipient's email address to the suppression list.
- SparkPost's accounts is of the utmost importance. SparkPost's Compliance Team ensures that we’re acting as a good sender within the email community across all our customers and takes requests of recipients very seriously. If a request is received, the Compliance Team will add the recipient's email address to that sender’s suppression list. Recipients can contact SparkPost and request that they no longer receive messages from a particular sender. Protecting our customers’ brands and maintaining high deliverability across all
- SparkPost Suppression List API. Using the REST API, you can insert/update a single entry or multiple entries in your suppression list, check the suppression status for a specific recipient, or remove a recipient from your suppression list. For more information, see the
- Suppression list UI: In the User Interface choose lists and suppression list.
Managing Suppression Lists with SparkPost
Now that you have unsubscribe events being broadcasted to your webhook consumer, you can begin to watch for those events and prevent sending reputation damage by populating your SparkPost Suppression Lists.
To Insert or Update a recipient on a Suppression List:
PUTapi v1 suppression list recipient_email HTTP Content Type application json Authorization YOUR KEY HERE
If a message is designated as “Transactional”, the recipient will be suppressed from “Transactional messages. If the message is designated as “non-transactional”, the recipient will be suppressed from non-transactional messages.
GETapi v1 suppression list recipient_email HTTP Authorization YOUR KEY HERE Accept application json
DELETEapi v1 suppression list recipient_email HTTP Authorization YOUR KEY HERE Accept application json
You can also use the User Interface to manage the suppression list
Note: CSV upload with subaccounts will need individual files for upload.
Suppression List Events and Error Messages
If any address present on the given exclusion list for the type of message you are attempting to send (i.e. "transactional" or "non-transactional") is attempted, the message will automatically fail. The event data associated with a customer-specific exclusion list event will always begin with the same error message - 554 5.7.1 recipient address was suppressed due to customer policy - and will follow with the specific reason for it (e.g. "Bounce Rule" [hard bounce], "Spam Complaint", "List Unsubscribe", or "Link Unsubscribe").
The event data associated with our global proprietary suppression list event will always begin with the same error message - 554 5.7.1 recipient address was suppressed due to system policy - and will follow with the specific reason for it (e.g. "Bounce Rule" [hard bounce], "Spam Complaint", "List Unsubscribe", or "Link Unsubscribe").
Note: For single recipient transmissions, if a given email address is suppressed, the API response for the rejection will appear inline. However, if you are using multiple recipient transmissions, the API response will initially accept addresses which will be suppressed later in the message generation process. For multiple recipient transmissions which contain a suppressed address, you will notice that an injection event is recorded before the ultimate suppression, but an injection event is not recorded for a single recipient, inline suppression.