While working on a project for a friend, we decided to introduce a proper email validation logic on the front-end and add some extra validation rules on top of the standard email address syntax check.
While the emails would go out from a different system, this naturally got me thinking about the List Detective feature of Salesforce Marketing Cloud. Its importance is crucial for email deliverability, but the rules seem to be opaque.
The official documentation describes List Detective as:
a proprietary Marketing Cloud database of bad email addresses that your Lists are “scrubbed” against whenever they’re imported.
The database includes known email spam traps, blocklist addresses, wireless domains, retired (no longer active) email companies or webmail providers, global unsubscribes, and mistypes.
– source: List Detective Overview
That’s great, but what happens when List Detective encounters a new address in a domain it doesn’t know? The documentation claims it’s a database, but maybe it works more like an algorithm and has some rules that could be discovered.
Being curious, I decided to shed some light onto the topic.
The process involved throwing thousands of email addresses at this tool and seeing what could and couldn’t get through. You can read about this in this section.
The Structure of Email Addresses
Before we dive into the weeds of this topic, let’s just agree on the naming convention:
With that out of the way, we can just dive right into the findings.
The 4 rules of List Detective
Here’s what I was able to gather from my tests. The methodology of finding those rules or patterns is described later in the article.
1. Spam Traps
The words spam
, blacklist
, blocklist
can’t appear anywhere in the email address:
- ❌ Not in the local part
- spam@sfmclistdetectiverocks.com
- spam+tag@sfmclistdetectiverocks.com
- notaspamtrap@sfmclistdetectiverocks.com
- xxxblacklistxxx@sfmclistdetectiverocks.com
- xxxblocklistxxx@sfmclistdetectiverocks.com
- ❌ Not in the domain
- hello@spam.com
- hello@notaspamtrap
.com
- hello@thisisnotablacklistreally.xyz
- hello@xxxblocklistxxx.xyz
- ❌ Not even in the tag
- example+spam@gmail.com
While it is a common practice to have multiple addresses and use a less personal one for registrations, sometimes the spam string could appear by accident.
2. Forbidden Local Parts
We’re all standing on should of giants and I can’t write this part without mentioning the excellent research done by Cameron Robert and Abikarsa Kristanto published in this article: “Email Usernames blocked by Salesforce Marketing Cloud” about “Role-Based” email addresses.
In short:
some email addresses do not represent individual people, but rather roles they play in organizations. A classic example of this would be this email address: “info@sfmc.quest” – multiple people could be responding to messages to this inbox.
This is not really something you would want to support as a B2C (business-to-consumer) platform.
The following words are only prohibited if they are the full local-part (exist before the “@” sign without any other characters):
- abuse
- feedback
- hostmaster
- info
- invalid
- junk
- junkemail
- junkmail
- listserv
- mailerdaemon
- marketing
- news
- newsletter
- nobody
- noc
- noemail
- none
- noreply
- null
- ops
- orders
- postmaster
- press
- privacy
- remove
- root
- security
- subscribe
- support
- unsubscribe
- usenet
- uucp
- webmaster
- www
I’m not listing spam, blocklist and blacklist here as they are already included in the 1st Rule.
Why are some words red? Well, things got complicated when I was writing the first draft of this article…
Your Mileage May Vary Here
While discussing my findings with a friend, I noticed that a different SFMC account was not rejecting some of the words. The actual word list for this rule might be different for your stack or SFMC instance.
In my tests “admin” is a valid local part passing the validation on both accounts, but that might not be the case on your account.
The other account rejected those local parts:
- abuse
- info
- invalid
- junk
- junkemail
- junkmail
- listserv
- mailerdaemon
- nobody
- noc
- noemail
- none
- noreply
- nospam
- null
- postmaster
- privacy
- remove
- root
- spam
- subscribe
- support
- unsubscribe
- usenet
- uucp
- webmaster
- www
But didn’t reject those:
- feedback
- hostmaster
- marketing
- news
- newsletter
- ops
- orders
- press
- security
Keep this in mind if you do your pre-production testing on a different account – you might have differences in import behavior which could impact your tests.
Examples that would be rejected:
- ❌ stop@sfmclistdetectiverocks.com
- ❌ remove@sfmclistdetectiverocks.com
- ❌ support@sfmclistdetectiverocks.com
- ❌✔️ press@sfmclistdetectiverocks.com can be rejected on one account, but accepted on a different one
Ask SF Support for help with specific role-based usernames
If you want to have a specific word enabled, support agents are able to ALLOW role-based usernames on your behalf.
Allowing usernames is not a Custom List Detective feature – it only serves as way of handing custom DENY entries.
Use +tags to bypass this rule
This rule can be easily bypassed for some inboxes that support sub-addressing: you can just add a +tag to cause List Detective to accept addresses from the list above.
- ✔️ stop+tag@sfmc.quest
- ✔️ none+shallpass@sfmc.quest
- ✔️ mailerdaemon+banished@sfmc.quest
3. Prohibited .com domains
Email addresses in the following domains are blocked:
- ad.com
- address.com
- box.com
- client.com
- domain.com
- example.com
- host.com
- none.com
- test.com
- union.com
Only the .com versions of those domains seem to blocked by List Detective. Their .co.uk and .de versions pass validation without problems.
For example:
- ❌ hello@domain.com will be blocked
- ✔️ hello@domain.co.uk will be OK
- ✔️ hallo@domain.de will be OK
Subdomains of the above domains are NOT rejected by List Detective:
- ✔️ hello@mail.domain.com will be accepted
Use Custom List Detective to allow specific domains
Getting Custom List Detective enabled in your account will allow you to ask Salesforce Support agents to add specific domains to the “List Detective for Domains” custom allow list.
As with usernames / local parts, you only have the option to deny specific domains yourself.
4. Nobody’s Domains
For whatever reason the word nobody
seems to be a special kind of an restricted word – if it will be anywhere in the domain part, the validation rejects the entire address.
Here’s a list of rejected email addresses with this word anywhere after the @ sign:
- something@nobody.com
- something@nobody.co.uk
- something@nobody.de
- something@nobody.gov
- something@nobody.sfmc
- something@nobodysuffix.com
- something@prefixnobodysuffix.com
- something@prefixnobody.com
- something@something.nobody.com
- something@something.nobody.de
- something@nobody.sfmc.quest
- something@nobody.sfmclistdetectiverocks.com
On top of being problematic in domains, this word also exists in the forbidden local parts (rule 2.), but is not as restrictive as spam / blocklist / blacklist, because it can be bypassed by using a tag in the local part.
🕵️ Could there be more?
Yes, of course there could be more. This is just something I was able to gather from my tests. I tried word sets in German and Spanish, but couldn’t find any more rejected words than those mentioned above.
If you find something that could expand this list, please let me know, I’ll try to recreate that and include here.
Live Test Tool
You can use the form below to check if an email would match any of the rules above as you type (there’s no need to push the button really).