In April 2026 the people who run the world’s inboxes and blocklists spent three days in Barcelona. We took notes. Here are the 25 checks that came out of it, in plain language, free to use, with the person who said each one named.
In April 2026 the people who run the world’s inboxes, blocklists and mail servers spent three days at La Pedrera in Barcelona for the Deliverability Summit. Steve Atkins of Word to the Wise, David Finger of Seznam, LB Blair and Varun Jain of SendPost, Syed Alam of Postmastery, Chris Adams of Bird, Raymond Dijkxhoorn of SURBL. We spoke on day two and took notes on everything else.
What follows is the list we brought home: 25 things an email program can check, each one attributed to the person who said it, each one written so that a CRM manager or a marketing lead can read it without a systems engineer at their side. It is free to use, copy and forward. If one of them saves you a Friday, tell us which.
Pre-send content checks
Keep every header line short
Steve Atkins showed that a header line over 998 characters is not valid SMTP, and Microsoft cuts headers at around 700 characters. When a header gets cut without a space to break on, DKIM breaks without any warning. The List-Unsubscribe header is the usual culprit, because some platforms pack a subscriber’s whole record into that one URL.
How to check: Look at your List-Unsubscribe and other long headers. Anything past 500 characters is worth shortening; anything past 900 is worth fixing today.
Steve Atkins, Word to the Wise
Shorten the unsubscribe link itself
Atkins called out a specific pattern: some ESPs serialise every field they know about a subscriber into the unsubscribe URL, producing links several thousand characters long. Those links break DKIM the same way a long header does.
How to check: Measure the full List-Unsubscribe header. If the URL runs past 500 characters, swap it for a short token that your server resolves to the subscriber record, instead of carrying the data in the URL.
Steve Atkins, Word to the Wise
Encode the body, do not minify it into one line
HTML minifiers strip line breaks, which leaves a body that is one line thousands of characters long. There is no folding rule for body content the way there is for headers. Quoted-printable or base64 encoding keeps every line under 80 characters on the wire, regardless of what the minifier did.
How to check: Confirm your sending pipeline encodes the HTML body in quoted-printable or base64 before it goes out, and flag any raw line over 998 characters.
Steve Atkins, Word to the Wise
Never send raw accents or emoji on the wire
SMTP support for raw UTF-8 is not universal. If one relay along the way does not support it, it re-encodes the body itself, and that breaks the DKIM body hash. Encoding accents, emoji, Cyrillic or Kanji as quoted-printable or base64 avoids the problem entirely.
How to check: Scan headers and body for raw non-ASCII bytes before sending. If you find any, force quoted-printable or base64 rather than relying on the receiving server to negotiate UTF-8 correctly.
Steve Atkins, Word to the Wise
Make every link https, footer included
LB Blair and Varun Jain looked at nearly 4 billion messages at SendPost: emails where every single link was https delivered 98.1% of the time. One stray http link changed nothing measurable, but two or more caused delivery to drop hard. The usual offenders are old footer links, tracking domains and a partner logo nobody has touched in years.
How to check: Open your last campaign, search the HTML for http:// and fix what you find. It takes about ten minutes and it is the cheapest win on this list.
LB Blair and Varun Jain, SendPost
More links do not hurt, irrelevant ones do
In the same SendPost dataset, the group of emails with the highest open rates carried seven or more links, newsletters and ecommerce alike. Link count was never the problem researchers assumed it was. What actually hurts a message is links a reader has no reason to click, not the number of them.
How to check: Before cutting links to “simplify” an email, ask whether each one earns its place, not how many there are.
LB Blair and Varun Jain, SendPost
Write alt text a person would want to read
The same SendPost dataset showed emails with no alt text on any image performed worst of all, and that receivers read the words in alt text as a signal about the message. A missing tag on one or two images barely registered, but generic text like “banner” or “image1” counted as nothing at all.
How to check: Treat alt text like the caption under a newspaper photo: what is shown, and why it is there. Your blind readers and the inbox agree on this one.
LB Blair and Varun Jain, SendPost
Keep the email between 40 and 80 KB
SendPost’s sweet spot was 41 to 60 KB of HTML. Very small, text-only emails also did well. Past 100 KB, the returns fade fast. Most oversized emails are not long: they carry five hero images where one would do, and a template nobody has opened in a code editor this year.
How to check: Measure the rendered HTML before you send. If it is past 100 KB, look for images to optimise and old code to remove before you look for text to cut.
LB Blair and Varun Jain, SendPost
Make leaving as easy as one click
One-click unsubscribe, the List-Unsubscribe-Post header from RFC 8058, is now offered by 82.8% of bulk senders and has been required by Gmail and Yahoo since February 2024. A reader who can leave in one tap does not reach for the spam button, and the spam button is the signal that costs the most.
How to check: Ask your platform to show you the actual header on a real sent message, not just the settings page that claims it is on.
David Finger, Seznam
Authentication checks
Keep SPF under ten DNS lookups
David Finger warned that this is where senders with several tools “burn out” fastest. SPF allows a hard limit of ten DNS lookups; go over it and the record returns a permanent error, which mail servers treat as a failure.
How to check: Resolve your SPF record’s includes, redirects and other lookups recursively and count them. Eight or more is worth flattening before it becomes ten.
David Finger, Seznam
Sign with RSA-2048, not Ed25519
Steve Atkins confirmed that Gmail, Yahoo and Microsoft do not yet support Ed25519 DKIM signatures. A message signed that way comes back “neutral: no key” at Gmail, which is functionally the same as no signature at all. RSA-2048 remains the standard until DKIM2 is finished.
How to check: Check your DKIM signing configuration for the algorithm and key length, and confirm the public key in DNS matches what you are actually signing with.
Steve Atkins, Word to the Wise
Move DMARC toward p=reject
David Finger put it plainly: p=none “provides no real protection” and will earn a slower, lower reputation over time. p=reject is what he called the gold standard, and mailbox providers are expected to start weighing p=none domains down within one to two years.
How to check: Query the DMARC record for every sending domain. Anything still at p=none or p=quarantine needs a migration plan, with rua reports actually monitored along the way.
David Finger, Seznam
Get both SPF and DKIM passing, not just one
Microsoft is moving toward requiring both SPF and DKIM to pass for DMARC alignment, rather than letting one compensate for the other the way some senders assume.
How to check: After a send, check the authentication-results header and confirm SPF and DKIM both show pass, even when DMARC overall looks fine.
Steve Atkins, Word to the Wise
Confirm your sending IP resolves both ways
Forward-confirmed reverse DNS, FCrDNS, means the PTR record for a sending IP matches its HELO hostname, and that hostname resolves forward back to the same IP. Both Data Innovation’s own presentation and Atkins independently named this a hard gate for any new domain.
How to check: For every sending IP: look up the PTR record, resolve that hostname forward, and confirm it lands back on the original IP before the domain sends a single message.
Florin Armasu, Data Innovation and Steve Atkins, Word to the Wise
Rotate DKIM selectors on a schedule, with overlap
A monthly selector, published a week before it goes live and kept valid for thirty days after rotation, means a key never goes stale without a safety window behind it.
How to check: Confirm the current DKIM selector matches the expected month, that next month’s is already published in DNS, and that last month’s is still valid.
Florin Armasu, Data Innovation
DNS checks
Make sure every nameserver agrees
Atkins showed a real case where two DNS providers held slightly different records for the same domain, causing DKIM to fail at random depending on which nameserver answered.
How to check: Query every authoritative nameserver for a domain and compare SPF, DKIM, DMARC and MX records across all of them, weekly.
Steve Atkins, Word to the Wise
Check DNSSEC is not quietly broken
A domain that published DNSSEC and then broke it still resolves fine for most tools, because standard resolvers do not validate it. DNSSEC-validating resolvers, though, return errors, and most online testing tools never check for this.
How to check: If a domain has DNSSEC published at all, run it through a DNSSEC-specific analyser rather than a general DNS checker.
Steve Atkins, Word to the Wise
Watch for recipient domains that change hands
Raymond Dijkxhoorn of SURBL pointed out that domains which change ownership can turn into recycled spam traps overnight. An address that was safe a year ago is not automatically safe today.
How to check: Store the MX records you see for recipient domains at collection time, and re-check monthly. Flag any address whose domain’s MX has changed since for re-verification.
Raymond Dijkxhoorn, SURBL
List hygiene checks
Validate syntax before an address ever queues
Every address should pass an RFC 5321 syntax check before it enters any sending queue. This is the cheapest filter available and it belongs at the very front of the pipeline.
How to check: Reject malformed addresses at the point of collection. Suppress them silently rather than bouncing, and log them to the suppression store.
Florin Armasu, Data Innovation
Treat role-based addresses with care
Addresses like admin@, abuse@, postmaster@, info@ and sales@ carry a higher risk of becoming spam traps or generating feedback-loop complaints.
How to check: Flag role-based addresses at ingest. Keep them out of bulk marketing sends and allow them only for transactional mail, with a lighter send rate.
Florin Armasu, Data Innovation
Screen out disposable domains
Addresses from services like guerrillamail or tempmail never convert and often turn into traps later. There is no upside to keeping them.
How to check: Keep an updated list of disposable domains and discard matching addresses at ingest, suppressing silently rather than bouncing.
Florin Armasu, Data Innovation
Send less to the people who stopped reading, on a schedule
When Dela Quist asked the blocklist panel exactly when a silent address becomes a liability, nobody had a firm number, and SURBL confirmed that traps now open and click deliberately to avoid being aged out of a list. The practical answer is a ladder rather than a cliff: reduce frequency after 90 quiet days, move to monthly after 180, quarterly after 270, and pause entirely after a year of zero engagement, re-verifying by MX before the final suppression.
How to check: Build the ladder into your sending calendar rather than one big annual purge. It protects your margin as much as your placement: fewer sends to people who left the room, more attention for the ones still in it.
Blocklist Panel, Deliverability Summit 2026
Bounce processing checks
Stop treating every 5xx as the same bounce
Syed Alam of Postmastery argued for three categories instead of one: a hard bounce means the recipient is genuinely invalid and should be suppressed immediately; a soft bounce is a temporary problem worth an exponential retry before suppression; and what he calls a just-a-bounce, such as a policy rejection or a too-many-connections message, is a sender or policy issue that should never suppress the recipient at all.
How to check: Audit your bounce classification rules and confirm that policy-related 5xx codes are logged separately, not treated as proof the recipient address is bad.
Syed Alam, Postmastery
Watch the raw number of complaints, not only the rate
Chris Adams of Bird described an affiliate ring that kept its complaint rate under 0.03% while generating 78,000 complaints a day. Rate alone completely missed the scale of the problem.
How to check: Track absolute daily complaint counts per domain alongside the rate, and set a review trigger such as 100 or more complaints a day regardless of how small the rate looks.
Chris Adams, Bird
Infrastructure checks
Check how concentrated your traffic is on one provider
The same affiliate ring Adams described sent 95 to 100% of its traffic to Yahoo alone. Legitimate senders naturally spread across providers because their real audience does.
How to check: Calculate the distribution of recipient providers per sending domain. If a single provider takes more than 80% of the volume, treat it as a reason to look closer at where the list came from.
Chris Adams, Bird
Get ready for BIMI while your DMARC is strong
David Finger confirmed BIMI helps reputation once the groundwork is in place: DMARC at p=reject, a square SVG logo under 32 KB, and a Verified Mark Certificate that is still valid.
How to check: For any domain already at p=reject, check whether a BIMI record exists yet. If it does not, that is an open opportunity rather than a problem to fix.
David Finger, Seznam
Where there is will, there is a solution. None of the 25 checks above need a new tool: most of them need twenty minutes and a person who knows where to look.
If you want a second pair of eyes on your own program, ours are free for twenty minutes. From 49 EUR per domain per month and from 0.135 EUR per 1,000 sends if you want us on the crew.