Want to ensure your Marketo emails bounce, or at least a healthy share of ’em? Try this:
Ideally, the Marketo Email Editor wouldn’t even let you try to use the lead’s own Email Address as the From. But it’s impossible to detect all the methods of using that variable[1], so you’re trusted to do the right thing.
Unfortunately, most MOPS folks are only passingly familiar with DKIM, SPF, and DMARC (to be fair, same goes for the IT folks who really should know how they work!).
So you might think “What if my sales alerts looked like an email from the person who filled out the form?” without realizing that’s exactly what DMARC is designed to prevent.
Assume DMARC is in use
First off: it doesn't matter whether your domain uses DMARC. Whether your own IT team has added a DMARC DNS TXT record (_dmarc.example.com) is immaterial.
What matters is whether the lead’s IT team has enabled DMARC, with a reject or quarantine policy (note DMARC isn’t much use without one of these policies) for their domain.
And you’ll find that large email providers have done so:
_dmarc.google.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"
_dmarc.outlook.com. 1080 IN TXT "v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1"
_dmarc.yahoo.com. 1241 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"Many other domains, large and small, also use DMARC. There are about 5 million domains[2] with published records, although admittedly only 1/3 of them use p=reject or p=quarantine. If a business values its brand and has a capable IT team, they almost certainly have a DMARC record in their stack.
In practice, every single lead won’t be @ a DMARC-protected domain, but you must build for the strictest common denominator.
SPF + DKIM + DMARC via metaphor
SPF and DKIM are both authorization/authentication/non-repudiation mechanisms, so the reason DMARC also exists can be hard to grasp.
But I’ll try a metaphor (yikes) and see if that helps.
Your electric company issues a company van and an ID badge to all field techs. The van is SPF, and the badge is DKIM.
But the tech might also take public transportation or their personal car. They also might leave their badge in their wallet and just get to working on the problem.
So they have identification, but they’re not always forced to use it.
DMARC is something more. It’s the rule “Con Ed employees will always have a badge to identify themselves and/or use one of our blue vans.”[3]
If someone claiming to be from the company is not both authenticatable and successfully authenticated, they cannot be trusted. And if you opt not to authenticate, the company is not responsible for their actions — even if they happen to be legit employees, which is the “repudiation” aspect.
(That metaphor kinda sucks, but it has a little charm, maybe?)
SPF + DKIM + DMARC via techspeak
OK, now for the real thing. Quickly but not dumbed down.
SPF
SPF authorizes a specific set of mailservers to use a domain in the MAIL FROM command, a.k.a. the SMTP envelope sender domain, as defined in RFC 5321. SPF does not relate to the From: header, which — despite being called a “header” — is part of the message itself.
(This is why, as I’ve written about many times, the standard Marketo setup with a shared IP address and generic envelope sender @something.mktomail.com does not require you to add or modify your SPF record, and in fact you may break the SPF record entirely by unnecessarily touching it.)
DKIM
DKIM allows a sender to digitally sign emails, with a standard way (a specific DNS record) for recipients to validate the signature. If signed, the signature must cover the From: header and entire body; it does not cover any envelope information (so it’s the converse of SPF in this way).
But DKIM does not mandate that emails be signed. It gives you a way to sign, and if you use it, you’d better sign correctly or the email is junk. If you don’t sign, the email is just like a regular email from 1982.
DMARC
DMARC goes beyond the mere existence of SPF and DKIM records to enforce the use of those records.
A company’s DMARC record treats the From: header domain as the effective domain (not the envelope sender domain, though they may happen to be the same). A typical DMARC record says “If an email claims to be From: someone@example.com, it either needs (a) to have a valid DKIM signature[4] from example.com or (b) must come from an IP address that results in an SPF PASS for example.com.[5]”
DMARC records are obeyed by all mailservers that understand the technology. Some mailservers don’t know how to look up DMARC but all large email providers do.
Putting it together
If you drop {{Lead.Email Address}} into the From: header, you become subject to the DMARC rules dictated by the lead’s company. And you’ll be unable to comply with those rules, because your emails will neither (a) pass SPF for their domain nor (b) have a valid DKIM signature for their domain.
Notes
[1] A Velocity {{my.token}} could manipulate lots of interstitial variables but end up outputting the original $lead.Email value, and that wouldn’t be detectable. Or you might be automatically copying the {{Lead.Email Address}} to another field using Change Data Value and Marketo couldn’t keep track of all that.
[2] Haven’t seen data about the total number of mailboxes that are protected by DMARC, but we know the major consumer/prosumer email providers do it, and that should be all the evidence you need!
[3] Yes, an imposter could make their own blue van, so it’s not really like an IP address. (Despite long-exaggerated fears of IP spoofing, that doesn’t happen over the modern internet.)
Maybe this is an alternative reality where a rogue blue van is instantly detected by a drone or something. But again, that’s why tech metaphors never really work!
[4] An invalid/faked DKIM signature, hopefully self-evidently, won’t cut it.
[5] An SPF UNKNOWN, PERMERROR, FAIL or any result other than PASS won’t cut it.