Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


550 5.7.1 Cannot relay

Posted on 2012-03-16
Medium Priority
Last Modified: 2013-05-24
I have an exchange 2007 sp1 running on windows 2008. I am currently having the following problem:
1. There is 1 domain that is giving me a delay error with 550.5.7.1. I can send emails both internally and externally with no problems except to this 1 email domain.
2. The email eventually gets sent after a some hours.
3. I tried to telnet to the user and recieved the 550 error as well. However, whenever i try to send email to anybody using telnet it gives me the 550 error.

Any ideas? mx and ptr records are all correct and I am not grey or blacklisted.
Question by:jerrywalk1
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 7
  • 4
  • 3
  • +4

Expert Comment

ID: 37729853
Have you tried sending an email from a free service like gmail or hotmail to this domain to see if the connection goes through?

Author Comment

ID: 37729886
Yes. They work fine.

Author Comment

ID: 37801404
Does Powershell have you tied up in knots?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why


Author Comment

ID: 39176378
I am still randomly having this problem. Right now it is just with 1 domain. I am getting the following. We changed IP addresses but all of our DNS is correct and checks out fine with our ptr record as well. Anys suggestions?

Diagnostic information for administrators:

Generating server: LEDA.FDS.ORG

mail.axcesspc.com #501 5.7.1 <user@fds.org>... Sender IP must resolve ##

Original message headers:

Received: from LEDA.FDS.ORG ([::1]) by LEDA.FDS.ORG ([::1]) with mapi; Thu, 16
 May 2013 19:42:49 -0400
From:User <user@fds.org>
To: "user@specjan.com" <user@specjan.com>
Date: Thu, 16 May 2013 19:42:47 -0400
Subject: testing for theresa
Thread-Topic: testing for theresa
Thread-Index: Ac5SjxAFewutnf2DTHSefu4tlicnmA==
Message-ID: <72B3B9E74A8BE34587AE380958FB1E6B518EB7D0@LEDA.FDS.ORG>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--39.546300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative;
MIME-Version: 1.0
LVL 28

Accepted Solution

Ryan McCauley earned 668 total points
ID: 39193424
We had this problem with our mail server as well - in our case, it was a result of the public IP address of the server not resolving to the DNS address provided in the HELO/EHLO handshake. This should show you how to change the DNS name your server is providing to the remote SMTP server:


It's spam protection, and only some servers take this step, but the remote server is doing a public reverse DNS lookup on your IP and it has to match the DNS name you're providing. If they don't match, the remote server sees you as a potential spoofer and refuses to accept the mail. This prevents another mail server, from a different IP address, from claiming to be mail.yourdomain.com, as the reverse DNS won't match.

This wouldn't explain why it's spontaneously delivered a few hours later - ours were never delivered and the 5.7.1 response terminated the connection. Maybe they have multiple servers in a load balance and some are configured to do reverse DNS lookup and some aren't, and you just have to wait until you happen to round-robin to one that doesn't care?
LVL 47

Expert Comment

by:Craig Beck
ID: 39193667
It's an issue with the recipient's mail server.

The "Unable to relay" message usually appears when the receiving SMTP server is trying to deliver a mail to a domain it's not authoritative for.  If that's the case then it can't be your fault.
LVL 18

Expert Comment

ID: 39194165
I would agree with craigbeck...the problem appears to be the recipient's mail server.  Have you tried to email into their server with a gmail account or some other account not related to your i-domain/email system?  If so what are the results?

Since the email eventually gets to the destination, there could be a problem with the target server itself simply not able to handle the volume.  Therefore SMTP traffic is delayed and deferred and can possibly take up to 4 days to reach the destination (default on some systems I work on).
LVL 28

Expert Comment

by:Ryan McCauley
ID: 39194178
When I've seen 5.7.1 in the past, it's usually been in the context of mail relay - in this case, the OP has posted the whole message and it looks like it's a pretty common configuration problem. Searching for "5.7.1 Sender IP Must Resolve" returns many people who have the same issue, and it sounds like the reverse DNS lookup problem that I've had previously, and I discussed above.

It's misleading, but the "Unable to relay" message is "550 5.7.1" and this message is "501 5.7.1", so the error code is subtly different.

Author Comment

ID: 39194192
@ryanmccauly all of our DNS and ptr records are correct. They all resolve fine. When you do a test using mxtoolbox all of it comes back fine with everything pointing back to the correct ip address and dns.

