550 5.7.1 MX+ Mismatch - When Email Server Administrators Go Bad

My ecommerce provider tried to send a receipt and serial number via email to a newly paying customer today. For some reason - the message didn't go through, and a bounce message landed in my inbox.

I tried resending the purchase information manually - again - it bounced back.

(namechanged@domain.com):
16.118.174.2 (IP changed to protect the guilty) does not like recipient.
Remote host said: 550 5.7.1 MX+ mismatch. See - http://boblabla13.com/07.html
Giving up on 16.118.174.2.

My first suspicion when I see a bounce is that the customer mistyped their email address. The bit about "16.118.174.2 does not like recipient" would seem to confirm this.

Even though they have to verify their address twice when purchasing - this happens more often than you'd think. Usually I get an email from a slightly perturbed customer a few days later - wanting to know where their serial number is. I point out the situation, they get a little embarrassed - but everyone's happy in the end. Surprisingly even a number of PayPal accounts seem to be tied to invalid addresses.

But then I noticed the bit about the "MX+ mismatch." That doesn't sound as simple as a botched email address. I decided to follow the included link for more information.

Error Code Explanation 550 5.7.1 MX+ mismatch
The IP address used to send doesn't match the envelope from.

Email is only accepted to this address if it's sent from an approved IP address. Approved IPs include an IP listed as an MX, or any IP whose reverse DNS is a subdomain of the envelope from domain. For example, if mail from example.com comes from IP that has the reverse DNS mx.example.com, that would be acceptable.

Common ways for this to occur are;

* Using an SMTP server that isn't the one supplied by your provider

That's interesting. It sounds like whoever runs the email server at 16.118.174.2 has invented a number of new rules regarding how SMTP is supposed to work. Unfortunately no one else ever agreed to play by these rules.

Lest there be any confusion, the individual or organization that configured the server is trying to block spam. While this is a noble cause - the rules they have chosen seem somewhat haphazard at best.

According to the message, messages are only accepted from servers when:

1. The sending server is the same as one of the receiving servers (MX records) for the domain.

Newsflash - using an outgoing SMTP "gateway" that is independent from your incoming SMTP server is very, very common. I would guesstimate 25% to 50% of all companies engage in this practice.

But, if a server fails the above test, there's another way for them pass muster with this particularly picky server.

2. The message is sent using an SMTP server with reverse mappings that map to the same domain as the sending address.

This means that a server with a reverse mapping of mail.bobsdiamonds.com could send email for bob@bobsdiamonds.com, but not bob@yahoo.com. This would seem to make some sense.

But what if bobsdiamonds.com also does business as bobsgems.com?

An email server's IP address can only reverse map to a single domain. The email server at 16.118.174.2 would presumably reject any messages from bob@bobsgems.com.

This doesn't even consider common scenarios like using a different ISP's email server when traveling, or sending email via a wireless connection.

There's no question that these rules would eliminate a lot of spam.

In fact, I bet that users getting their email from 16.118.174.2 get very little spam at all.

I also suspect they don't get about 40% of their non-spam email.

Back