Laura Atkins
I’ve seen a bunch of folks panic about some phrasing in Google’s Email sender guidelines. Buried deep in the Message formatting section Google say: Don’t use HTML and CSS to hide content in your messages. Hiding content might cause messages to be marked as spam. Read literally that might cause you to wonder about your use of CSS display:none to switch between different content on desktop and mobile. But that’s not what Google are concerned about – they’re targeting spammers who load up their mail with hidden text (“hashbusters“) in an attempt to make the content of the mail look like one thing to spam filters and a completely different thing to the human recipient. And a variety of similar deceptive behaviour intended to avoid spam filters, or avoid the spam folder or the promotions tab. (This is common behaviour amongst bottom of the barrel spammers. If you see someone
I wrote last year about using “stunt” nameservers for customer subdomain authentication – i.e. dynamically generating all the authentication records needed in DNS for each customer as needed. For example, if you’re an ESP that has customers who can’t or won’t use their own domains and you still need to give them unique subdomains you can generate CNAME records to support white label DKIM authentication: selector ._domainkey. customerid .espcustomer.com CNAME selector .dkim.esp.com or generate white label DMARC with useful rua= reporting: _dmarc. customerid .espcustomer.com TXT “v=DMARC1 p=none rua=rua+ customerid @esp.com” Once you’ve set up these DNS records once they’ll work for all your customers, you just need to put the right domains in your DKIM signature and return path. I shared some demo code to explain the concept last year, but since then we’ve developed a robust, production-ready application to dynamically serve DNS in this way. It’s called
We just got back from Amsterdam a couple of days ago, after attending the Deliverability Summit. It may have been the best email event I’ve been to in several years. Not too big, not too small. Plenty of space and time to meet up with folks. Mostly great sessions, a better average than most conferences. Well organized, at a lovely location, with a safe and welcoming environment. Andrew et al. did a great job putting it together. A better return on time and effort than some of the bigger conferences. Keep an eye out for it next year; maybe we’ll see you there.
When trying to find out why Something Went Wrong during delivery of an email we sometimes want to look at the route by which it was delivered. Did SPF break because of an unexpected forward? Did DKIM break because an intermediate mailserver modified the content of the message? Why did it take nine hours from the mail leaving our ESP to make it to the inbox? Did it really leave our ESP when they say it did? Did Microsoft internal handoffs break something again? Received headers are the breadcrumbs that record the path an email took. Every time a mailserver receives an email it adds a Received header at the top of the mail (so the most recent Received headers come first). And it mustn’t modify any of the existing Received headers. A Received header looks complex, but they have quite a strict structure, and they’re fairly easy to read
Six years ago today I wrote here “Spam isn’t going away“, talking about systemic problems at Google, Cloudflare and Amazon and in India. If I were writing it today I might mention Microsoft, Salesforce and ExactTarget as well as Google, and might stress Amazon less (mostly because all the Amazon spam sites tend to be hidden behind Cloudflare, so you don’t know they’re Amazon sites). And OVH, of course. But the gist of the story hasn’t changed in six years, and the conclusion is as valid today as it was then: There will be increasing volumes of B2B spam being sent for the foreseeable future, and there doesn’t seem to be much we can do to change that. If your career involves filtering inbound spam – consumer, smb or enterprise – it seems your skills will be in demand for a long while yet.
TXT Records DKIM public keys live in DNS TXT records. A DNS TXT record contains strings of text, and each string is limited to be no more than 255 characters long. Recommended practice for DKIM at the moment is to use 2048 bit keys (1024 bit keys aren’t insecure, but they’re looking a bit weak and 2048 is where folks have mostly decided to move to). But a 2048 bit DKIM key is going to be around 400 characters long. So how do we fit that into a TXT record? A TXT record can contain more than one string, so we can split the 400 character public key into two strings, put both of those strings in a single TXT record and the DKIM validator will join those two strings back together and use them to validate the email. A single TXT record containing three strings Editing your DNS Unfortunately
The worst thing about the yahoogle requirements has been their use of the term “one-click unsubscribe”. It’s an overloaded term that’s being used here to mean RFC 8058 in-app unsubscription. That’s a completely different thing to what one-click unsubscription has been used to mean for decades, often in the context of complying with legal requirements around unsubscription. It’s confusing. So here’s the simple explanation. To comply with everyone’s unsubscription requirements you need to do two things. First thing You need to have a clear link visible in the body of your message that allows users to unsubscribe. It’s the link you already have in the footer of your message: When the user clicks on it they should go to a web page. That web page must have a clear, conspicuous button that the user can click to unsubscribe. It cannot require them to provide any other information. That page can
It’s not always easy to know what the actual headers and body of an email as sent look like. For a long time accepted wisdom was that you could send a copy to your gmail account, and use the Show Original menu option to, well, see the original message as raw text. It turns out that’s not actually something you can trust. I used swaks to send a test message with an extra header to my gmail account. swaks –to wttwsteve@gmail.com –from steve@blighty.com –add-header “List-Unsubscribe: =?us-ascii?Q?=3Cmailto=3Asteve=40blighty.com=3e?=” Code language: JavaScript ( javascript ) We can see swaks sending it: -> DATA Date: Wed, 17 Jan 2024 08:49 :59 -0800 -> To: wttwsteve @gmail.com -> From: steve@blighty.com -> Subject: test Wed, 17 Jan 2024 08:49:59 -0800 -> X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/ -> List-Unsubscribe: =?us-ascii?Q?=3Cmailto=3Asteve=40blighty.com=3e?= -> Code language: CSS ( css ) But when we then go to gmail and click on Show
Yes, it’s another yahoogle best practices post. Google divide their requirements for senders into those sending more than 5,000 messages a day, and those sending less. Yahoo divide their requirements into “All Senders” and “Bulk Senders”, and explicitly don’t define that via a volume threshold: “A bulk sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold.”. So … do you need to count how many messages you send, to see if Google thinks you’re a bulk sender or not? No. Definitely not. Google state a threshold just so they don’t have to argue about the definition of “bulk sender”, I’m sure. In practice they’ll be using the same definition as bulk sender as Yahoo – we know it when we see it. But the real distinction isn’t volume – it’s whether you’re professional, grown-up sender or a hobbyist. If
Yes, it’s another yahoogle best practices post. Google divide their requirements for senders into those sending more than 5,000 messages a day, and those sending less. Yahoo divide their requirements into “All Senders” and “Bulk Senders”, and explicitly don’t define that via a volume threshold: “A bulk sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold.”. So … do you need to count how many messages you send, to see if Google thinks you’re a bulk sender or not? No. Definitely not. Google state a threshold just so they don’t have to argue about the definition of “bulk sender”, I’m sure. In practice they’ll be using the same definition as bulk sender as Yahoo – we know it when we see it. But the real distinction isn’t volume – it’s whether you’re professional, grown-up sender or a hobbyist. If