ESPs, Non-portable Reputation and Vendor Lock-in

I’ve seen some mentions recently of ESPs suggesting that if you use your own domain in the From: of mail you send through an ESP then that ESP can’t “do email authentication” properly unless they require you to edit your domains DNS settings. That’s not really so, but there is a kernel of truth in there.
The real situation is, unsurprisingly, a bit more complicated.
What authentication features should you look for in an ESP?

1. Awareness of email authentication, specifically SPF and DKIM
2. They encourage you to use your own domain for authentication, but don’t require it
3. They suggest you add something like “include:cust-spf.exacttarget.com” to an existing SPF record, rather than anything with “ip4:” in it
4. They suggest you add an NS record something like “espname._domainkey.yourcompany.com” to your DNS for DKIM support
5. They ask you specifically what domain you’d like to use for authentication, rather than requiring it be the same as the domain you use in your From: field
   
6. They check that any DNS changes you’ve made are correct before sending email

7. They monitor your DNS changes, to protect you from mistakes in the future

What authentication mistakes should make you wary of an ESP?

1. Any suggestion that your reputation as a sender isn’t important, rather that it’s solely the ESPs job to get good delivery rates
2. Any suggestion that the ESPs reputation is completely irrelevant, and your mail will be delivered solely based on your reputation
3. They tell you that the domain name used in your email From: has to have anything to do with authentication
4. They tell you to add a TXT record for SPF records, rather than adding an “include:” clause to your existing record
5. They tell you to add anything with “ip4:” in it to your DNS
6. They tell you to add an NS record like “_domainkey.yourcompany.com”
7. Any suggestion you use ADSP (1).
8. Any mention of DomainKeys (2)

Reputation?
When we’re talking “authentication” we’re really talking about SPF and DKIM. Both are ways to associate an identifier with the email that’s sent that receivers can use to track the reputation of your mail (so that you can get the delivery benefits of your history of sending wanted mail) and manage whitelisting and feedback loops and all sorts of other good things. See dkimcore.org for more details on why authentication can be a good thing.
Neither SPF nor DKIM require you to use the same domain you use in your From: header as you use for authentication. This has a couple of really important implications:

1. Your ESP can use a domain of their own for authentication. That means that you can get some of the advantages of authentication (feedback loops, non-portable reputation) without having to edit your DNS or even knowing anything about what your ESP is doing.
2. If you use a range of different domains in your From: field (for brand-specific mailing, maybe) you can use the a single identifier for authentication across all that mail, getting all the benefits of your history of sending wanted email for BrandA and BrandB when you launch a new campaign for BrandC.

Portable vs non-portable reputation
I used the term “non-portable reputation” there without explaining it.
Non-portable reputation is reputation that is tied to your ESP – as you send wanted mail from that ESP your reputation with ISPs receiving the mail will get better and better, and you’ll get all the delivery advantages associated with that. But if you take your business to another ESP, or start sending some mail yourself, you’ll lose all that good reputation and have to start over.
Portable reputation is reputation that is tied to you, and mostly independent of your ESP. You can build up a history of sending email that people want to receive through one ESP, then you can move to a different ESP and take all that good history with you, keeping all the delivery advantages. (Or use multiple ESPs for different campaigns and send some mail from in-house and pool your good reputation across all those sources of mail.)
If you’re a reputable sender, sending mail that people want, then building a portable reputation will significantly benefit you. It does require you to configure your domains DNS records to support it, though, which can be tricky to set up and isn’t supported well by some DNS providers. So if you’re just beginning to dangle your toes in email marketing using non-portable reputation from your ESP is a great way to get going, but you should plan on switching to using portable reputation if email is going to be important to your business.
Some ESPs don’t really like the idea of portable reputation as without it their good customers are likely to take a significant delivery rate hit if they move elsewhere – and that vendor lock-in helps them keep those customers. Better ESPs are more likely to be enthusiastic about portable reputation as while it makes it easier for customers to move to competing ESPs it will also make it easy for them to move to them from their competitors. Without that disincentive for customers to move from one ESP to another it makes it easier for good ESPs to compete based on price and quality of service.
You really want to be able to get portable reputation using both SPF and DKIM. For that you’ll want to use a consistent domain for authentication, often your main corporate domain, even if you use a range of domains in your From: field. You want to be able to do this in a way that doesn’t tie you to using a single ESP for all your mail, rather that lets you use multiple ESPs simultaneously without losing your reputation. And you want it done in a way that doesn’t require you to be involved in editing DNS records any time any of those ESPs needs to make a change, otherwise the IT overhead and the risk of mistakes will be something you’ll regret.
For SPF this can best be done with a DNS record that looks something like

yourdomain.com TXT “v=spf1 mx include:cust-spf.esp1.com include:cust-spf.esp2.com include:cust-spf.esp3.com ~all”

… possibly with a few “ip4:” fields near the beginning to specify your corporate mailservers. The use of include: to pull in the SPF configuration for each of the ESPs you use allows you to have valid SPF records for each of those ESPs, and allows them to make any changes that are needed as they rearchitect their networks without needing to bother you.
For DKIM this can best be done with a set of DNS records that looks something like

yourdomain._domainkey.yourdomain.com TXT (a DKIM public key goes here, if you want to use DKIM on mail you send yourself)
esp1._domainkey.yourdomain.com NS dkim-ns1.esp1.com
esp1._domainkey.yourdomain.com NS dkim-ns2.esp1.com
esp2._domainkey.yourdomain.com NS ns1.esp2.com
esp2._domainkey.yourdomain.com NS ns2.esp2.com
esp3._domainkey.yourdomain.com NS dkim-nameserver.esp3.com

The first record is just if you’re using DKIM (or DKIM Core) for mail you’re sending yourself. The remaining records allow the ESPs you’re using to do all the magic that’s needed to sign with DKIM – generating and rotating key pairs, publishing public keys, expiring public keys and so on – without needing you to do anything further once the NS records are set up.
If an ESP suggests that instead of delegating something like “esp1._domainkey.yourdomain.com” you instead delegate “_domainkey.yourdomain.com” then run away. If you were to do that it would make it impossible for you to use DKIM with any other ESP, or even to use it yourself.
(If you are an ESP, and you want more details on how to set up DKIM in this way, take a look at this.)
(Footnotes)

1. ADSP is an extension of DKIM that can provide some minor benefits in rare circumstances, but will cause significant delivery problems most of the time. ADSP shouldn’t come up in conversation with an ESP unless you bring it up (and you shouldn’t do that unless you’re intimately aware of the damage it will do to your delivery)
2. DomainKeys is the forerunner to DKIM. It’s obsolete now, and while a small number of ISPs still pay attention to DomainKeys signatures when there’s no DKIM signature, and some senders sign with both, there’s really no need for anyone to use DomainKeys today.