Avatar of jerrywalk1
jerrywalk1
 asked on

550 5.7.1 Cannot relay

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.
ExchangeWindows Server 2008

Avatar of undefined
Last Comment
jerrywalk1

8/22/2022 - Mon
Michael Smolens

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

ASKER
Yes. They work fine.
jerrywalk1

ASKER
Anybody?
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
jerrywalk1

ASKER
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

user@specjan.com
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19872.002
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;
      boundary="_000_72B3B9E74A8BE34587AE380958FB1E6B518EB7D0LEDAFDSORG_"
MIME-Version: 1.0
ASKER CERTIFIED SOLUTION
Ryan McCauley

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
GET A PERSONALIZED SOLUTION
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
Craig Beck

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.
Scott Kunau

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).
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
Ryan McCauley

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.
jerrywalk1

ASKER
@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.
Craig Beck

So its fair to say the AOL DNS resolution isn't working properly.

Also, do you use an SPF record?  AOL use SPF verification.
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck
Ryan McCauley

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.
Ryan McCauley

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.
Craig Beck

@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.
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
jerrywalk1

ASKER
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.
SOLUTION
Brian B

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
SOLUTION
Steve

THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
⚡ FREE TRIAL OFFER
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
jerrywalk1

ASKER
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.
jerrywalk1

ASKER
Thanks all. Your feedback helped me to track down the issue.
Experts Exchange is like having an extremely knowledgeable team sitting and waiting for your call. Couldn't do my job half as well as I do without it!
James Murphy