Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My knowledge of Exchange isn't particularly great, so excuse me if some of the terminology I use isn't quite right. I'm primarily a web developer who's now responsible for a small business's network.

We have a server running SBS 2008 and Exchange 2007. Generally, everything works well, emails are able to be sent to both internal and external domains without issue. We've only got ~20 users, Exchange is sitting on a single server.

I use SendGrid to send emails generated by our externally hosted website to users in the office. Primarily, order notifications are sent to Without any pattern and less than once per week on average, an email to will bounce back, and the logs on SendGrid detail the following error:

550 5.7.1 Unable to relay for

Either side of that failed delivery attempt, I'm able to send and receive emails to/from

Having done some research, incorrect reverse DNS seems like it could be a cause of intermittent bounces like this. Having used nslookup, I have found that the reverse DNS doesn't map like it should, e.g.

Office IP: 135.325.351.123 (made up IP, for example only)
Domain: (made up, for example only)
Reverse DNS: (half made up)

Could this be a cause? I'm sure that the IP address and the domain should map to each other.

Also, it has been suggested to me that as the Exchange server is on a network with an ADSL connection, that could be a potential cause as the connection "goes up and down all day long". I don't have an opinion on this, as I don't have enough knowledge of Exchange/ADSL to form a reliable opinion.

Can anyone offer any insight as to whether one or both are actually potential causes, or if there is another possible cause?

share|improve this question
Yes that is the cause. Sending mails from an ADSL connection will always lead to delivery failures. You need to relay through a server with a static IP. – mailq Nov 30 '11 at 0:11
The server definitely has a static IP address, and it's only receiving emails that we have an issue with, and as I say, it only happens a handful of times a week out of 100s of emails that we receive. Am I right in thinking that with an ADSL connection, when the connection is down (even if it's only for a small amount of time) and an SMTP server attempts to deliver an email to a domain mapped to that IP, that could cause the bounce? – Steve Kennaird Nov 30 '11 at 10:52
It can cause a bounce. But not a bounce with the above message. It would read something like "550 5.7.1 Bounce verification failed" – mailq Nov 30 '11 at 11:39

Reverse DNS can be an issue when it comes to spam filters (some providers require the correct reverse ptr record).

The other issue could be you have multiple MX records and incorrectly configured, i'd check this as a precaution.

share|improve this answer
I have two mx records set up, (priority 10) and (priority 100). Do I need the second record? – Steve Kennaird Nov 30 '11 at 10:57
If you don't know why you have a secondary MX, then you don't need one. But a secondary MX can definitively cause the above message in the case that it doesn't feel responsible for the domain – mailq Nov 30 '11 at 11:42
up vote 0 down vote accepted

Both comments led to me finding the solution. Yes the ADSL will cause me issues, and I did have a faulty MX record set up for a backup mail server, which has since had it's IP changed. The answer for my scenario is to use a backup mail server to allow emails to still be delivered to the domains I manage even when my internal server cannot be reached (due to the ADSL connection). This backup mail server will be external, and will be a paid-for service (e.g. MxSave with a SLA).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.