@zenandemailguy and @craigbeck What i have found is that when I telnet into AOL from my server it acts as though it does not see the correct DNS. I telnet into others and run it fine. It is as though the DNS never updated on AOL side.
LVL 47

Expert Comment

by:Craig Beck
ID: 39194240
So its fair to say the AOL DNS resolution isn't working properly.

Also, do you use an SPF record?  AOL use SPF verification.
LVL 28

Expert Comment

by:Ryan McCauley
ID: 39194245
It looks like checking for banner mismatch is part of the mxtoolbox suite of tests, so it should have thrown an error if this was incorrect. I'm not sure how this would work, but is it possible Exchange is providing a different banner when sending (when you see this error) than it is when receiving (what it's doing when mxtoolbox checks your server)? I don't doubt your MX and the reverse DNS on your domain is set up properly, but what exchange reports as its DNS banner doesn't have to be your domain - it can be anything at all - and that configurable free-form field is what's causing the issue.

Is it possible to get a copy of the conversation with this one remote mail server that's causing you issues? That should show the EHLO, response, and then the 501 5.7.1 as the remote server refuses to accept the mail because of (what the error code says is) a banner mismatch.
LVL 28

Expert Comment

by:Ryan McCauley
ID: 39194255
Though I'd admit that I'm a bit out of my element, it looks like a bad (or misconfigured) SPF record leads to:

550 5.7.1 SPF unauthorized mail is prohibited

Rather than the message he's seeing. It's likely either a reverse-dns problem at AOL with your IP address or a banner issue.
LVL 47

Expert Comment

by:Craig Beck
ID: 39194404
@ryanmccauley - agreed, it's unlikely to be a SPF issue, however the sender's DNS zone is checked for the presence of an SPF record by AOL.  If one doesn't exist within the zone or the SPF record doesn't specify the sending mail server, the error you noted is displayed.  If the sender's domain can't be resolved by the receiving server this message won't ever be displayed as the SPF record can't be queried.

That goes back to DNS resolution on the AOL side.

I've just tested the domain mentioned in post 39176378 and its rDNS entry at MXToolbox - everything is fine.  So, again, it looks like an AOL issue.

Author Comment

ID: 39194446
We dont have an SPF at all. The only thing that changed was the public IP as we changed vendors. Everything was updated correctly as far as DNS and ptr records. We didnt have to change any of our FQDN as this did not change. Again...its looking like the DNS didnt not update on AOL side. We have 3 other domains having this same problem. It is not widespread at all. Comcast is the other one having the same issue. I am checking with AOL now...rather i have my ISP checking it with them. Let's see what happens.
LVL 25

Assisted Solution

by:Brian B
Brian B earned 668 total points
ID: 39194635
I would confirm with your service provider that your rDNS record is correct. Some mail server confirm against this to make sure your email server is actually who you say you are.

When I have seen this in the past, I was usually able to fix it by routing outbound mail through the service provider's smart host.

Worst case, speak to the operators at the recipient domain and get them to whitelist you.
LVL 27

Assisted Solution

Steve earned 664 total points
ID: 39195874
the error you are getting is definately rDNS related.

> set type=mx
> fds.org

Non-authoritative answer:
fds.org MX preference = 10, mail exchanger = leda.fds.org

leda.fds.org    internet address =
> set type=ptr

Non-authoritative answer:     name = leda.fds.org

Open in new window

I have checked your DNS & rDNS and it does appear to be right so the logical explanation is to check your IP is correct when sending.
I recommend checking the external IP your server is using to make sure it matches up.

try http://www.whatsmyip.org/ to confirm your IP is listed as

Author Comment

ID: 39195979
Ok So i figured it out. The ISP is using 2 different IPs. 1 is for email and 1 is for my firewall. Email going out on my firewall has a different IP than email that is coming in. So we had to do a ptr record for the outgoing email. ONce we created that it all worked. Weird earthlink set up with MPLS.

Author Closing Comment

ID: 39195980
Thanks all. Your feedback helped me to track down the issue.

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The main intent of this article is to make you aware of ‘Exchange fail to mount’ error, its effects, causes, and solution.
This month, Experts Exchange sat down with resident SQL expert, Jim Horn, for an in-depth look into the makings of a successful career in SQL.
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
This video demonstrates how to sync Microsoft Exchange Public Folders with smartphones using CodeTwo Exchange Sync and Exchange ActiveSync. To learn more about CodeTwo Exchange Sync and download the free trial, go to: http://www.codetwo.com/excha…

610 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question