Salesforce Marketing Cloud: Email validation, IP strategy
URL Copied
Just a quick post for today, with a couple of random bits of Salesforce Marketing Cloud (aka ExactTarget) info. These have been sitting in my notes for a while, and since I've got nothing else Marketing Cloud related to share right now, I figured I'd wrap them up into this tiny little post right here.
First, Salesforce Marketing Cloud has an email validation API. Did you know? I didn't know. Let's take a look at what the documentation says it can do. The "Validate Email" API has multiple criteria (validators): SyntaxValidator, MXValidator, and ListDetectiveValidator. One assumes syntax validator is a format checker. The reference to List Detective implies that the address is checked to see if its username or domain matches against the List Detective filtering list, meaning that Marketing Cloud would reject import of the address under normal circumstances. The MX Validator, I assume, is some sort of DNS check to look for a valid MX record, but be warned that this is but an assumption on my part.
If you're a Salesforce Marketing Cloud user and you capture addresses outside of Salesforce, this API might come in handy to help you ensure that you don't waste time later trying to import addresses that would fail their validation checks. Checking for address validity at point of capture is never a bad thing; it allows you to provide feedback to the potential subscriber, warning them that you don't think their address is valid, and giving them an opportunity to correct the address before submission.
This makes sense and seems like a sound policy. Clients on dedicated IP address are best positioned to control their own deliverability -- IP reputation, specifically, is based only on their sends and nobody else's. Occasionally a sender will want to siphon off some mail to send it via a shared IP address, usually because they're worried about potential reputation damage to their dedicated IP address.
The problem with moving that mail to a shared IP address or shared IP pool is that the damage still happens; it's just a shared IP that gets harmed, impacting multiple clients and system infrastructure. If you want to wrap it in metaphor, ask yourself, why would I want to let you set my own house on fire, engaging in activity that you didn't want to do inside your own house, because of that fear of fire?
Just a quick post for today, with a couple of random bits of Salesforce Marketing Cloud (aka ExactTarget) info. These have been sitting in my notes for a while, and since I've got nothing else Marketing Cloud related to share right now, I figured I'd wrap them up into this tiny little post right here.
First, Salesforce Marketing Cloud has an email validation API. Did you know? I didn't know. Let's take a look at what the documentation says it can do. The "Validate Email" API has multiple criteria (validators): SyntaxValidator, MXValidator, and ListDetectiveValidator. One assumes syntax validator is a format checker. The reference to List Detective implies that the address is checked to see if its username or domain matches against the List Detective filtering list, meaning that Marketing Cloud would reject import of the address under normal circumstances. The MX Validator, I assume, is some sort of DNS check to look for a valid MX record, but be warned that this is but an assumption on my part.
If you're a Salesforce Marketing Cloud user and you capture addresses outside of Salesforce, this API might come in handy to help you ensure that you don't waste time later trying to import addresses that would fail their validation checks. Checking for address validity at point of capture is never a bad thing; it allows you to provide feedback to the potential subscriber, warning them that you don't think their address is valid, and giving them an opportunity to correct the address before submission.
Next, Marketing Cloud shared/dedicated IP policies have apparently been updated, Stefano Crepaz, Salesforce Marketing Cloud Lead for Richemont shared back in October. The change? Salesforce will no longer allow a mix of configuration between shared IP and dedicated IP for business units (child accounts) inside of the same Enterprise (account grouping). Meaning that if your set of accounts has dedicated IP addresses configured, they are not able to grant you any access to send any mail via shared IP addresses.
The problem with moving that mail to a shared IP address or shared IP pool is that the damage still happens; it's just a shared IP that gets harmed, impacting multiple clients and system infrastructure. If you want to wrap it in metaphor, ask yourself, why would I want to let you set my own house on fire, engaging in activity that you didn't want to do inside your own house, because of that fear of fire?
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.