Suppressions & Allowlists

Suppressions

Usually you would only visit these sections on occasion but suppressions are critical to maintaining email compliance. This is where addresses that should no longer recieve your emails are stored.

You should first migrate your suppression lists from your current ESP by using the Migrate your data option. We are constantly working on extending the supported integrations to provide you with an automated migration from as many platforms as possible. Alternativelly you could import your suppression lists using the Upload CSV option or manually add addresses one by one.

Suppressions are automatically populated by the system as you send out messages. The data is divided into 3 categories based on the cause of suppression:

  • Bounce - this is going to be your busiest suppression list that holds all the recipients that are permanently undeliverable, eg. non-existent addresses, inactive mailboxes, etc. This list prevents you from sending messages to such addresses and protects you from reputational impact of attempting delivery to non-existent addresses.
  • Unsubscribe - while your recipients once wanted to receive messages from you over time some of them change their mind. Their reasons may differ but the outcome is the same - they unsubscribe. Every recipient that unsubscribes is recorded in this suppression list along with the method they used and the date. Honoring unsubscribes is key to your legal compliance.
  • Complaint - this list contains the recipients who chose to report your message as unwanted aka. spam. We receive this type of information from the mailbox providers through so called feedback-loops. Such complaints affect your reputation and inbox placement if ignored. You should always strive to minimize complaints. The best way is to make sure your send valuable information that engages the recipient and by providing an easy way for the recipient to unsubscribe.
  • Block - unlike the above listed suppression type which are automatically populated the Block suppression list is fully in your control. This one allows you to suppress messages from being sent to a specified recipient under any circumstances. In addition to blocking specific recipients you can also block specific target domains by suppressing the domain by entering @example.com instead of jack@example.com.

All three suppression list types will prevent messages from being sent to the recipient in the same way.

Suppression exceptions

One exception to the suppression rules is for transactional messages. Since these are messages of highest importance for the recipient and often contain critical information they are not subject to unsubscribe and complaint suppression lists. Only bounces and block are suppressed to protect your domain reputation. Transactional messages can only be sent using domains that were approved to send transactional messages.

Allowlists

Recipients

As the name implies the Recipients Allowlist is the oposite of Suppressions. It allows you to specify recipients that must never be suppressed. The most common use cases is to add recipients who are part of the testing or approval process to make sure they always the the messages your send.

As the allowlists are usually fairly short and static we don't allow them to be updated in bulk. This is safety measure prevents accidental import of suppression lists into allowlists.

Addresses on allowlists can not be suppressed. Any bounces, complaints and unsubscribes made by allowlisted recipients are ignored.

URIs

URI Allowlist serve a completely different purpose. This security feature that allows you to protect your domain from abuse in case of compromised API credentials.

Imagine the following scenario - a malicious actor gets hold of your API key which is not locked to a specific IP address. That malicious actor can now send messages using your domain which will be fully authenticated (since Omnivery has been authorized by you). Except the content will not be exactly what you would send - some of the links would point to a fake login page of your ecommerce site, or online banking (whatever your company does). Such messages would be treated as fully authenticated by the receiving servers and would most likely end up right in the inbox of your trusting recipients.

When Domain URI Allowlist is enabled all messages will be scanned for links and those will be matched against the URI patterns that are in the allowlist. You can safely populate your URI allowlist with all the URI patterns before enabling the feature.

It takes up to 5 minutes for changes to take effect - be it enabling/disabling URI Allowlist or adding patterns.

Messages with links matching the URI patterns are let through. If a single link in the message body points to a destination that is NOT listed, the message will be rejected by the system and the phishing attempt (or mistake) will be stopped.

URI patterns are added by clicking the Add to list button and entering the URI pattern (regular expression) and a Note (for your convenience). You have to create a URI pattern for each of the links you intend to use in your messages to permit their use.

URI pattern example

^https:\/\/www\.linkedin\.com\/company\/omnivery - it's important to keep in mind the importance of escaping regular expressions as well as being as accurate as possible. This pattern only allows links to a specific page on LinkedIn rather than the whole linkedin.com domain.

Make sure the URI patterns are checking the string from the start whenever possible using the ^ rather than checking for specific content as the later could be circumvented.

Only permit destinations you are in control of - never add 3rd party link trackers, link shorteners, etc. to your list.