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
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?
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
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).
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.
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.
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.
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.