Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lukewd]

Hi all,

I wanted to pose a question to the experienced ESP pmta admins out there. Do you have any suggestions for discarding certain role based email addresses in your feeder application, such as the obvious abuse@ and postmaster@ addresses? And, do you have a list of domains that people should never send email marketing to? For example, spamcop.com...

In an effort to improve our compliance we want to start building a resource of such domains and addresses so we can better detect low quality customers during onboarding, before they get the chance to ruin our sending IP's reputation with bought/scraped/harvested lists.

It would be a great resource if everyone shared their knowledge on this here.

To start it off, these are the role based emails we drop for our campaign based clients:
^admin@.*$
^abuse@.*$
^postmaster@.*$
^noc@.*$
^root@.*$
^security@.*$
^sysadmin@.*$
^compliance@.*$
^registrar@.*$

All suggestions welcomed.

[KentM]

support@
spam@
privacy@
hostmaster@

[jobeck]

Although we're not discarding them yet, we've found that info@ is decent indicator of a poor list.

[sfjedi]

Here are a few more:

Jobs@
help@
press@

[Blates]

Check Port25's latest blog post.

http://www.port25.com/indicators-of-a-poor-list-role-based-accounts-to-discard/

Also anything with the word spamhaus in would probably be good...

[VIN786]

While most of the role based accounts listed make sense to exclude, but it really boils down to what type of email your clients send. It is also important to understand how your client captures lead/prospect or customer email address.

There are legitimate reasons to allow emails like info@, support@, billing@, etc., unless you or your clients use third party lists to send marketing/soliciting campaigns.

[KentM]

We allow our clients to send to role based email addresses, but they must use confirmed opt-in. If the contact does not confirm they will be suppressed in their account, that way there isn't much risk.

Kent M