Office 365 email to 3rd party bounce back due to "Misconfigured PTR record"
Hi Experts
Here is the setup
1. Sender is using Office 365
2. Sender workplace does not have fixed IP.
3. Sender's workforce is mobile. Could work from many different locations including wifi hotspot, 3G/4G, client wifi, etc
4. ONE Recipient mail server is refusing email from sender. Office 365 (sender mail server) sent an NDR message to the sender - see below
Question 1: Is the recipient mail server reacting to where the emails come from (Office 365 server) or where the emails were created (the IP of where the Outlook was when the email was created)?
Question 2: Is there a solution to this issue? The sender's workplace ISP does not offer fixed IP. The "Outlook's ISP" can change on a daily basis. So is there a solution to this issue?
Here is the setup
1. Sender is using Office 365
2. Sender workplace does not have fixed IP.
3. Sender's workforce is mobile. Could work from many different locations including wifi hotspot, 3G/4G, client wifi, etc
4. ONE Recipient mail server is refusing email from sender. Office 365 (sender mail server) sent an NDR message to the sender - see below
Question 1: Is the recipient mail server reacting to where the emails come from (Office 365 server) or where the emails were created (the IP of where the Outlook was when the email was created)?
Question 2: Is there a solution to this issue? The sender's workplace ISP does not offer fixed IP. The "Outlook's ISP" can change on a daily basis. So is there a solution to this issue?
Your message to peter@recipient.com couldn't be delivered.
A security check at recipient.com failed due to misconfigured settings at sender.com.
Action Required: Misconfigured PTR record
How to Fix It
The recipient's email server at recipient.com performed a security check against your message and the check failed. To fix this, forward this non-delivery report (NDR) to your email admin.
Was this helpful? Send feedback to Microsoft.
____________________________________ ____
More Info for Email Admins
Status code: 550 5.7.363
It appears that the recipient's email server at recipient.com performed a reverse DNS (rDNS) lookup security check to verify that the IP address the message is coming from is associated with the sending domain, and the lookup failed. It appears that the pointer (PTR) record for sender.com isn't set up correctly.
Set up or fix your domain's PTR record - If you're the admin for sender.com, work with your DNS hosting provider (your domain registrar, Web hosting provider, or ISP) to correctly set up a PTR record for your domain. If you're using Office 365 to manage your DNS records note that PTR record creation and management isn't supported in Office 365, so you'll have to change your DNS management to a DNS host outside Office 365. Refer to this article for more information and instructions: Change how DNS records are managed with Office 365.
Unfortunately, Office 365 Support can't help you fix these kinds of externally reported errors because Office 365 doesn't support PTR record management.
Original Message Details
Created Date: 12/08/2016 3:54:42 AM
Sender Address: john@sender.com
Recipient Address: peter@recipient.com
Subject: test email
Error Details
Reported error: 550 5.7.363 Remote server returned sender verification failed -> 550 Verification failed for <john@sender.com>;No Such User Here;Sender verify failed
DSN generated by: HK2PR04MB1700.apcprd04.prod.outlook. com
Remote server: ctp8kvm5.webhosting.openconnect.com. au
ASKER
Hi David
As far as I know, a PTR record can't be added at the registrar end and instead has to be added at the ISP end as it is an IP > name record rather than name > IP record.
I saw that other Expert Exchange question as well, but the
I already contacted the recipient email server admin who stated that it was a problem with Office 365 and not their problem which is obviously incorrect
I think we are in a no-win situation unless
1. The recipient changes email provider
2. or the recipient email provider somehow relaxes its own rules
Alexandre
As far as I know, a PTR record can't be added at the registrar end and instead has to be added at the ISP end as it is an IP > name record rather than name > IP record.
I saw that other Expert Exchange question as well, but the
I already contacted the recipient email server admin who stated that it was a problem with Office 365 and not their problem which is obviously incorrect
I think we are in a no-win situation unless
1. The recipient changes email provider
2. or the recipient email provider somehow relaxes its own rules
Alexandre
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Hi Jian
This is a GREAT solution as sender uses Reflexion.net for inbound traffic and could use it for outbound as well... I will need to try this. Will post back an answer when done and tested
Alexandre
This is a GREAT solution as sender uses Reflexion.net for inbound traffic and could use it for outbound as well... I will need to try this. Will post back an answer when done and tested
Alexandre
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
You can't setup PTR's for Microsoft - they will have already done that and the problem won't be related to their PTR record.
The problem may stem from how the account has been setup on the device. If it has been setup as an Exchange account, there shouldn't be a problem as the PTR record will be correct for Microsoft.
If the account has been setup as POP / SMTP, then that isn't the correct way to setup a 365 account, so it should be removed and re-added as an Exchange account which should solve the problem.
To answer your questions:
Question 1: Is the recipient mail server reacting to where the emails come from (Office 365 server) or where the emails were created (the IP of where the Outlook was when the email was created)?
This depends on how the client is setup. If using an Exchange account, it will be the PTR's at Microsoft. If using POP/SMTP, it will be the PTR of the client's IP where the computer is located (or if using a 3G dongle or equivalent, the non-static Public IP Address).
Question 2: Is there a solution to this issue? The sender's workplace ISP does not offer fixed IP. The "Outlook's ISP" can change on a daily basis. So is there a solution to this issue?
Yes - as long as you are using Outlook set for an Exchange account or if on a mobile, using an Exchange account / Activesync account, there shouldn't be any problems at all.
Alan
The problem may stem from how the account has been setup on the device. If it has been setup as an Exchange account, there shouldn't be a problem as the PTR record will be correct for Microsoft.
If the account has been setup as POP / SMTP, then that isn't the correct way to setup a 365 account, so it should be removed and re-added as an Exchange account which should solve the problem.
To answer your questions:
Question 1: Is the recipient mail server reacting to where the emails come from (Office 365 server) or where the emails were created (the IP of where the Outlook was when the email was created)?
This depends on how the client is setup. If using an Exchange account, it will be the PTR's at Microsoft. If using POP/SMTP, it will be the PTR of the client's IP where the computer is located (or if using a 3G dongle or equivalent, the non-static Public IP Address).
Question 2: Is there a solution to this issue? The sender's workplace ISP does not offer fixed IP. The "Outlook's ISP" can change on a daily basis. So is there a solution to this issue?
Yes - as long as you are using Outlook set for an Exchange account or if on a mobile, using an Exchange account / Activesync account, there shouldn't be any problems at all.
Alan
ASKER
Unfortunately, the sender is connecting to Office 365 using Active Sync / Exchange account and not a POP3/IMAP account. So there <shouldn't> be a problem ... but there is one anyway.
What I'm asking is: "Is the recipient server wrong to refuse connection because of a faulty PTR" when the email comes from Office 365???
I just did a test email. The last email hops (from email header) is
So why, why, why, why, is the recipient mail server saying that the PTR is misconfigured?
What I'm asking is: "Is the recipient server wrong to refuse connection because of a faulty PTR" when the email comes from Office 365???
I just did a test email. The last email hops (from email header) is
Received: from APC01-SG2-obe.outbound.proI checked and 107.47.47.125.43 has a PTR record.tection.ou tlook.com (mail-sg2apc01on0043.outbo und.protec tion.outlo ok.com [104.47.125.43])
by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 87C573C6BCB
for <recipient@optusnet.com.au>; Wed, 17 Aug 2016 18:34:28 +1000 (AEST)
So why, why, why, why, is the recipient mail server saying that the PTR is misconfigured?
i re-read your question
Error Details
Reported error: 550 5.7.363 Remote server returned sender verification failed -> 550 Verification failed for <john@sender.com>;No Such User Here;Sender verify failed
Sender verify error is very rare so it could be something else.
You might want to move the problem from O365 to Reflexion, if it is fixed, then it will end of the question. but it is not, at least you know it is nothing you can do. It is something on the recipient causing the issues.
Error Details
Reported error: 550 5.7.363 Remote server returned sender verification failed -> 550 Verification failed for <john@sender.com>;No Such User Here;Sender verify failed
Sender verify error is very rare so it could be something else.
You might want to move the problem from O365 to Reflexion, if it is fixed, then it will end of the question. but it is not, at least you know it is nothing you can do. It is something on the recipient causing the issues.
I very much doubt that Microsoft will have things setup incorrectly, so it looks like an incorrect check on the receiving server side checking the wrong IP Address (I've never had this problem and I've been using 365 for years and we have over 100 customers using 365 which we manage for them and never had this issue reported to us), but Jian An Lim does make a very good point about the error you are seeing and that may the issue and not PTR problems.
Alan
Alan
Check the year on top of page if you have any contra opinions.
https://tools.ietf.org/html/rfc1123#page-84
Or use Gmail/yahoo/vpn if you cannot understand 3 sentences of 27 years old specification.
https://tools.ietf.org/html/rfc1123#page-84
Or use Gmail/yahoo/vpn if you cannot understand 3 sentences of 27 years old specification.
ASKER
Thanks Jian An.
I still believe the recipient server is misconfigured, but I could not be bothered fighting with them. Your input allowed me to work around the issue
I still believe the recipient server is misconfigured, but I could not be bothered fighting with them. Your input allowed me to work around the issue
You can believe what you want.
MAIL SENDER IS REQUIRED TO HAVE PROPER DNS PTR IN ALL CASES
Thats is so for almost 30 years, no matter how hard your customer pushes you around, their mail will not be accepted at discretion of recipients.
MAIL SENDER IS REQUIRED TO HAVE PROPER DNS PTR IN ALL CASES
Thats is so for almost 30 years, no matter how hard your customer pushes you around, their mail will not be accepted at discretion of recipients.
ASKER
I agree with you Jian An ... but ...
Recipient is Uber Global, Australia (not the ride booking company), now in the middle of a merge with Melbourne IT
Mail sender is Office 365. Can I assume it was set up properly...?
Is it more likely that Office 365 is misconfigured or that Uber Global support is wrong when it tells me that it is not their problem?
In any case your suggestion fixed the issue :-)
Recipient is Uber Global, Australia (not the ride booking company), now in the middle of a merge with Melbourne IT
Mail sender is Office 365. Can I assume it was set up properly...?
Is it more likely that Office 365 is misconfigured or that Uber Global support is wrong when it tells me that it is not their problem?
In any case your suggestion fixed the issue :-)
you mean @Gheist not me.
I aware what happen and i know what i would do (which you have executed what i would do anyway)
and I am in Melbourne so i would know Melbourne IT will not said they have configured them wrongly.
I aware what happen and i know what i would do (which you have executed what i would do anyway)
and I am in Melbourne so i would know Melbourne IT will not said they have configured them wrongly.
Your customer needs to set up a DNS server with reverse zone(s) and ask upstream provider to delegate reverse zone to it.
See this PAQ:https://www.experts-exchange.com/questions/28958333/Recipient-email-server-rejects-senders-email-Office-365-due-to-incorrect-PTR-record.html