Spam Resource: All Things Deliverability

Troubleshooting 4 different types of Microsoft DKIM rejections

2026-05-30T13:45:44.268-05:00

If your attempts to send email to Microsoft-hosted inboxes are bouncing back intermittently with authentication-related rejections; specifically highlighting that DKIM is failing, when you know you’ve got DKIM authentication correctly implemented: what do you do now?

The actual SMTP rejection looks something like this: “550,5.7.515,Access denied, sending domain example.com doesn't meet the required authentication level. The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender. To learn how to fix this see: https://go.microsoft.com/fwlink/p/?linkid=2319303 Spf= Pass , Dkim= Fail , DMARC= Pass”

Almost hidden in the massive SMTP response, near the end, is that “Dkim= Fail.” But you didn't misconfigure DKIM, so you're confused. And rightly so; it's a tricky issue with multiple possible root causes.

Here, in my latest Valimail “Ask Al” video, I walk you through four things I would look for when trying to troubleshoot this issue: DNS timeouts, header folding issues, double or missing headers, or something else resulting in unexpected content modifications.

View the video embedded above or click here to view it over on Youtube.

CNIL open tracking restrictions are coming and complex

2026-05-29T05:30:00.000-05:00

CNIL, France’s data protection and privacy authority, recently announced new restrictions and requirements related to open tracking (aka pixel tracking) and things are relatively complex.

The TL;DR is that permission is required before tracking opens, there’s a potential exemption for deliverability use, and email service provider and marketing automation platforms may have to modify functionality or implement new functionality to enable email senders to comply.

Start here with this great overview of what has come out so far, courtesy of Alison Gootee from Sinch Mailgun. (She also notes that Italy’s privacy authority has announced a different set of restrictions – be sure to review that, as well!)

And now what? For that, let’s head over to Jonathan Loriaux, CEO of Badsender, and his recent Linkedin post, where he summarized what he observed in a CNIL webinar meant to provide clarification around the new pixel tracking requirements and restrictions.

It’s easy to translate his feedback from French using your browser, so I won’t paste a whole, long translated version here. But to highlight his key takeaways: He says that when it comes to the new pixel tracking mandates, “the disconnect between the legal perspective and operational reality is glaring,” platforms are not ready to comply, and the webinar audience ultimately were left with more questions than answers.

I looked for a recording of the webinar online but wasn’t able to find one – it doesn’t seem to be on the CNIL video site. Feel free to drop me a line with a link, if you’ve got one.

CU Boulder shutting down alumni email service

2026-05-28T11:59:23.024-05:00

If you’ve got an active alumni email account from the University of Colorado Boulder, you might have already seen the announcement: Your alumni email account is going away as of August 31, 2026.

This affects email accounts in the domain colorado.edu — not all accounts, as this affects only alumni, not active students or faculty. Email senders, get ready for an increase in bounces from that domain, and you might want to reach out now to ask subscribers to provide an updated email address.

Why is the school shutting down this email service? Cost, security, and complexity are undoubtedly the main reasons. They cite “evolving compliance requirements,” which I interpret as “email forwarding is a huge pain in the rear nowadays.” I can’t say that I blame them for wanting to divest themselves of the cost and management headaches involved.

And it’s not just CU Boulder. Duke recently announced a similar shutdown for alumni access to duke.edu email accounts, and SUNY Stony Brook phased out their alumni email service in 2025.

Learn more about DMARCbis

2026-05-18T10:06:35.426-05:00

DMARCbis: What is it and what do you need to know? It’s the updated version of the email authentication-related DMARC internet specification, and it modifies how DMARC works in a few small, but important, ways. If you’re curious to learn more, check out my latest Valimail "Ask Al" video, where I explain the most important changes that you need to be aware of.

Find the video embedded above or click here to head on over to Youtube to view it.

ICYMI: BIMI success stories and data

2026-05-10T11:34:12.674-05:00

Curious about BIMI adoption rates? Looking for BIMI success stories? The fact is, BIMI helps boost email engagement. And if you’re looking for the data to make the business case for BIMI, this recent webinar has what you need to help you support the argument for implementing a BIMI logo.

I presented along with Dean Coclin from DigiCert and Mica Taboada from Valimail where we talked it all through, how BIMI can help you bridge the gap between IT and marketing, how compliance with bulk sender requirements isn’t enough to shine in the inbox, and more.

Click on through to watch our recorded webinar, no registration required.

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

2026-05-09T12:14:29.446-05:00

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.

GMX/WEB.DE/mail.com moving to inbound DMARC enforcement

2026-05-06T07:00:00.000-05:00

Staff from mailbox provider GMX/WEB.DE/mail.com (1&1 Mail & Media GmbH) have just announced on the Mailop list that they'll begin enforcement of DMARC checks in a phased rollout over the coming weeks.

What does this mean? It means that if you publish a DMARC policy of p=reject for your email domain, they will now reject email from that domain, during the SMTP transaction, if that mail does not pass email authentication checks.

