Technical
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
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
Happy 2024, everyone! We’ve released a shiny new tool to let folks self-check a lot of common questions we see about email requirements. Go to AboutMy.email and send an email to the email address it gives you. Once it receives that email it will go through it and do many of the basic checks we’d usually do to check the technical health of a client’s email1 and displays a detailed report of what it finds. Details it reports on include SPF DKIM DMARC BIMI, including details about the certificate and image What IP address it was sent from, and whether it has valid DNS The size of the mail as sent (no more arguments about Gmail clipping size) The SMTP session as it was delivered The raw payload of the mail as delivered Checks for line length, non-ascii characters, non-CRLF line endings Headers, both pretty (including RFC 2047 decoded) and
Email supports TLS (Transport Layer Security), what we used to call SSL. Unlike the web, which split it’s TLS support off into a completely different protocol – https, listening on port 443 vs http listening on port 80 – SMTP implements it inside it’s non-encrypted protocol. A mailserver advertises that it supports this by having the word “STARTTLS” in the banner it sends after you connect to it. Before you do much else you send the command “STARTTLS”. At this point the tcp connection to the mailserver stops speaking SMTP and is ready for the complex binary dance that is a TLS handshake. Once the negotiation of protocols and ciphers and session tokens is done SMTP comes back. It looks just like it did before, but now it’s all being tunneled over a secure, encrypted TLS session. Sometimes you want to find out a few more details about how a
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
If you’re an ESP with small customers you may have looked at the recent Google / Yahoo requirements around DMARC-style alignment for authentication and panicked a bit. Don’t impersonate Gmail From: headers. Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery.…For direct mail, the domain in the sender’s From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment. So everyone who’s using their gmail address to send bulk mail is going to have to stop doing that within the next few months if they still want their mail to be delivered. For any ESP customer that already has, or can be convinced to buy, a domain for their web presence maybe they can be persuaded to switch to using that – though even if they can, onboarding 100,000 technically naive users
When you query DNS for something you ask your local DNS recursive resolver for all answers it has about a hostname of a certain type. If you’re going to a website your browser asks your resolver for all records for “google.com” of type “A”1 and it will either return all the A records for google.com it has cached, or it will do the complex process of looking up the results from the authoritative servers, cache them for as long as the TTL field for the reply says it should, then return them to you. There are dozens of different types of records, AAAA for IPv6 IP addresses, MX for mailservers, TXT for arbitrary text, mostly used for various sorts of authentication (including SPF, DKIM and DMARC). And then there’s CNAME. CNAME stands for “Canonical Name” and means “Go and ask this different question instead”. If you have a DNS record
Learn what is Microsoft Smart Network Data Services (SNDS), including how to utilize SNDS data to improve your email program. The post What Is Microsoft Smart Network Data Services (SNDS) and Do I Need It? appeared first on SendGrid.