dns
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
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
If you’re one of those weirdos (like me) who tracks what email providers hosts mail for what domains, you’ll want to take note of this. In the email industry’s ongoing efforts to improve email security, Microsoft is adding the ability for Microsoft-hosted domains to implement DANE with DNSSEC. As Microsoft explains, “SMTP DANE is a security protocol that uses DNS to verify the authenticity of the certificates used for securing email communication with TLS and protecting against TLS downgrade attacks. DNSSEC is a set of extensions to DNS that provides cryptographic verification of DNS records, preventing DNS spoofing and adversary-in-the-middle attacks to DNS.” Anyway, my point is not to dissect the potential value of DANE or theorize how long it’ll take for a majority of customer domains to be updated (Microsoft hosts mail for 750,000 of the top ten million domains, and I’m sure many more beyond that). Instead, I
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
When sending to Microsoft OLC (Outlook Consumer – i.e. hotmail.com, outlook.com, msn.com, live.com, etc.) domains, are you seeing this bounce message?Microsoft: 5.4.4 (unable to route: no mail hosts for domain)If you’re seeing that error message, or something similar, here’s what’s happening, I think, based on what some smart folks have shared with me.All of those domains have an MX record that points to outlook-com.olc.protection.outlook.com. And when you look up the IP addresses for that server mentioned in the MX record, what do you get? Well, when I do it from here, I get just two IPs: 104.47.58.33 and 104.47.55.33.But other folks showed me examples where they were receiving 25+ IP addresses in response. I can’t reproduce it, so I don’t know if it’s geo-specific, intermittent, or if overall, the whole thing has been addressed. I suspect some combination of all of that. But anyway, I’m told that when the results
So much going on in the past week in the world of email deliverability. Multiple email platforms (ISPs/MBPs) and sending platforms (ESPs) having problems or unexpected downtime. Multiple issues with DNS, which is one of those things that few people understand and even fewer people manage or monitor properly. Which is why you should follow Julia Evans and check out her “How DNS Works!” zine, if you haven’t already. And why we all should tread very lightly around those legacy systems that manage so much of the DNS that makes the internet work. But I digress.What’s going on THIS week is that Jennifer Nespola Lantz and I are going to present a webinar on Wednesday specifically talking deliverability as it relates to the little guy. You’re not paying a Marketing Cloud a million dollars for platinum support. It’s just you and maybe somebody else and you’re managing your sends out
Did you know? For the past fifteen years, I’ve run a simple little website at xnnd.com that provides a set of DNS lookup tools. My goal was to have a simple set of tools to help you troubleshoot DNS issues. You can do things like look up DMARC settings for a domain, try to find the DKIM selector(s) in use for a domain, check a domain’s BIMI record, query the same IP or domain against a bunch of different public DNS servers all at once (helpful to catch intermittent or propagation-related issues), and a few other things. This past weekend I moved XNND from Amazon’s AWS to Google Cloud (partly to save some money, and partly to see if I could do it), and so far it seems to have moved over just fine — but if you see anything amiss, please feel free to let me know!
Are you seeing this bounce message when trying to send mail to Yahoo subscribers?451 Message temporarily deferred due to unresolvable RFC.5321 from domain; see https://postmaster.yahooinc.com/error-codesAnd you’ve checked and confirmed that your sending domain seems to resolve for you, so you’re wondering, what the heck is going on and what do I do about it? If so, Steve Atkins has got you covered. Over on the Word to the Wise blog, he explains how Yahoo is looking for an SOA record (Start of Authority) in DNS and depending on how your DNS and delegation are configured, you could be misconfigured in a way that most don’t notice, but would fail this check.Click on over to Word to the Wise to learn more. Thank you, Steve, for clearing this up! It’s a tricky one.