That's good news for email senders who authenticate every single email message sent, but less good news for folks who don't have SPF and DKIM configured properly for their outbound email.

Spammers and scammers looking to take advantage of their 42 million active users at these mailbox providers will also have a harder time of things; bad actors looking to send phishing email using a particular domain name will find that those bad emails will be rejected if they use the from address of a domain name that has DMARC properly implemented at p=reject.

Messages that fail those email authentication checks will be rejected with an error stating "554 Transaction failed Reject due to domain's DMARC policy." Learn more about that here.

Zeta: Q1 2026 Email Marketing Benchmarks

2026-05-05T15:04:46.710-05:00

Zeta Global just posted their latest email and SMS benchmark report. Curious about open, click and unsub percentages across a whole bunch of industry sectors? Zeta's got that. Retail, Financial Services, Travel and Hospitality, Media and more. It's good stuff, especially if you're in any covered industry segment and wondering if your campaign results measure up.

Read more: Marketing Benchmark Report: Email & SMS | Q1 2026

Microsoft DKIM Failures? Check for double headers

2026-04-25T14:51:52.273-05:00

Another day, another issue with DKIM signatures. As has happened before, and as will likely happen again, everything looks great for an email message at mailbox provider A, but gets rejected or otherwise runs into trouble at mailbox provider B.

If you’ve been in email deliverability for a while, then I know that, at least once, you’ve had messages pass DKIM authentication checks at Gmail, but the DKIM signature fails when checked at Microsoft.

The reason why isn’t always the same. In the past I had typically chalked it up to message encoding issues or header rewriting.

But here’s a new scenario, one I haven’t seen before. Double headers, meaning an RFC violation. I know that Gmail now rejects messages with certain doubled headers, but not in this case. Gmail lets the message on through – they’re perhaps cleaning up headers before performing authentication or RFC checks – but Microsoft isn’t.

Bram Van Daele, the CEO of "Agentic Email Intelligence Platform" Engagor, recently shared the story around these unexpected, mailbox provider-specific DKIM failures and how he was able to troubleshoot it all. It is well worth a read.

To me, this highlights that while we're approaching a bit of a convergence when it comes to email sender requirements, different mailbox providers do not always end up handling the same failure case the same way.

And it also reminds us that we've moved past the era where a "good enough" configuration works everywhere. Good enough, and "it worked fine that way yesterday" are, well, no longer good enough.

So, if your emails are bouncing at Microsoft but landing in the inbox at Gmail, here's yet another technical slip up that could be the source of your woe.

Check out Bram's full breakdown of the investigation, and how he gets into the raw headers and the specific "why" behind Microsoft's strictness: How Engagor Found the DKIM Bug That Microsoft Couldn't Explain

DELIVTERMS: MTA-STS

2026-04-24T07:00:00.013-05:00

It's time for another installment of our DELIVTERMS series here on Spam Resource, where we help you digest and understand the alphabet soup of email technology. Today, we're looking at MTA-STS (and TLS Reporting).

MTA-STS stands for: Mail Transfer Agent-Strict Transport Security.

The concept behind MTA-STS is actually pretty straightforward. It's essentially a way for an email receiver to tell the rest of the internet: "I only speak encrypted. If you can't guarantee a secure connection, don't even bother trying to deliver the mail."

The Problem: SMTP Encryption Isn't Mandatory

To understand why we need MTA-STS, we have to look at how email encryption usually works. For a very long time,, we've relied on something called STARTTLS. When one mail server (aka MTA) connects to another, it basically asks, "Hey, do you support encryption?" If the receiving server says yes, they wrap the conversation in a secure TLS (Transport Layer Security) tunnel.

The problem? STARTTLS is opportunistic, meaning that encryption is optional, and won't be used, unless both parties in an email transaction are okay with it.

If a hacker is sitting in the middle of that connection (a man-in-the-middle attack), they can intercept the request and tell the sender that they don't support encryption, or simply strip the STARTTLS command out entirely. This is called a downgrade attack. The sending server, thinking it has no other choice, sends the email in plain text – no more encryption.

Once upon a time, optional encryption might have been good enough. Especially for us in email marketing land. Why do we care if people are able to sniff (observe) bulk email messages in transit? Is somebody going to steal that Kohl's coupon code? But, truth be told, a better secured internet is very much a good thing, and so it behooves everyone, email marketers included, to understand, and support, encryption when it comes to email.

The Solution: MTA-STS (RFC 8461)

Defined in RFC 8461, MTA-STS allows a domain owner to define and publish an SMTP encryption policy. This policy tells sending servers two very important things:

Encryption is mandatory: You must use TLS to deliver mail to me.
Verify my identity: You must check that my security certificate is valid and issued by a trusted authority.

Like with DMARC, a domain owner sets a choice of "policy" – in this case, none, testing and enforce.

To find a receiving site's policy, the sender looks up a DNS record, which points them to a secure website (HTTPS) hosted by the receiver. Because that website is protected by its own separate encryption, it's much harder for a hacker to lie to the sending server about the policy. Once a sender sees this policy, they cache it. The next time they send you mail, they already know the rules, and they won't fall for a downgrade attack.

MTA-STS is supported by Microsoft, Google, and many other mailbox providers.

The Reporting: TLS-RPT (RFC 8460)

Think of TLS Reporting (TLS-RPT) as a sidekick to MTA-STS.

While MTA-STS sets the rules, TLS-RPT (defined in RFC 8460) provides the reporting. Without that, if a sender tries to deliver mail to you but fails because the TLS connection wasn't secure enough, troubleshooting gets an awful lot harder. TLS-RPT allows the sender to send a daily report to the domain owner saying, "Hey, we successfully sent 5,000 encrypted emails, but 10 failed because (for example) your certificate expired." It is the "success and failure" ledger that helps administrators ensure their secure mail flow is actually flowing.

Why It Matters

In the old days, we were just happy if an email arrived at all. But now? Between business email compromise (BEC) and sophisticated data theft, sending email in plain text is a massive liability.

MTA-STS is essentially the "lock the front door" policy for your mail server. It moves us away from the "wild west" era of opportunistic encryption and toward a future where secure communication is the unshakeable default.

Want to learn more about deliverability terminology and other pesky acronyms related to email technology? Be sure to visit the DELIVTERMS section here on Spam Resource.

Webinar Alert: When Email Deliverability Isn't Enough: Turning Trust Into Brand Impact

2026-04-23T08:00:00.000-05:00

If you want to learn more about the value of and potential benefit from BIMI (Brand Indicators for Message Identification), the inbox logo standard that helps you build email trust and boost engagement with your subscribers, then this is the webinar for you!

Join Al Iverson (Valimail), Dean Coclin (DigiCert), and Mica Taboada (Valimail) as we walk through everything you need to know about BIMI, with real world data and successful use cases. We'll also share how Valimail Amplify helps you streamline your path to BIMI success, where Mark Certificates (VMC/CMC) from DigiCert fit into all of this, and more!

Join us, won't you? The fun happens on Tuesday, April 28th at 12:00 noon central time, and is 100% free.

Mickey Chandler: DKIM Failing at One Domain Is Not a Key Issue

2026-04-22T07:00:00.005-05:00

My friend Mickey Chandler recently posted a great new blog post explaining what an email sender can do with DMARC aggregate reporting. Specifically, what the reporting can tell you with regard to troubleshooting mailbox provider-specific email authentication failures. What you should do, and not do. Good advice, and you should click on through to check it out.

