In this blog post, we would like to point out several things that ESPs (Email Service Providers) can do to mutually benefit themselves and us as a classic DNSBL (aka. blacklist/blocklist) provider.

This is based on the talk that I gave at the Inbox Expo 2021 online conference on March 24th, 2021:

1. Segment outbound SMTP traffic by IP

Use different outbound pools for different classes of customers, some ideas for this segmentation might be:

• New customers
• Free-tier customers (if applicable)
• Existing customers (once good behavior is proven)
• Customers that use confirmed opt-in (COI)
• Customers that do not use COI
• Customers with affiliate programs

This avoids different classes of customers affecting the others and helps manage the risk of each type. Most importantly publish this information so that postmasters know what the IP ranges are for each pool.

2. Use subdomains for each customer

Where you are using your own domains for things like click/open tracking, use a subdomain for each customer.   Publish your policy of doing this and which domains are used for what.

This would help us only block domains that affect a single customer in the case of issues.  And in the case of a listing, you would immediately know who the problem customer was.

3. Publish an SPF record that only contains your sending ranges

Make sure that you publish dedicated records that your customers will include in their own SPF records and make sure these are public and easily discovered.

These should ideally only provide ip4:/ip6: mechanisms for your sending ranges and pools.

Any SPF mechanisms that cause DNS lookups (e.g. a:, ptr: include:) should be avoided where possible as there is a limit of 10 lookups for an SPF lookup, so if the customer has multiple includes in their own records, then this limit can quickly be exceeded which will cause SPF failures.

We use SPF records for whitelisting purposes and extract the ip4:/ip6: ranges from them along with the IPs found from any a: lookups.

4. Create and maintain a “postmaster” page

This would document all of the points above along with any other pertinent information for mail administrators or security researchers.  e.g.  Company name and address, who to contact for technical/abuse issues etc.

Any domains that you use in email messages or rDNS domains should then point to this if they are visited with a browser instead of going nowhere.

We’ll be far less likely to block a domain if we can easily find out what it is being used for and by whom.

5. Check before you send

Have a series of pre-flight checks that you’ll do prior to sends from new customers and periodically for existing customers.   These can grow over time as you find new things that work to prevent abuse from leaving your network.

For example:

• If someone clicks “Reply” on a message that you are sending – their reply should never hard bounce.
• When the receiving system gets the message the SPF result should be Pass, Neutral or None.  Anything else (e.g. SoftFail, Fail, PermError, TempError) should not be permitted.
• Beware of Reply-To headers that point to a different organizational domain e.g. to a freemail domain.
• Beware of messages where the From: header “Display Name” is changed from normal, is frequently changing or matches certain keywords (e.g. frequently Phished domains).
• Beware of accounts where account details and billing are being frequently changed.
• Be more aggressive with new accounts, look for red flags e.g. high numbers of: role accounts, unresolvable domains, domains with no functional MX etc.

6. Make sure your bounce/reject handling actually works

Some of our trap classes reject every single piece of mail sent to them, however, they do this at the end of DATA, so that we can see the message before we reject it.

We’ve had a number of occurrences in the last few years of smaller ESPs where this was broken and they didn’t realize.

7. Help your customers with best practices

Make sure they use confirmed opt-in (COI) and sign-up pages with good anti-bot mechanisms.
I can’t stress enough how important these points are. There are plenty of bots looking for sign-up forms that they can abuse to send spam by proxy (e.g. via contact forms that send a copy to the submitter). These bots are not very selective, so if they discover a list sign-up form that doesn’t do COI and has no protection against bots, then it’s going to get poisoned eventually.

We, as Abusix, will never reveal our trap domains and we’re not going to spend our time unsubscribing them. If a list is poisoned in this way, it either needs to be rewound to a point prior to the poisoning, re-confirmed, or scrapped completely.

I would go so far as to suggest that you charge a premium to customers who do not do COI as this will bite sooner or later and it will cost you time, money, and other angry customers.

8. Learn from your previous abuse

Every time your system is abused or problems are caused by a rogue customer, make sure you ask:

• “How can we learn from this?”
• “What can we do to avoid this happening again?”
• “How can I make the clean-up easier if it happens again?”
• “What processes can be improved?”
• “Are there any patterns to the abuse?”

You should be able to learn something new and put additional measures in place every single time this happens.

I hope you found this useful, I’d love to hear your thoughts. Is there anything that I missed that you would add to this list – get in touch with me via LinkedIn or the Chat function at the bottom right of this page.

Thank you,
Steve