Email Deliverability in 2026: What's next?


You’re wondering what deliverability changes await us in 2026? I’m so glad you asked! Let’s talk about deliverability in 2026: What’s here now, how things work today, how it’s all evolving, and what I think things will look like over the coming year.

In 2026, Technical Compliance Matters

We’ve reached “no auth, no entry,” meaning that if you’re a bulk email sender, you’re not getting mail delivered to inboxes hosted by Yahoo, Google and Microsoft, unless you have SPF, DKIM and DMARC in place and passing. In the past, there were exceptions. And you could have gotten by with one failing (like DKIM) if you had SPF working in place (or vice versa), but no more. Loopholes are shrinking or have closed. And it’s not just Yahoo, Google and Microsoft – others have these requirements, too, and those that don’t are likely to have this requirement in the future.

The bare minimum starting point for an email sender?
  • Configure DKIM for your email sending domain. Some platforms call this “configuring your custom domain” or “authenticating your custom domain.” Klaviyo used to call it a dedicated sending domain, but now calls it a branded sending domain. This is an absolute must. You need to configure this.
  • See if your email sending platform requires that you configure SPF for your email domain. (Yes for 1:1 email like Google Workspace or Microsoft 365. Likely no, for SMB-focused ESPs like AWeber, Constant Contact and Mailchimp. YMMV can vary for others.)
  • Configure DMARC. (I work for DMARC vendor Valimail, and I’m fond of our free platform, Valimail Monitor. And here’s a whole list of vendors if you’d like to do your own research.)
  • If you’re sending newsletters or marketing emails, make sure your sending platform complies with the latest Microsoft, Apple, Gmail and Yahoo (MAGY) sender requirements. Avoid any platform that tells you it’s “too hard” to do so.

It's time to monitor DNS infrastructure

Google added SMTP rejection reporting to DMARC reports in mid-2025. My Vali-colleague Scott Ziegler and I were lucky enough to be one of the first folks to review this data en masse and we learned something surprising; that a whole bunch of email is being rejected because of email sending infrastructure being misconfigured. In particular, reverse DNS (PTR) records being misconfigured or missing. Meaning that your servers, the sending IP addresses of your mail servers (MTAs), don’t have proper DNS names that match up between forward and reverse DNS.

DNS can be technically complex and difficult to get right. But email service provider platforms, and those managing in-house sending platforms, tend to have smart people in the right place to help configure DNS properly when provisioning a new client. But something is getting lost, later on. A domain name changes, but the DNS hostname doesn’t get updated. Or a subdomain delegation gets deleted. Nobody notices the impact this has on the DNS configuration for sending IP addresses, and mail starts to bounce.

The gap here is ongoing monitoring of DNS infrastructure. Making sure all of your sending IPs have proper DNS ongoing. Whether “you” means a big brand sender, or “you” means you work in ops for an email service provider or cloud email platform: you need to monitor for broken DNS.

When you treat DNS as “set it and forget it,” never coming back around for that ongoing monitoring, you’re going to have problems. And in the 2026 world of bulk email sending – whether it be email marketing or important transactional emails, those troubles are big and bad and ugly.

A.I. is real, but beware of hype versus reality

Artificial Intelligence is everywhere right now, and a lot of people want to talk about what it means for deliverability. Some of that concern is warranted. Some of it is recycled fear. Mailbox providers have relied on machine learning driven filtering for years. A.I. is not suddenly entering deliverability. It has been part of the system for a long time.

Where A.I. is rapidly changing email is outside classic spam filtering. Good actors are using it for smarter segmentation and personalization. Bad actors are using it to scale attacks faster and make them harder to spot. That threat is real, though it sits closer to email security and domain protection than to inbox placement alone.

Then Google announced that Gmail is entering the Gemini era, complete with new A.I. inbox features. That understandably raised alarms. Will my newsletter still get seen? Will my marketing messages get summarized away and pushed out of view?

Remember this: the core principle does not change. Mailbox providers want to deliver wanted mail and block unwanted mail. TL;DR? Focus on sending messages people actually want to receive and read. If you do that, it does not matter how much A.I. is sitting between you and the inbox.

But if you'd like to talk about this in more detail, I've broken my thoughts on the new Gmail A.I. inbox into a separate post, and you can find that here.

Beware the Hucksters

There’s a lot of bad deliverability advice online, trying to tell you that there’s some magic secret to inbox placement that nobody has thought of before, and only they can help your email marketing efforts succeed. It’s rarely true. There is no magic text to add to emails to guarantee primary tab placement. Those charts that claim that ESP platform XYZ has better deliverability are trying to get you to switch platforms on a false premise. There is no true “just route your mail through my SMTP service to guarantee inbox delivery.” And anyone promising you that they’ve cracked the code to cold email is working in a realm different from this one. Their advice usually involves rotating through email sender domains, severely limited volume per domain, trying to avoid reputation metrics and other hacky tricks that aren’t compatible with B2C email marketing success.

Exceptions are Disappearing

Spam filters are more automated than ever, and with that rise of A.I. or machine learning (which, again, is not that new in this realm), it means that the opportunities to “make your case” to a human at a mailbox provider, to try to resolve a spam folder or blocking problem are disappearing. It would be nigh impossible for the batphone to be any less relevant in 2026.

Spam filters are tightening up, too. The closer you get to the edge of what’s allowed, the more likely you are to eventually end up on the wrong side of that edge. Your deliverability falls off a cliff, remediation is extra painful, and there’s nobody to call to escalate it to. But neither “these practices worked just fine in the past” nor “we’ve been emailing this way since 2017” do anything to resolve the issue.

The fact is, filters evolve. If you want to stay ahead of it, it’s time to review your practices, and audit for opt-in mechanisms that you know to be imperfect, or processes that you know to be “slightly” out of compliance, and fix them now, before the hammer drops.

Engagement Is Where Deliverability Is Won or Lost

The best way to future-proof yourself against deliverability problems, as much as you can, is by sending wanted content to people who want it. Third party data, purchased lists, “grey area” practices, they all reduce engagement, and mailbox providers get better and better at deciding inbox placement (or not) based on engagement.

Implementing DMARC won’t fix this. Adding a list-unsub-post header won’t fix this. For sure, fail a technical requirement, and you’ll be less likely to get to the inbox. But, pass all the technical checks, and you still can land in the spam folder. Those technical requirements are a subset of the rules, not the whole rulebook. Lots of perfectly technically compliant mail lands in the spam folder – because it is easily measured as having low value to recipients.

Engaging mail delivers. Unwanted mail doesn’t. You know this. Let’s work together to make sure your mail is engaging, so that you can reliably reach the inbox in 2026.

(Author note: I updated the "A.I. is real, but beware hype versus reality" section on January 10th to incorporate more info about recent Gmail updates.)
Post a Comment

Comments