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

Microsoft changes

There’s been quite a bit of breakage and delivery failure to various Microsoft domains this month. It started with them changing the MX for hotmail.co.uk, then the MX for hotmail.fr… and both these things seem to have broken mail. I also saw a report this morning that some of the new MXs have TLS certificates that don’t match the hostnames.

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

Engagement drives deliverability

Return Path released an white paper today offering the Secrets of Successful Senders. I don’t think any of my readers will be surprised that it boils down to identity, reputation, and engagement. Return Path treats these as separate things and I understand why they do. I think however, that the identity and reputation are supporting players to the overarching issue of engagement.

When I’m dealing with clients and troubleshooting deliverability problems and offering solutions, I focus on the root cause. To me the root cause is almost always a data problem. Either there’s a problem with data collection or there’s a problem with data maintenance. These problems result in mail going to people who don’t really want or care about it.
Yes, identity is important. But, realistically, anyone mailing through a decent ESP has SPF and DKIM in place, at least on some level. There may be better ways to authenticate, but the boxes are checked.
Yes, reputation is important. But here’s the thing, reputation just means that the ISP knows how users are going to react to an email. Reputation isn’t some nebulous concept made up by ISPs. It’s an actual measurement. It quantifies the history of an IP or a domain or a mail stream and says we know that this IP sends wanted mail. We know that this domain sends mail our users ignore. It’s a history. Past performance does indicate future results.
Identity says who a sender is. Reputation tells us that sender’s history of sending. Those are the two factors that enable ISPs to make delivery decisions. Mail comes in and the ISP looks at it. They use identity to determine what reputation to assign to a mail. Reputation drives delivery, whether into the inbox or the bulk folder.
 

Read More