Your Marketo SPF entry doesn't matter (unless you're paying extra)

A frustrating myth in the Marketo world is that you must have SPF and DKIM set up for the domains you use in outbound emails.

In fact, unless you have specifically added branded envelope sender domains to your subscription — a paid additional feature — SPF doesn't matter at all. Even worse, in trying to add Marketo to your SPF record when it isn’t necessary, you can break your existing SPF record completely.

I've dialed up my rhetoric on this over time based on bad experiences and troubling research.

I used to say adding include:mktomail.com to an SPF TXT record was useless but harmless. Nails on a chalkboard to someone who knew it was a waste of time… but still, you do you.☺

Now, I have to come on stronger. You really must not spend any time on SPF, nor delegate your IT to spend any time on it, unless you’re absolutely positive your subscription requires it.

Let's go over why SPF doesn't matter unless you've added an extra feature to your Marketo subscription.

SPF protects envelope domains from malicious use

SPF is a mail protection measure that is specifically designed to protect envelope sender domains from impersonation by unauthorized people or services.

I don't want to rehash all of SPF's technical details here (there's profuse info online, though I'm also happy to answer specific questions as best I can). Rather, I want to help you understand the giant difference between

[a] the envelope sender that SPF hopes to protect from abuse

and

[b] the From: and Reply-to: headers you set in the Marketo email editor, which SPF could not care less about

Envelopes vs. letters (the email content is the “letter”)

The SMTP envelope, as its name suggests (that is, if you're old enough to remember physical letters!) represents what’s supposed to be the truthful information about the sender and recipient.

When you put a letter in a snail-mailbox, you write your name & address and the recipient's name & address, and that’s what dictates how the envelope (and thus the letter inside) moves from place to place. Either it goes to the recipient, or it “bounces” back to the sender reflected on the envelope if the recipient can't be found. The letter folded inside the snail-mail envelope, though, could reflect a totally different (and arbitrary) set of names & addresses, right?

An envelope could have From: Bruce Wayne, Wayne Manor and To: Commissioner Gordon, Gotham PD. But the letter inside could say, “Haha, it’s actually Joker and I’ve got your daughter!”

The envelope info (which Gotham Postal Service used to physically route the mail) need not appear on the letter. Nor vice versa.

In the physical world, of course, if the From: and To: on the envelope differ starkly from the From: and To: on the letter inside, you have a Wat? moment. But in the email world, there's little risk of confusion because — provided best practices are followed — the envelope sender is not shown to the recipient by default.

True, the recipient can usually find the envelope info if they hunt down the "View Details" or "View Original Message" button in their mail app, but few users do. As a result, they erroneously assume the From:, Reply-To:, and To: headers of the email (the email body + headers are the equivalent of the “letter” in the real world) represent the true routing of the message.

Bounces go to the envelope sender

Let's consider again my remark above about “bouncing.”

In the physical world, a message gets returned to the sender written on the envelope. In the Marketo world, a message also bounces to the envelope sender. Only you aren't getting the bounces, right? Marketo is getting the bounces so it can automatically update the lead's activity log and status. Yes, unless you have that branded sender domain extra on your account, your Marketo emails come from envelope senders like MUN-CHK-ID0⁠.673.0.7030.0.0.14263.7.2987038@em-sj-999.mktomail.com. That's the address that receives bounces — remember, bounces are for undeliverable mail, as opposed to manual and automated replies, which go to either the From: or Reply-To: — and that's also the only address that is relevant to SPF!

So when Marketo connects to a recipient's mailserver and transmits that envelope sender over the network, the mailserver looks up the SPF record for em-sj-999.mktomail.com in DNS. It doesn't look up the SPF record for the domain(s) that appear in the Reply-To: and From:. In fact, the recipient's server usually doesn't even have access to the email when it does the SPF lookup, so it couldn't look them up even if it wanted to! When the SPF check completes (the results are sorted into levels of success, failure, error, or neutrality) the message is either "weighted" for spamminess based on the result or rejected immediately for the most egregious failures. Whether you have a strict SPF policy, a loose SPF policy, or no policy at all for your Reply-To: and From: domain(s) is irrelevant.

The exceptional case is if you've knowingly added the branded sender domain option to your account. In this case, the envelope sender is @ one of your domains (usually a subdomain like mktg.example.com) so that domain's SPF does matter.

Why would you add this option? In hopes of of increasing deliverability by obscuring a known ESP/MAP, of course.

Branded envelope sender is often (but not always, depends on how much you pay) accompanied by a dedicated IP address, so you also get segregation of your email from other Marketo tenants' email. (The IP address is still within Marketo's IP range, though, so it doesn't take a genius to know you're using Marketo.)

Why does Marketo still tell you to set up SPF, even though they know it's usually a waste of your (and IT's) time? I can't say. They don't exactly upsell the branded sender option: you have to ask about it, and presumably if you're asking about you'd know that meant you had to add a corresponding SPF entry. Unfortunately, the fact that the official docs recommend SPF means that 3rd-party best practices guides have incorporated it as well.

Hope you've gained some clarity from this post. I purposely skipped over what an SMTP envelope looks like, because I didn't want this to turn into a deep technical lesson. Instead, I want to draw a distinction between [a] the way email is routed on the Internet and [b] the content of an email, including headers like Reply-To: and From: (and Subject: and many more). SPF only cares about [a].