More on DKIM2: VERP, async bounces, signatures and hops

As you might have seen me mention on Linkedin this week, I'm still working to fully wrap my head around DKIM2, specifically thinking about a couple of different things: the impact on DMARC and the impact on ESP platforms. Let me tell you what I know and what I don't know.

DKIM2: The Basics

As I covered in my previous Valimail "Ask Al" video, and this Valimail blog post, the goals of DKIM2, generally speaking, are to address DKIM replay, prevent backscatter, and to find a way to deal with message changes that break authentication (like secure email gateways/SEGs rewriting links to inspect and track links clicked on by their users).

All good stuff. I very much want to see backscatter die once and for all, and while DKIM2 probably won't really change life too much for email senders (i.e. the customers of email service providers and marketing automation platforms), it will have some potential for impact when it comes to those email service provider (email sending) and mailbox provider platforms.

Delayed Bounces (and VERP)

In my most recent Valimail "Ask Al" video, I touch on delayed bounces in more detail. The million dollar question is this: Do email service provider platforms realize, and are they ready for, a significant increase in delayed (asynchronous) bounces being returned in a future where DKIM2 leads the email authentication rodeo?

Mailbox providers are saying they need more time to be able to inspect inbound email messages. Partly because of the increasing complexity of threats, but also because bulk email senders tend to all send at the same time (like, for example, at the top of the hour and bottom of the hour exactly), so that can lead in spiky needs for filtering power at peak times, systems overwhelmed for part of the time, but otherwise sitting mostly idle. Allowing mailbox providers to safely reject mail after a delay gives them the ability to smooth out these peaks and distribute the load of inbound message filtering more evenly throughout the hour.

This does mean that people who are used to seeing more than 90% of their SMTP rejections come back instantly (as for years, delayed bounces have been somewhat rare) will have to get ready for a new future where a greater percentage of SMTP rejections come back after a delay.

I also suspect that "edge case" senders – those nearing poor practices, just teetering on the edge of blocking – are more likely to see trouble. A mailbox provider given more time to examine inbound messages and properly calculate a sending reputation is likely going to improve their fingerprinting of some kinds of bad senders.

This is yet another example of why it's so important to stay well within best practices and not make a game of "how close can you get to the edge." Because the edge moves; exceptions to best practices shrink over time.

Impact on Send Platforms

Here's where gaps exist in my understanding of DKIM2's future impact. Today, these bits of outbound SMTP infrastructure generarting most bulk mail sign messages with multiple DKIM signatures, authenticating mail as the brand (customer), and also authenticating as the platform's domain, allowing for things like feedback loop participation and postmaster tools insight to help with policing clients and monitoring overall platform deliverability.

This is going to work differently under DKIM2. No such thing as multiple signatures, directly, I think. But outbound bulk email platforms will likely still be able to include both the brand and platform as authenticated domains, responsible parties for a given email message. I have only a vague idea of how that bit of things will work; stay tuned, and as I learn more, I'll share more.

Impact on DMARC

And what of DMARC? Right now, very little of the discussion around DKIM2 is focusing on how it will intersect with DMARC. That makes sense, as there's lots of technical bits in the execution bit to work out before DKIM2 is live enough to help inform our thoughts about where and how it'll work with DMARC.

Today, DMARC is very valuable in that it provides a domain owner email disposition feedback regarding authenticated and unauthenticated mail, at the organization (domain) level–regardless of source. This is something that no other email authentication protocol has. DKIM2 contains a feedback component, a signed bounce destination address, but DMARC feedback is at a different level than bounces; it provides info about YOUR sends regardless of send platform, and it provides info back about spoofing attempts that you didn't initiate. (If you didn't initiate them, you don't have an ESP's bounce logs to look at to see them.)

And DMARC reporting is centralized. If your domain sends from a dozen different sources, that means bounces are found in a dozen different platforms to review. But aggregate information about all of those rejections ends up in your DMARC reporting. One place to look, not a dozen.

DMARC also helps catch when infrastructure breaks in an unexpected way, something very clearly demonstrated when Google started adding SMTP rejection info to DMARC feedback.

And More?

DKIM2 is both still a work in progress, and complex enough that I'm sure some of my thoughts here border on oversimplification, or I could even be getting a detail or two incorrect. But I think it's important to keep folks updated on how things are evolving, without waiting for perfect understanding to be the enemy of a good attempt to share.

As I said above, stay tuned; as I learn more, I'll share more.