2

I'm working with a client who will is Marketing Cloud for B2B marketing.

Due to the nature of B2B marketing, a large percentage of their customers use role-based email addresses (for example, [email protected]) and role-based email addresses are suppressed by List Detective by default.

I understand the reason for blocking role-based email addresses, as these typically indicate that the email is being sent to a group or an employee with a role, rather than an individual person and as a result, it's not possible to verify that the Subscriber attached to these role-based addresses has given their consent to receive emails. However, customers with role-based email addresses (for my client) have explicitly opted-in and I don't foresee any deliverability or complaint concerns in sending to these recipients (but we will monitor this).

While exceptions can be created for individual role usernames (e.g. accounts@, sales@, etc), these have to be submitted and granted on a case-by-case basis through Salesforce Support. There's no 'whitelist' where you can add these yourself and you can't request that this feature to be "turned off".

The issue is that Marketing Cloud don't publicly disclose all role-based usernames that they are blocking. And there doesn't appear to be a way that you can validate whether the email address will be accepted by List Detective.

I thought of using the validateEmail API method, but this always returns true for role-based emails. For example, the following payload:

{
  "email": "[email protected]",
  "validators": [ "SyntaxValidator", "MXValidator", "ListDetectiveValidator" ]
}

Returns the response:

{
    "email": "[email protected]",
    "valid": true
}

While I could write a query to find all role-based email addresses of all my clients Subscribers based on this list of role-based usernames, this won't necessarily match Marketing Cloud's list.

The only solution I can think of is to monitor which Subscribers do not receive an email for a given email JobId, then submit a support request on a case-by-case basis to enable these role-based addresses. However, this is a significant amount of manual work.

How are other Marketing Cloud users managing role-based email addresses for B2B Subscribers?

4
  • I had a similar scenario here where one of the BUs were setup for B2B communications. We haven't had to use API however, I extracted the complete database to scan and merge similar role based emails and sent the list to Salesforce support to get these added in the exception list in List detective. Commented Aug 31, 2018 at 1:40
  • @BradSapkota, thanks for this. The issue that I have is that new Subscribers are being created all the time and without having knowledge of which role-based emails are being blacklisted, I can't identify which ones to exclude. Also, I assume there are language considerations to, for example accounts@, cuentas@ (Spanish), comptes@ (French) and so on. But, I'm not sure if they only exclude English based usernames. I guess we just to have to try sending to these addresses and see if they get through, then generate an exception report of all addresses that did not send... Commented Aug 31, 2018 at 1:46
  • 1
    i have just run the API and I am getting the validations as false if i enter a role based email that isn't part of the list detective exceptions Commented Aug 31, 2018 at 1:47
  • I'm in the same situation currently. The company i work for have B2B and B2C customers and we only send emails to subscribers (not purchased lists). So although i know these role based emails want to receive our emails, i'm worried that if i customise list detective to allow role based emails ISP's still see this practice as unfavorable and we could still end up damaging our sender reputation. Wondering if you ended up customising list detective and whether it affected your deliverablity in any way?
    – CRMdelaCRM
    Commented Jun 14 at 9:20

1 Answer 1

4

It turns out you can use the validateEmail REST API method to validate if an email will be blocked by ListDetective.

While I tried this originally (as per my question), it always returned true in the specific account I was using, but I see that it's returning false in other accounts, so it looks the this could be a good solution to validate questionable email addresses prior to sending.

Alternatively, you create an exception report of all email addresses that were not sent (using a Query Activity to return SubscriberKeys from the sendable DE that do not appear in the Sent Data View) for a given send.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .