Delivery Improvement

Since I wrote about it last month the requirements for bulk senders to Yahoo and Google have changed a little. The big change is that bulk senders need to authenticate with both SPF and DKIM, rather than SPF or DKIM. Only one of those has to align with the 822 From: header.

On Tuesday I wrote about using DNS wildcards to implement customer-specific subdomains for email authentication. As I said then, that approach isn’t perfect. You’d much prefer to have per-customer domain authentication, where each customer has their own DKIM d= and ideally their own SPF records, rather than having all customers sharing those records and relying on loose DMARC alignment to have them to work with a per-customer subdomain in the 5322 From: header. But doing that with DNS wildcards would have some odd side effects, such as TXT records appearing where they weren’t expected, in ways that could trigger bugs in rarely tested code paths at mailbox providers and potentially even open up security problems. I mentioned using a “stunt” DNS server would be one option to do that, and then quite a few people asked me what I meant by that. A stunt DNS server is one that doesn’t

One of the most common refrains I hear from folks with delivery problems is that the filters must have changed because their mail suddenly started to go to the bulk folder. A few years ago, I posted about how even when there is no change in the sender’s behavior, reputation can slowly erode until mail suddenly goes to the Gmail bulk folder. Much of that still applies – although the comments on pixel loads (what other folks call ‘open rates’) are a bit outdated due to changes in Gmail behavior. While it is often true that reputation drives sudden delivery problems there are other reasons, too. Filters are always adjusting and changing to meet new challenges and threats. We’re seeing these changes rolling out at some of the consumer mailbox providers. Steve recently wrote about changes that Yahoo! was making related to domain existence. He also posted about Microsoft getting

Seen this recently? 451 Message temporarily deferred due to unresolvable RFC.5321 from domain; see https://postmaster.yahooinc.com/error-codes This is Yahoo doing some extra work to identify that the 5321.From domain1 of the mail is acceptable to them. Yahoo are going (slightly) beyond what’s required for the return path to be valid in SMTP terms. SMTP just requires that the return path be syntactically valid – i.e., looks like an email address – and that it be deliverable. The basic DNS check you might do would be to check if the right-hand-side of the email address has an MX record2. So for a bounce address of bounces@email.example.com you’d check to see if email.example.com had an MX record. Yahoo want to also check that it looks like a legitimate address in another way, that the organizational domain of the right-hand-side looks legitimate. The organizational domain is what you might think of as a “domain”

When we’re looking at the technical details of email addresses there are two quite different contexts we talk about. One is an “821 address” or “5321 address”. This is the email address as it’s used by the SMTP protocol, as part of the “MAIL FROM: ” or “RCPT TO: ” commands sent to the mailserver. It’s defined in RFC 821, now updated by RFC 5321, hence the name. If someone mentions the “envelope” or they’re talking about “bounce addresses”, this is the sort they mean. We’re not talking about them in this post. The other is an “822 address” or a “5322 address’. They’re the ones the recipient sees in the To: or From: headers. They’re named after their RFC, RFC 5322. This is the sort of email address most folks mean by default, unless they’re explicitly talking about the envelope of an email, but if someone describes an email

It looks like Microsoft are getting pickier about email address syntax, rejecting mail that uses illegal address formats. That might be what’s causing that “550 5.6.0 CAT.InvalidContent.Exception: DataSourceOperationException, proxyAddress: prefix not supported – ; cannot handle content of message” rejection. Why do we care? It’s good to send syntactically valid email in a warm fuzzies sort of way – it shows we know what we’re doing, and aren’t dodgy spamware – but it’s increasingly important to delivery as mailbox providers are tightening up on their syntax checks. But why are mailbox providers doing that? One reason is that authentication tech like DKIM and DMARC is built around them only being applied to email. Not to messages that kinda look like email. There are ways to bypass DKIM protections by sending invalid messages. As one example, if you send multiple copies of the From: header with different values a DKIM checker

I’m repeating the presentation I gave at M3AAWG in London for the Certified Senders Alliance.It’s all about how to send an email by hand, and how knowing the mechanics of how an email is sent can help us diagnose email delivery issues.We’re starting in about five hours from when I post this.Register at https://register.gotowebinar.com/register/2268789893122531343

I did a class at M3AAWG teaching the basic mechanics of sending an email, both really by hand using dig and netcat, and using SWAKS. No slides, but if you’re interested in the script I’ve posted a very rough copy of my working notes here.

I regularly see folks asking how to fix their Gmail delivery. This is a perennial question (see my 2019 post and the discussions from various industry experts in the comments). Since that discussion I haven’t seen as much complaining about problems. There are steps that work to get delivery fixed at Gmail. Verify that your mail is actually going to bulk. I had one client that had a bad / medium reputation at Google, but their mail was actually inboxing for the most part. We spent a lot of time trying to fix the reputation without success but it didn’t matter as they were reaching the folks they needed to reach. Cut way back on your mail to google. Stop sending to anyone who is currently receiving the mail in their bulk folder. About the only way to know who’s getting mail in bulk is to focus on those folks who…