dns

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.

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”

A friend warned me of a scenario that could have the potential to freak people out, if misunderstood. It looks like this:This person is using Spamhaus to filter inbound mail.They seem to be rejecting mail from Gmail due to a Spamhaus listing.The Spamhaus website DOES suggest there might be an SBL entry (a blocklisting) for Gmail.So…Spamhaus is blocking Gmail? NO, no no. Gmail is not blocklisted by Spamhaus. Promise. Here’s what’s actually happening.Using Spamhaus is good, but querying Spamhaus using open/public DNS resolvers is bad. Spamhaus is actually rejecting those queries — they’re not blocking mail from Gmail. The person running into this problem needs to switch over to using the Spamhaus DQS (Data Query Service), and that ought to just flat out fix things.As noted above, the rejections are actually because the email administrator of the mailbox provider or mail server in question has configured Spamhaus in a way