DKIM
On Tuesday I wrote about using DNS wildcards to implement customer-specific subdomains for email authentication. As I said then, that approach isn’t perfect. You’d much prefer to have per-customer domain authentication, where each customer has their own DKIM d= and ideally their own SPF records, rather than having all customers sharing those records and relying on loose DMARC alignment to have them to work with a per-customer subdomain in the 5322 From: header. But doing that with DNS wildcards would have some odd side effects, such as TXT records appearing where they weren’t expected, in ways that could trigger bugs in rarely tested code paths at mailbox providers and potentially even open up security problems. I mentioned using a “stunt” DNS server would be one option to do that, and then quite a few people asked me what I meant by that. A stunt DNS server is one that doesn’t
If you’re an ESP with small customers you may have looked at the recent Google / Yahoo requirements around DMARC-style alignment for authentication and panicked a bit. Don’t impersonate Gmail From: headers. Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery.…For direct mail, the domain in the sender’s From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment. So everyone who’s using their gmail address to send bulk mail is going to have to stop doing that within the next few months if they still want their mail to be delivered. For any ESP customer that already has, or can be convinced to buy, a domain for their web presence maybe they can be persuaded to switch to using that – though even if they can, onboarding 100,000 technically naive users
If you dig into the newly published upcoming sender requirements from Google, you’ll unearth three points that relate to DMARC. These are important enough that I wanted to highlight them specifically.First, note that Gmail is moving to a “p=quarantine” policy for gmail.com. That means it is no longer safe to send mail as (anything)@gmail.com except when doing so via Gmail’s infrastructure. This new policy update is Google telling the world to spam filter mail that says it’s from a gmail.com email address, but doesn’t pass email authentication tests. This is a big deal. Gmail, Yahoo, and many other mailbox providers are going to filter unauthenticated messages much more harshly as a result.My memory’s a little fuzzy, but I remember a freemium SMB-focused ESP that had a free “newsletter service” that I think they’ve long since shut down. The platform let you send as yourself, so they served up an awful
Gmail has long pushed for adoption of email authentication best practices from email senders, effectively making it tough to get to the inbox without proper email authentication in place. They also, for years now, have been very cautious about what mail they accept over IPv6, declining to accept mail over IPv6 that fails authentication checks. Well, now those same checks now apply to all mail sent to Gmail — over IPv4 or IPv6. Meaning, if you want to send mail to Gmail, you need to authenticate that mail with Domain Keys Identified Mail (DKIM) or Sender Policy Framework (SPF).If you’re trying to send mail to Gmail subscribers, and the mail doesn’t authenticate properly, it’ll be rejected with this error message:550-5.7.26 This mail is unauthenticated, which poses a security risk to the sender and Gmail users, and has been blocked. The sender must authenticate with at least one of SPF or
If you’re seeing intermittent DKIM authentication failures at Microsoft domains (outlook.com, hotmail.com, etc.) — meaning you’re seeing “dkim=fail (body hash did not verify)” instead of “dkim=pass (signature was verified)” in your “Authentication Results” email headers — then what likely has happened is that Microsoft has modified one or more characters in your email message.See, there’s multiple ways to encode email messages for sending them via the Internet — the oldest, default way of just plain text (7-bit ASCII text) doesn’t allow for emojis, accented characters, special character sets, Kanji, anything beyond just the simple characters used to write English-language text. And to allow email to be transmitted in this simplistic character set, but allow for additional, extended characters and alternative character sets, methods of encoding were created that allowed email platforms to do things like specify complicated multi-byte characters by “encoding” them into Quoted-Printable or Base64, to allow them to
Or, how to scare your potential new customers by doing a whole bunch of things wrong all at once, leading to the big warning box of doom. Cold leads, not sending using a full name, and not authenticating properly. Trying to be friendly and sending mail as “Bob” can backfire, especially if your employer has four other people already named Bob, Gmail can’t tell which is which, and Gmail is concerned because your DKIM configuration is busted and you didn’t configure SPF properly. Good job, Bob.This brings me back to the common question, are SPF and/or DKIM required for inbox placement? Well, the lack of them in this case sure didn’t help Bob. Don’t be like Bob. Make it easy for Gmail to identify you and authenticate your mail.
It looks like Microsoft are getting pickier about email address syntax, rejecting mail that uses illegal address formats. That might be what’s causing that “550 5.6.0 CAT.InvalidContent.Exception: DataSourceOperationException, proxyAddress: prefix not supported – ; cannot handle content of message” rejection. Why do we care? It’s good to send syntactically valid email in a warm fuzzies sort of way – it shows we know what we’re doing, and aren’t dodgy spamware – but it’s increasingly important to delivery as mailbox providers are tightening up on their syntax checks. But why are mailbox providers doing that? One reason is that authentication tech like DKIM and DMARC is built around them only being applied to email. Not to messages that kinda look like email. There are ways to bypass DKIM protections by sending invalid messages. As one example, if you send multiple copies of the From: header with different values a DKIM checker
Need help creating your DKIM key? Specifically, the private key file and public key info that you’ll publish in DNS? MessageBird (acquirer of Sparkpost (itself the acquirer of eDataSource), has got a cool little tool for you that’ll do just that. Give it the domain name and selector and it’ll generate everything you need. They support up to 2048-bit keys today, which should be good enough for the moment. (Long term, we need to go larger, but there is a good chance that there is some infrastructure out there somewhere that might choke on keys larger than 2048 bits. That’s a challenge to tackle another day.)Find it here: MessageBird DKIM Wizard.
The other day, I ran across a complaint on Linkedin. “Just saw another email go to the Promotions Folder with DKIM, SPF, and DMARC set up perfectly. Stop telling people this will fix their e-mail problems!” It’s not the first time I’ve heard this, and I can understand why the author is frustrated. But, it’s important not to miss the true point — email authentication will help to improve inbox delivery. Because it does! But there’s a nuanced explanation to go along with that. The devil truly is in the details.Email authentication is fantastic. SPF and DKIM both allow you to set yourself up as YOU in the eyes of mailbox providers — as opposed to just being one of the many clients of ESP or CRM platform X, based on a shared IP address or shared DKIM domain. This is a good thing, but it’s just the start.Setting yourself
DKIM replay attacks are one of the new big things lately, and they work like this: Take a DKIM signed email message, and re-send it to a billion other people. Maybe add another header (or change the subject, if the signature doesn’t cover the subject), or maybe change nothing. Just take that message and randomly spam a million people. The mail will pass DKIM authentication checks, as long as it is sufficiently unchanged, and thus it authenticates as if it were a legitimate email message. Even if you weren’t the original intended recipient. Even if it was sent only to one person but then recent to a million other people, just to annoy them. That’s not a good thing — it can damage a sender’s domain reputation, because people unhappy about that unwanted mail will report it as spam, and spam reporting processing mechanisms will tie it back to the