Using Suppression Lists

April 29, 2017 Contributors

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. NOTE: The Global Suppression List data is not accessible via the Suppression List API.

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?

  • Spam Complaints / FeedBack Loops (FBLs): 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.
  • Hard Bounces: 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.
  • Unsubscribe Requests: 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.The unsubscribe header is not added automatically for transactional messages (using the option transactional=true)
  • Compliance Team: 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’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.
  • 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 SparkPost Suppression List API.
  • Suppression list UI: In the User Interface choose lists and suppression list.

If you want to learn how your application can be notified of list pruning events, read our using unsubscribe events guide.

# 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:

NOTE: 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.

To inspect the status of a recipient on a Suppression List:

To remove a recipient from a Suppression List:

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.