Friday, April 16, 2010

5.5.0 smtp;554 : Relay access denied

5.5.0 smtp;554 : Relay access denied
5.5.0 smtp;554 : Relay access denied
gunther.imbrechts@... - 10/03/07 Hello,

Some users within our organisation receive NDR's like this:

Your message did not reach some or all of the intended recipients.

Sent: 3/10/2007 16:04

The following recipient(s) could not be reached: on 3/10/2007 16:05
There was a SMTP communication problem with the recipient's email server. Please contact your system administrator.
: Relay access denied>

We have this issue only with a few mail recipients. My configuration:

Exchange 2003 SP2 with FE and BE configuration. There are 2 WAN IP's, #1 and #2, first one is for outbound traffic, second is for inbound. When doing a reverse lookup of our #1 IP, tells us that the A record of our domain published in the PTR (=same as the HELO hostname) is not pointing back to the originating IP. But when I google a bit I found that normally there shouldn't be any problem using different WAN IP's on inbound and outbound. Does it maybe mean that I should publish our SMTP clients on the second IP address, or should I change our DNS configuration so that the A record points to #1 IP?

If I do a reverse lookup for the PTR of our #2 IP address, it gives us the same domain as when I do it for #1. No errors concerning A records for this reverse lookup, because the A record for this domain points back to the same IP, #2.

One last thing, if I don't want to change any of the two options above, could an SPF record maybe help me out?

Thanks a lot for your help,


1. Exactly the same problem! - mailserver HELO?
crastinblack@... - 10/05/07 Hi, I'm having exactly the same problem as you in that we are also getting the 554 Relay access denied NDR when we try to send email to certain domains.

I have two internet connections (although SMTP is bound to only one), and spam filtering relays (MX properly configured so that all incoming mail goes through those).

I know that receiving mailservers perform a reverse-dns lookup on the source IP to get the hostname, then perform a forward-dns lookup to get the IP of that hostname and they double-check that the resulting IP is the same as the source IP. I've manually done this to verify, it all checks out. Which leads me to think that these domains that I can't send email to must perform an additional check on the address that our mailserver gives in it's EHLO.

At the moment, my mailserver identifies itself as in it's EHLO statement. I think perhaps that it should be fully-qualified (as in
1.1. Progression...
gunther.imbrechts@... - 10/06/07 Hey crastinblack,

I read that you should use indeed a FQHN. Did you set up a SPF record for your domain? You can let disappear certain relaying issues (mostly due to spam filters) using an SPF record. There is even a little tool which helps you out configuring a correct spf record, but the link is on my company's computer.

For my issue, last Friday I changed our configuration so that inbound and outbound SMTP traffic pass over the same IP. (#1) Our ISP should only change the A record to point to that IP#1


2. 554 Errors
wmadoty@... - 04/29/09 What I have found is that this issue is frequently related to errors in DNS. Some ISP's (the list is growing) will do different types of verification to check if a message is valid before receiving it. I am sure we are all familiar with the lack of a reverse lookup for a mail server, but some ISP's are also checking to see if an email account is valid before receiving the message.

This validation is done by looking up the MX record for a given domain and then checking the mail server listed in the MX record to verify that the sender has an account on that machine. Most mail servers will respond to this query. Once it is known that the user does exist in the mail domain, the mail is received and delivered to the appropriate box.

If the server does not respond to this query or the senders account does not exist on the server referenced in the DNS MX record for that domain, the 554 DNR error message is issued.

Check your MX Records and your PTR records on your DNS server. If you have more than one MX record for domain make sure the records are valid and the priorities are properly set. This will fix a lot of the 554 problems.

No comments: