Sender verify failed with incorrect reverse DNS record
What a week! Switching hosting providers, setting up a new content management system for this blog (more on that as soon as it’s ready) and all at the same time as suffering e-mail problems as, since the middle of the week, every e-mail that I’ve sent to a particular contact has bounced back with the following message:
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
someone @ somewhere .net
Reporting-MTA: dns; mymailserver .markwilson.co.uk
Final-Recipient: rfc822; someone @ somewhere .net
Action: failed
Status: 5.5.0
Diagnostic-Code: smtp;550-Verification failed for < myalias @markwilson.co.uk>
550-No Such User Here
550 Sender verify failed
I have various anti-spam measures on my mail server, but this appeared to be a problem when sending mail to a particular external host - e-mail sent to the same contact via a different mail server was received with no problems.
I set about researching the 550 Sender verify failed message and found various suggestions as to what might cause such an error - the most useful of which was a message on a newsgroup post which suggested it may be caused by an incorrect reverse DNS (PTR) record (thanks to Ben Winzenz for replying to that group a couple of years ago).
Even though much of my mail was being delivered successfully, that seemed like a perfectly reasonable explanation - the reverse lookup for my IP address would have returned a hostname in the format username.myisp.co.uk, rather than mymailserver.markwilson.co.uk (as confirmed by a DNS report on my domain, which also commented that “RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry”), so I set about getting the record updated by my ISP (it has to be done by the owner of the IP address block).
Initially I asked my ISP to add my mail server’s DNS name as a second PTR record for my IP address but in practice I found that DNS responded in a round robin pattern (rather than returning all the matching records) so I couldn’t rely on a consistent response and was still experiencing mail delivery failures. Finally, after reverting to a single PTR record for my IP address and waiting for DNS propagation (again), I was able to successfully send e-mail to the contact with whom I’d previously experienced issues (phew!).
As more and more hosts take action to prevent unsolicited commercial e-mail (UCE - also known as spam), this is likely to be a more common occurrence and it just underlines how important a correct DNS configuration is.