Undelivered mail without a bounce

A few weeks ago I wrote a blog post focusing on one small part of bounce handling. Today I want to talk about delivery failures that aren’t bounces. This is really the biggest issue for companies who have written their own bulk sending servers. Modern bulk MTA appliances and ESPs correctly handle these types of bounces. However, when you’re troubleshooting it’s important to know that sometimes there won’t be a SMTP level bounce.

When we talk about bounce handling, we’re usually talking about what happens during (or after) the SMTP transaction. That’s built into our terminology. User unknown, 5xy, 550, 4xx is all shorthand we’ve taken from the email protocol documents. There are some types of delivery failures that happen before a SMTP transaction happen. And, like the SMTP failures, they can be permanent or temporary.

Domain not found in DNS

The first thing an outgoing mail server does to send mail is look up the mail exchange (MX) record for the receiving domain. There are a few different responses a DNS server can return. The expected response is a domain name that is actively configured to receive mail for that system. The sending server can move on and attempt to deliver the mail.

When there is no MX configured there are a couple different responses returned. All of them contain a blank MX record, but they also include a status message. If a domain exists, but just doesn’t have a MX configured the DNS server returns a NOERROR status. If a domain or subdomain doesn’t exist in DNS the DNS server returns NXDOMAIN. For NXDOMAIN the email address should be marked as undeliverable and removed from future sends.

What to do in the case of NOERROR isn’t as clear cut. It is a perfectly valid configuration to have no MX published in DNS but to accept mail. What happens is a DNS lookup is performed for the A (or AAAA) record of the domain. If there is an A record then the mail server attempts to deliver to port 25 at that IP address. In the vast majority of cases there is a MX record and any domain publishing a blank MX is not accepting mail. This is even more true when we’re looking at the consumer email domains. However, it’s not 100% guaranteed that a domain will publish a MX record. Overall, I think that if there is a blank MX then mail to that domain should be suppressed as a domain with no email users. This recommendation may result in a very, very tiny fraction of email to hobby and personal domains being suppressed. But I think that overall, it’s better to suppress than attempt to deliver to domains that may not actually want mail.

Sometimes a DNS server will return a SERVFAIL response. In this case, current delivery will fail but the address can be retried in the future.

DotMX or localhost in DNS

There are a couple things that a domain owner does to identify a domain that does not accept email. One of those is using a single . (yes, it’s really just a dot) in the MX record (RFC7570). This is a clear statement by the domain owner that this domain is never used for email. Some domain owners put in a record of 127.0.0.1 or localhost. In both cases, these responses mean mail will never deliver and all future mail to that address should be suppressed.

No server at the MX

Sometimes the domain does respond with a MX but there is no mail server there. Behind the scenes, the sending mail server attempts to connect on port 25 but the connection attempt times out because there is no answer. This situation isn’t as clear cut as a NXDOMAIN or a dotmx. There are cases where a server might not answer temporarily. Ideally, the MTA will requeue the mail and attempt to send it over a few days. If the failure continues over a long period of time then it’s likely this is a dead domain and future mailings to the domain should be suppressed.

Overall, these bounces are quietly handled by competent ESPs and modern bulk MTAs. But they do happen. It’s not a spam issue, but it is a data hygiene issue. Excessive numbers of people submitting addresses with no MX, or a dotMX or no server at that domain mean that they’re also likely submitting addresses that belong to unsuspecting third parties. Understanding what about the collection process is encouraging forgeries should result in cleaner deliverable data.

 

 

Related Posts

The Internet is hard.

There are so many things that need to happen to make the Internet work. DNS entries need to be right. MXs need to be set up. Web servers need to be configured. And, let’s be honest, anyone who has ever run their own services on the Internet has flubbed a configuration.
We don’t think about it, because most of the time the configurations are handled by scripts and they do things right. But at some point someone needs to type in something and there’s a risk it will go horribly wrong. I’ve been digging into domain data for a client of mine today. I think I’m going cross-eyed over it. But I have found so many weird things that just mean someone isn’t paying attention to what they’re doing.
Like the domain that has a MX record that says:
nullmx
 
I’m pretty sure the intention of the domain owner is to publish a null MX. But they added an extraneous “0” in there and ended up publishing something really weird. Even worse, the MTA that this client is using is listing this as a “delivered” email. I’m pretty sure that mail to that domain never left the MTA.
I’ve found horribly typoed MX domains for popular spam filters. I’ve found domains that have invalid characters in them. I’ve found domains that are totally a mess.
The vast majority of us have some story or other of the time we really broke things by accident. Like the time a very large ISP deleted their MX records. Or when a different ISP changed their internal forwarding and broke SPF authentication for everyone mailing that domain. Or when another ISP accidentally blocked every IP beginning with 6.
Sometimes I’m amazed that the Internet ever works. No matter how big it gets, there are actual people writing actual code and configurations. The number of things that have to happen to get packets from A to B is pretty impressive. We rarely ever notice the breakages, the people who run things are really good at their jobs. But sometimes poking in the grotty corners reminds me how easy it is to break things. It’s sometimes a wonder things actually work.
 

Read More

SPF and TXT records and Go

A few days ago Laura noticed a bug in one of our in-house tools – it was sometimes marking an email as SPF Neutral when it should have been a valid SPF pass. I got around to debugging it today and traced it back to a bug in the Go standard library.

Read More

About that DMARC "exploit"

A security researcher has identified a rendering flaw that allows for “perfect” phishing emails. From his website:

Read More