(BTW, Mickey Chandler's a smart guy. You should hire him.)

What is DKIM2? What do you need to know?

2026-04-21T07:30:00.021-05:00

There have been a few different blog posts, Linkedin posts, and email newsletters talking about DKIM2 lately. And oof, most of them seem to get one or more of the details wrong. People mean well, so let's forgive them -- this is a complex thing, and it's easy to misunderstand what's going on. But I think we need a bit of better info out there.

So, here I am, opening my own big mouth, explaining what DKIM2 is. The difference is, I'm actually one of the folks participating in the IETF working group process. I'm a little bit out on the edges in that I'm not necessarily writing code to define or unwind message-instance-tracked message modifications, but I'm observing what's going on, and doing so through the eyes of somebody with a strong email sender background.

In this short (5 minute) video (embedded above or find it on Youtube), for the latest episode of Valimail's "Your Email Authentication and Deliverability Questions Answered" video series, I focus on what senders need to know and care about when it comes to DKIM2. Keys aren't changing (at least not so far), and email senders might actually not need to make any significant changes at all. Let me walk you through what I know so far.

Super smart nerd friends may want to complain that I'm significantly oversimplifying things here and there in my description of intent and current state. If so, they're probably right! There's a lot of complex stuff here going on, and it is tough to condense it down to a short explanation. Forgive me in advance if I seem to gloss over something important.

And keep in mind that the specification is not yet finalized. Things are subject to change.

So keep that all in mind as you watch or listen to my explanation, and my email address is in the video, if you've got any feedback or additional questions that you'd like to bring to my inbox.

The Case for Reactivation (and Sunsetting)

2026-04-19T11:59:00.004-05:00

We often talk about the importance of "keeping a clean house" when it comes to deliverability. But list hygiene isn't just about bouncing bad addresses; it’s about managing the entire subscriber lifecycle to ensure mailbox providers see you as a sender people actually want to hear from.

Jessica Fern Hunt, a very smart deliverability consultant over at Twilio, recently shared a must-read post on LinkedIn regarding the "Case for Reactivation Campaigns."

Jessica highlights a truth that many marketers still struggle with: engagement is a deliverability signal. If you are carrying a large percentage of disengaged subscribers who haven't opened an email in six months, you aren't just paying to store dead weight. You are actively hurting your chances of reaching the inbox for your active subscribers. When mailbox providers see low engagement rates, they start to view your mail as "unwanted," and that’s a fast track to the spam folder.

Reactivation (or "winback," or "re-engagement") campaigns remain, in this modern era of increasing complexity around deliverability, a vital component of subscriber lifecycle management. If you want to maximize your inbox placement, you have to be willing to let go of the folks who have moved on.

Check out Jessica’s full post here for more insights on building a "genuine digital relationship" with your audience.

Weird DKIM failures? Check your header lengths

2026-04-09T13:33:00.003-05:00

If you’re running into issues with DKIM signatures failing when sending to Microsoft domains, but working fine elsewhere, one thing to check is that your various email headers aren’t too long or wrapped improperly. Postmark’s blog post from January touches on this very issue; ActiveCampaign’s Postmark platform previously generated list-unsubscribe headers that were quite long; so long as to cause a specific issue with DKIM email authentication at Microsoft.

Did the sending email platform violate the RFC by generating too long of headers? I’m not entirely sure, and that’s not really the point. Sometimes things can fall within the RFC requirements or guidelines just fine but still do not match the reality of how a mailbox provider has implemented things. The goal in sharing this info? Not to accuse either Postmark or Microsoft of doing something wrong, but to offer up a potential solution, some actionable advice, if you run into a similar issue.

Long story short, if you generate really long headers, like, in this case, the list-unsubscribe header, or possibly even others, and you’re seeing DKIM signatures failing to validate at Microsoft, shortening those headers is something you should consider testing. Postmark did, and it solved their problem.

And they were kind enough to share this with the world (here) – kudos to them!

Interview with Sam Masiello

2026-04-07T12:41:00.000-05:00

It was a pleasure to sit down for a special edition of the Valimail “Ask Al” video series for a Q&A with an old friend and industry veteran, Sam Masiello. Sam and I go way back to the early days of anti-spam and email security, but his career has since evolved into a security leadership role.

In our conversation, we trace Sam’s journey from hosting his own messaging network at age 13 to his involvement in the affinity email space. For those of us in the DMARC world, Sam’s history is particularly interesting: he was the first general manager of Return Path’s DMARC product, helping to bring that technology to market during its infancy. (I love talking to people about the history of the various technologies that are so important to protecting email today.)

He shares some great insights on the "fake it till you make it" moments of his career and the often-difficult transition from a purely technical expert to a C-level executive who must "speak the language of the business." We also took a bit of a detour into Sam’s life outside of the office, talking about basketball and volleyball officiating, and the positive impact it has had on his life and even his business skills.

Check out the full interview above (or here on Youtube) to hear more about Sam’s "snowball" philosophy on staying ahead of threats and his thoughts on using A.I. to manage the firehose of security data and keeping informed on the latest threats.

(And don’t forget to check out the whole Ask Al video series from Valimail, aka “Your Email Authentication and Deliverability Questions Answered,” over on Youtube!)

Relief for marketers? Washington email law amended

2026-04-05T08:00:00.021-05:00

If you've been following the legal landscape for email marketing, you're likely aware of the "litigation gold rush" happening in Washington State. Thanks to a strict interpretation of the Washington Commercial Electronic Mail Act (CEMA), even the smallest technical inaccuracies in a subject line could trigger a wave of lawsuits. (Mickey Chandler blogged about this back in February over on his Spamtacular blog. Smart guy. You should hire him. But I digress.)

Back to the law: There is finally some (relatively) good news to report. Recent amendments to the law have been signed into effect, aimed at curbing the predatory nature of these filings and providing a bit more breathing room for legitimate senders.

What changed? The update introduces two key shifts that help mitigate risk for email marketers:

Knowledge Standard: Liability now requires that a sender "knew or reasonably could have known" that a subject line contained false or misleading information.
Reduced Damages: Statutory damages have been lowered from $500 per violation to $100 per violation. While this can still add up to big money in a class action, it significantly lowers the "bounty" that has driven so many recent cases.

Others are saying yay, the problems with this law have now been addressed. I'm not so sure about that, in my layperson's view. The law still doesn't require a recipient to prove they were actually harmed or even that the misleading info was "material" to their decision to open the email.

And I feel like this law might be leading some law firms to salivate a bit; as recently it seems that a number of the ads I was seeing on social media seemed to be from law firms looking to invite email recipients to report violations, perhaps hoping that people will enable or join class action litigation.

But, still, smart folks are saying that this is an improvement.

For a deep dive into the specifics of these changes and what they mean for your compliance strategy, I highly recommend reading the full breakdown over at JD Supra:

Positive Industry Changes to WA's Email Law

Disclaimer: I'm not a lawyer, just a loudmouth blogger with an opinion.

When Gmail broke the rules: What a two-day glitch taught us about user intent

2026-04-04T08:30:00.014-05:00

Steven Lunniss, Director of Deliverability for email marketing provider Cordial, was able to answer a very important question back in January, thanks to an unexpected glitch.

The question: What happens to engagement and subscriber sentiment when your email messages are unexpectedly redirected from the promotions tab to the primary inbox?

The glitch: On January 24th and 25th, something went awry at Gmail. Google's filtering was suddenly placing messages in the primary inbox, where they would have been placed in the promotions tab (or maybe even the spam folder, depending on the sender).

The outcome: Engagement increased. But while engagement saw a lift, it wasn't much of a lift. And along with that engagement lift came an even greater boost in unsubscribes.

Steve calls this forced engagement. I think of it as a sender forcing messages in front of recipients that aren't always interested -- or when they are interested, they're interested on their own terms. (Meaning, they know where to go to find your emails when they're ready -- in the promotions tab.)

TL;DR, forcing your way to the primary inbox can have unexpected (and unhappy) consequences.

Read the whole story over on the Cordial blog.

Industry: Apple to enter B2B mailbox space, Amazon exits

2026-04-03T12:23:00.001-05:00

Here’s a quick update on recent comings and goings in the business mailbox provider space.

Amazon to wind down Workmail offering

Amazon just announced that they are shutting down their corporate mailbox solution Workmail. The service officially ends just about a year from now, on March 31, 2027.

Amazon announced Workmail back in 2015. I blogged about it then, but never really ran into it much between then and now. Not to say that it had absolutely zero adoption; I see amazonaws.com in the MX records of just over 14,000 of the top ten million domains, according to my January 2026 DNS snapshot. But I never really ran into it very much out in the deliverability world.

Updated Apple Business offering launches soon

At the same time, Apple has announced that they’ve got a new business mailbox offering. Starting April 14th, their updated “Apple Business” launches with new support for corporate email inboxes and more; combining email and calendaring into their device, domain and even brand management functionality. Meaning, I think that Apple Business Connect, which includes BIMI-like logo functionality, will be managed as part of this suite as well.

I have lots of questions. I read that the Apple offering will be free, but there’s free and then there’s free. I don’t think this is a standalone email service; will there be some sort of overall cost or verification requirement for a business to register – and what constitutes a business, if so?

And will this be hosted on the regular, existing iCloud mailbox infrastructure? Seems possible; it already does have calendar support and custom email domain support. Apple iCloud is lightly represented in the top ten million domains data today, with just over 5,500 domains pointing their MX records at icloud.com, according to my January 2026 snapshot.

I am looking forward to the upcoming April 14, 2026 launch date, so that I can investigate further and learn more about Apple’s new offering. Stay tuned.

DELIVTERMS: Hashbusting

2026-04-01T10:24:00.001-05:00

It is time to clarify another technical concept here on Spam Resource, in our series DELIVTERMS, where we decode email and related acronyms and terms, helping you better understand the messaging ecosystem that surrounds you. Today, the word we’re defining is: hashbusting.

If you have ever seen an email that ends with a strange block of gibberish, a string of random numbers, an unexpected excerpt from Mary Shelley's Frankenstein, or even invisible text hidden in the HTML, you have likely encountered hashbusting. It is an old-school spammer trick that some ignorant or unethical email marketers still use to try to outsmart modern spam filters.

What is Hashbusting?

At its core, hashbusting is the practice of inserting unique, randomized content (often, but not always, hidden from the recipient) into an email message. The goal is to ensure that every single message in a campaign is technically "unique." The hope is that spam filters (or categorization filtering) will be confused or overwhelmed, and less able to successfully fingerprint a bunch of messages accurately.

Historically, spam filters used content hashing to identify bulk mail. If a filter saw 100,000 identical messages, it was easy to flag them as a single bulk blast. By "busting" that hash with random strings of code or text, senders hoped to trick the filter into seeing each message as an individual, one-to-one communication.

Today, senders often use these "tricks" to try to force a specific result, such as:

Moving an email from the Promotions tab to the Primary inbox.
Trying to bypass a spam folder placement.
Avoiding "duplicate content" triggers (i.e. being flagged as bulk).

The Modern Version: Tab/Category Placement

Hashbusting goes way back; it used to be a very simple thing where spammers would append paragraphs of garbage text, sometimes from a dictionary file or public domain books, to the end of the email messages, to confuse filtering. With the modern version of this, the intent is generally more subtle.

“I can get you into the primary inbox!” “Never land in the promotions tab again!” Buy my tool, buy my service. You’ve probably seen these, the loud, self-described deliverability experts on Linkedin, crowing about how they’ve “cracked the code” and that they’ll give you special code that unlocks a guaranteed path to the primary inbox, with every send. Except...

They don’t work. Or rather, sometimes, they do work. Until they don’t work any more. It’s an arms race. They found a way to trick the filters. Today. The filters will very likely catch up tomorrow. It is not sustainable.

And It’s a Bad Practice

While it might sound like a "clever hack," hashbusting is actually a big ole’ red flag. Avoid it, because:

Mailbox Providers See Through It: Modern filters at Gmail, Microsoft, and others are incredibly sophisticated. They don't just look at the "hash" of a message; they look at sender reputation, engagement patterns, and infrastructure. If a filter catches you using hashbusting techniques, it is a clear signal that you are trying to manipulate the system.
Negative Reaction: When a mailbox provider (MBP) notices you are intentionally trying to obfuscate your content, they take a dim view of it. Instead of getting your mail into the inbox, you are more likely to earn a "suspicious sender" label or other special, unhappy treatment, which can lead to aggressive filtering or outright blocking.
It Looks Unethical: From a brand perspective, hashbusting is a bad look. It suggests that your content isn't strong enough to earn its way into the inbox on its own merits. Instead of building a relationship based on permission and value, you’re resorting to "black hat" tactics.

The Better Path

Resorting to tricks and hacks to get email delivered is rarely a winning strategy. If you have to hide random code in your footer to get past a filter, you don't have a deliverability strategy. You’re just playing a risky game.

Authentic brands don't need to hide. High deliverability comes from sending wanted messages to engaged subscribers from a properly authenticated email domain. Focus on those well-known best practices for long term success. Avoid busting hashes.

Want to learn more about email technology and deliverability terminology? For more definitions like this, check the DELIVTERMS section here on Spam Resource.

Dan Stevens: Why I Built a Flat-Rate ESP in 2026

2026-03-23T07:00:00.001-05:00

My friend Dan Stevens (who founded email verification platform Kickbox and hired me there once upon a time) has rejoined the email community! After seeing him announce unMTA, I invited him to author a guest post here to share thoughts about his new venture and what his goals are. Take it away, Dan!

Here's what pisses me off about traditional ESP pricing: it's built for the generic sender… circa 2009. If there are two things I've learned in my years in email, it's that not all senders are the same, and it's not 2009 anymore.

Seventeen years ago, the cost of operating an ESP at scale was legitimately expensive. Hardware was expensive. Bandwidth was expensive. The pricing models reflected that. But infrastructure costs have come down dramatically, and the pricing hasn't followed. The margins on per-message fees at most ESPs are, frankly, obscene.

The worst part is what that model actually subsidizes. Running a shared sending platform means dealing with senders who cut corners, buy lists, or "accidentally" mail a segment they shouldn't have. That costs the platform in reputation, in remediation, in support. And who pays for that? The good senders, through inflated per-message pricing that has to cover the operational cost of cleaning up after the bad ones. You're not just paying to send your mail. You're paying for the platform's abuse desk.

Meanwhile, shared sending infrastructure means your reputation is tangled up with whoever else happens to be on the same IPs. You can do everything right and still take a deliverability hit because your neighbor decided to blast a purchased list on a Tuesday afternoon.

These aren't new complaints. But I got tired of just complaining about them.

Infrastructure is the hard part

A Mail Transfer Agent (MTA), even a great one, is just an MTA. It's the infrastructure around it that transforms it into an ESP.

unMTA is built on KumoMTA, which handles the core MTA piece incredibly well. It's fast, flexible, and free. But a great MTA and a full ESP are still very different things.

BYOIP and BGP. PTR records across hundreds of IPs. DKIM management. IPv6 configuration. Per-customer isolation. IP warming. Bounce processing. Monitoring. DNS architecture for SPF, DKIM, and DMARC. Feedback loop processing. The list goes on, and every item on it is load-bearing. Miss one and your deliverability suffers.

Email infrastructure is a pain no matter how you slice it. I've done it. It's a full-time job, and that's if you already know what you're doing. If you're a sender evaluating build vs. buy, the build side is almost always more expensive and time-consuming than you expect going in. I've watched teams burn six figures and six months trying to stand up what they thought would be a straightforward sending operation.

unMTA sits on the buy side of that equation. You get the control and isolation of running your own infrastructure without the operational burden of actually running it.

What unMTA is

Every unMTA customer gets their own dedicated MTA (or MTA cluster), running on modern, fast hardware and networks.

The IPs are unMTA's, purpose-acquired address space, not inherited from some previous webhost tenant. Full IPv6 support. Proper authentication configured from the start. Nobody else is on your IPs.

That said, dedicated IPs within a shared CIDR aren't invisible to each other. Mailbox providers evaluate reputation at the range level, not just the individual IP. Dedicated IPs are better isolation than a shared sending pool, but they're not the same as having your own ASN and disconnected address space. This is why we're choosy about who we let on the network. The unMTA team manages and monitors who sends on our infrastructure the same way we manage the network itself. If your next-door neighbor is blasting a crypto scam, dedicated IPs don't help, so we don't let that neighbor on in the first place.

The pricing is flat-rate, unmetered. Just like it would be if you were running this in your own data center: nobody is charging you per message. Your throughput is limited by the hardware (which is fast) and the speed the receiving mail servers will accept your mail. That's it.

Who this is for

unMTA is for senders doing hundreds of thousands to hundreds of millions of messages per month who've hit the ceiling of shared infrastructure. Maybe you're on a major ESP and you're tired of your reputation being influenced by other senders on the platform. Maybe you've looked at building your own and realized the operational cost doesn't make sense. Maybe you're an agency and you need to put clients on isolated infrastructure without standing it up yourself.

This is not a platform for lead gen. It's not for cold outreach to purchased lists. It's not for anyone who thinks "unmetered" means "send whatever I want to whoever I want." That's not us being picky for the sake of it. It's a direct consequence of the architecture.

What I expect to learn

The unmetered model is something I believe in, and it's also something I know could be a Pandora's box if not managed carefully.

When you remove the per-message cost lever, you change sender behavior. Much of that change is positive. But some of it requires guardrails. Unmetered doesn't mean unmanaged. We're building this for senders who already have good practices, not for people who need the threat of a bill to keep them honest.

I'm also curious what the market teaches me about where the real pain points are. I've been in this industry long enough to have strong opinions, but also long enough to know that strong opinions need to get tested against reality. Some of my assumptions will be right. Some won't. I'd rather build in the open and adapt than pretend I've got it all figured out from day one.

If any of this resonates, I'd love to hear from you. You can find us at unmta.com.

Choosing the Right Subdomain

2026-03-21T14:08:15.530-05:00

What happens if you choose the wrong subdomain? Does everything explode and the submarine sinks to the bottom of the ocean? Not really, but there are indeed some considerations around choice of subdomain for your various types of email messages.

I recently tackled this topic in my Valimail "Ask Al" video series. If you're the type of person who prefers to watch and listen rather than read, I’ve embedded the video here for you. Or, if you’re all about that written content, stick with me and we’ll dive into it together below.

And this is a question I get surprisingly often. IT administrators frequently need to configure a specific subdomain to point toward an Email Service Provider (ESP). Sometimes the platform requires it for technical reasons; other times, it’s just a best practice for organization and auditing.

But before we talk about what to pick, we have to talk about what not to pick.

Avoid Lookalike Domains

I cannot stress this enough: Stay away from cousin domains or lookalikes. If your main domain is example.com, consider:

Real subdomains: e.example.com, m.example.com, news.example.com, potato.example.com.
Lookalike/Cousin domains (avoid): example-email.com, examplemail.com, marketing-example.com, example.net.

Why does this matter? When you use a lookalike domain, you are training your customers to trust something that is "almost" your brand. You are effectively lowering the bar for phishers and bad actors who love to spin up convincing "close-but-not-quite" domains. Stick to your actual organizational domain. Your real domain.

There are a lot of lookalike domains configured in various email service providers today. That’s usually because a lot of those configurations were initially set up years ago, and nobody has gone back to update it since. Remember that just because you see it out in the wild, does NOT mean it’s still a best practice.

Why Use a Subdomain at All?

If you're wondering why you can't just send everything from your top-level domain (example.com), there are three big reasons:

Clarity and Auditing: Using e.example.com for marketing makes your logs and tracking much cleaner. You’ll always know exactly where that traffic originated.
Technical Necessity: Many ESPs require a dozen or more DNS entries. If you try to put these at the top level, they often conflict with existing records (like your website or corporate email). A subdomain gives you a "clean room" to work in.
Reputation Segmentation: A subdomain provides a buffer. While spam filters are smart enough to link a subdomain to the main organizational domain, having a dedicated subdomain for bulk mail can help insulate your critical corporate/executive communications if your marketing reputation takes a temporary hit.

But, ultimately, YMMV. If it’s possible to send as the top level of your domain, and authenticate everything correctly, that’s not inherently evil. Especially if you’re a small sender and not juggling a bunch of different email send platforms. So, keep all of this in mind and decide on what makes the most sense for you.

Naming That Subdomain

When it comes to the actual name, keep it flexible and neutral.

Don't Box Yourself In: Avoid names like marketing.example.com or sales.example.com. What happens when you start sending transactional receipts, product updates, or customer education from that same platform? Suddenly, a "marketing" label feels inaccurate.
Avoid "Spammy" Keywords: This should go without saying, but don't use blast.example.com or spam.example.com. You don't want a recipient to look at the "From" address and immediately think "unwanted junk."
Keep it Short: Mobile email client real estate can be limited. Shorter subdomains might actually look cleaner in the "From" field. My guidance? Go for choices like m.example.com, e.example.com, or msg.example.com.

Related Bits and Bobs

Once you’ve picked your subdomain name, you’re not quite done. There are a few other things you should keep in mind.

Warm It Up: You cannot go from zero to 100,000 emails overnight on a new subdomain. You need a controlled ramp-up plan. (I highly recommend checking out Jennifer Nespola Lantz’s guide to IP warming for the specifics).
Watch Your DMARC Records: Some ESPs will automatically create a DMARC record for your new subdomain. I've seen cases where they set it to p=reject without an aggregate reporting (RUA) address. If this happens, it can mess things up. If you see a conflicting record, ask your ESP to remove it.
Google Postmaster Tools: Don't forget to register the new subdomain here. It’s the best way to get direct feedback from Gmail regarding your reputation and complaint rates.

There you have it. Not too complicated, I hope. Just remember to use your real domain, pick something short and simple, and remember to configure everything and warm it up properly.

And don't forget to follow my Ask Al video series (aka "Your Email Authentication and Deliverability Questions Answered). Find it here on Youtube.

Podcast Fun: 175 Years of Email Experience (and counting)

2026-03-19T16:58:33.424-05:00

I recently sat down with a bunch of new friends to sit for a podcast recording. The podcast, Email’s Not Dead, is “about how we communicate with each other and the broader world through modern technologies.” Joining me on this adventure? Jonathan Torres, Eric Trinidad, Thomas “T-Bird” Knierien, and Alison Gootee, all from Sinch Mailgun.

We covered everything from the "scary" side of AI summaries to the positive trust signals of BIMI.

That included touching on helping marketers work their way through the “freak out” around those A.I.-generated email summaries, where and how things can go wrong, and why not everybody wants a robot in their inbox.

We also talked about cutting through the misconceptions some marketers have around being “owed” placement in the primary inbox. Hacks are bad; respect the network. How those hacks bite you and what the path is to real long term inbox success.

And finally, we talked about BIMI, the inbox logo standard that builds on email authentication and trust. What is it, how it helps boost engagement, and adoption trends over time.

Whether you want to hear about my first double opt-in email in 1998 or why I’m currently "doing weird stuff with data" at Valimail, you can catch the full episode over on the Sinch Mailgun website.

Thanks to the friendly friends at Sinch Mailgun for inviting me on to chat with them. I had a blast! I hope folks enjoy listening to our discussion.

Cool Tool: Sender Audit by Simon Bressier

2026-03-18T12:00:00.000-05:00

Looking for an easy way to validate that your email is configured correctly? While technical compliance is only part of the deliverability equation (don’t forget our old friends reputation and engagement), it’s still very, very important to make sure you get it right: DNS configured correctly, authentication and headers, too. Sender Audit is a tool that can help you with that, and more! Created by Simon Bressier, this free web-based utility provides a comprehensive health check for your email sending infrastructure.

Sender Audit acts as a "pre-flight check" for your emails. By sending a single test message to a unique address generated by the site, the tool performs a deep-dive analysis of your technical configuration and content.

Authentication Validation: It verifies that your SPF, DKIM, and DMARC records are not only present but correctly configured according to the latest RFC standards.
Blacklist Monitoring: The tool automatically checks your sending IP and domain against major industry blacklists to ensure you aren't being blocked before you even hit "send."
Anti-Spam Filter Simulation: Using industry-standard engines like SpamAssassin and Rspamd, Sender Audit shows you exactly how recipient servers perceive your mail. It flags common issues like suspicious tracking pixels or formatting errors that trigger spam filters.
DNS Hygiene: It ensures your DNS syntax is perfect, helping you avoid the small technical "gotchas" that often lead to hard bounces.

Unlike some overly complex enterprise tools, Sender Audit is straightforward and fast. It gives you a clear "Pass/Fail" look at your deliverability health, making it an essential resource for small business owners, marketers, and mail administrators who want to ensure their messages actually reach their audience.

Head on over to the Sender Audit website to test your emails today!

Meet Jason Morrow, Senior Email Designer & Developer

2026-03-17T16:58:02.063-05:00

Hey, you! Are you looking for work? It’s rough out there, I know. I want to help, if I can. Every now-and-then I’m going to share a post that highlights the name and focus areas of a smart expert in the email space who is looking for work. My goal is to assist with a bit of extra exposure and maybe, if we're lucky, it could even bring potential job leads. Want in? Contact me.

Today, I’m featuring Jason Morrow! Wondering what Jason can do for you? Read on! -- Al Iverson

If you’re looking for someone who can both design and build email — and understands the realities of rendering quirks, dark mode behavior, modular systems, and scalable architecture — Jason is worth a conversation.

Jason brings 10+ years of experience creating visually compelling, conversion-focused email programs across acquisition, onboarding, retention, and lifecycle marketing. Most recently at The Washington Post, he led responsive HTML email design and development in high-volume environments — translating strategy into modular systems that were visually polished, technically precise, and built to perform consistently across Outlook, Gmail, Apple Mail, and mobile clients.

He’s equally comfortable shaping typography and hierarchy in Figma as he is hand-coding table-based layouts with inline CSS. From dynamic content implementation in Iterable to cross-client QA in Litmus, Jason blends strong visual craft with engineering rigor.

He’s currently exploring new remote opportunities across:

Email design & development
Lifecycle / CRM execution
Digital campaign production
Performance-driven creative (email + paid social)

If your team needs someone who understands both the creative vision and the technical execution — and can move quickly without sacrificing quality — Jason would love to connect.

Find him on LinkedIn here, or visit jasonmorrow.com to see his portfolio and learn more.