Deliverability Summit : the ideas that changed 
how we think about email

This April, the Batch Deliverability team attended the Deliverability Summit in Barcelona, three days of talks, panels, and conversations at La Pedrera, bringing together some of the most experienced practitioners in the email ecosystem: ESPs, MTA vendors, blocklist operators, mailbox providers, and deliverability consultants. Here are some of the sessions we attended and the ideas worth sharing.

Email is infrastructure, not just a channel

The opening keynote by EasyDMARC set the tone for the entire event: email is not a marketing tool that happens to use a protocol, it is critical infrastructure.

That framing matters because it changes how we think about everything downstream, from authentication to bounce handling to vendor choices. It was a thread that ran through most of what followed over the three days.

What actually gets senders blocked in 2026

David Finger from Seznam (Czech mailbox provider) offered a receiver's perspective on filtering, and it was a useful reality check. The signals that genuinely move the needle are not always the ones senders focus on.

Spam traps (special email addresses used to detect spammers and illegal mailing lists) remain one of the most revealing indicators of poor list hygiene, often more telling than complaint rates alone. Reputation is not a function of content alone, and attempting to engineer around filtering systems tends to backfire.

The blocklist and reputation panel, with representatives from Spamhaus, SURBL, Proofpoint, and Hornetsecurity, reinforced this. One misconception that came up repeatedly: spam traps are often treated as edge cases when they are actually a direct signal of list hygiene problems.

Monitoring: not optional, and not just complaint rates

Andrey Sas from Social Discovery Group gave one of the most practical talks of the event, a full monitoring architecture for email at scale. His core message: complaint rates are a lagging indicator. By the time they rise, the problem has already been happening for a while.

A complete monitoring stack covers:

• Product-level sending anomalies (volume, CTR, confirmation rates among new users)

• MTA delivery logs

• Google Postmaster Tools data (spam rate, SPF/DKIM/DMARC)

• FBL (Feedback Loops)

• Blocklist tracking across a critical selection, Proofpoint being a well-known example of a list that can't be monitored

Metrics should be segmented across multiple dimensions: by mailbox provider, by IP, by product line.

This is exactly how we approach deliverability monitoring at Batch. The goal: surface problems before recipients experience them. Not after.

Bounces: temporary does not mean harmless

Syed Alam from Postmastery challenged a common shortcut: treating 4xx deferrals as non-events because they are classified as "temporary." His argument was precise, deferrals carry diagnostic information.

Each deferral indicates where the root cause lies:

• At the sender level (IP reputation, volume)

• At the domain level (authentication, DMARC alignment)

• At the recipient level (full mailbox, unknown user)

• At the policy level (content filtering, rate limits)

Retry strategy matters. Smarter retry logic, informed by deferral classification, leads to fewer retries and better delivery speed. Not worse.

His framing: soft becomes hard when time plus retries equals a decision. Treating every 4xx the same way is not a neutral choice. It is a missed diagnostic opportunity.

The publisher's blueprint: compliance is not deliverability

Florin Armasu from Data Innovation made a distinction that often gets lost: compliance and deliverability are related but different problems.

Compliance means following the rules. Deliverability means generating revenue while following the rules. Optimizing purely for compliance, zero complaints, zero risk, leads to zero revenue. The two levers need to be managed separately.

Managing deliverability in challenging industries

Josephine Skinner from Omnivery tackled deliverability for sectors with elevated risk profiles. Adult content, gambling, cryptocurrency, pharmaceuticals, debt collection. Two quotes from receiver-side contacts in her talk are worth keeping: "You can send whatever you want, but be prepared to do it well" (Yahoo) and "As long as it is wanted, you can send anything" (Google). The operative words in both: intent and hygiene.

Crypto, supplements, these industries are not inherently undeliverable. They operate in ecosystems rife with abuse. The bar is simply higher.

A few rules she laid out:

• Confirmed opt-in (double opt-in) is not optional

• Segmentation and sending cadence need to be tighter

• Content should lean toward education rather than promotion

• Being adjacent to bad actors in the same vertical creates reputational association risk, regardless of individual sender behavior

Her practical conclusion: pre-vetting senders and being willing to terminate relationships with those who break the rules, even large clients, is part of the job.

DKIM2: a new era for email authentication

Professor Richard Clayton from the University of Cambridge walked through DKIM2, the proposed successor to the email authentication standard that has been in place for over 20 years. DKIM has done its job, but its weaknesses are well known:

• Replay attacks: a valid signed email is reused to exploit the original sender's reputation

• Signature breakage, caused by forwarding and link rewriting

• Backscatter from bounce messages sent for emails the alleged sender never originated

DKIM2 is designed to address all three.

The changes are significant at the infrastructure level, but the impact on senders will be minimal. Most of the heavy lifting falls on ESPs and mailbox providers. ESPs will need to support additional signing layers and handle inbound responses, including delayed bounces, differently. Mailbox providers, in turn, gain something valuable: visibility into the full transformation history of a message, not just its final state, which enables more precise spam and abuse signals.

DKIM2 is still under active development within the IETF working group. Professor Clayton confirmed that the code is already written, and the first mailbox providers are expected to begin testing it toward the end of 2026. DMARC is expected to remain essential given its reporting role. For those who want to follow the specification as it evolves, the draft is available on the IETF datatracker.

What we're taking back

The summit confirmed a few directions already central to how we approach deliverability at Batch, and sharpened a few others.

Monitoring needs to go beyond complaint rates. The full stack, MTA logs, Postmaster Tools, FBL data, blocklist tracking segmented by IP and mailbox provider, product-level anomaly detection, enables earlier intervention. We continue to build toward this for our clients.

The compliance versus deliverability distinction is worth making explicit in client conversations. Both matter, but they are not the same lever, and conflating them tends to produce overly conservative sending strategies that hurt performance without improving reputation.

DKIM2 is coming, and the time to start paying attention is now. For senders, the changes will be minimal. For ESPs, the adjustments to signing layers and bounce handling will require preparation. We are tracking the IETF working group's progress and will share updates as the specification matures.

The infrastructure question is changing. Open-source tools have matured, managed services are evolving, and senders are asking more sophisticated questions about ownership and control. That conversation will only get louder over the next few years.

The Deliverability Summit is one of the few events where the people who run the filtering systems sit in the same room as the people trying to reach inboxes. That proximity produces conversations that do not happen anywhere else. We will be back!