Office 365 - Set up or fix your domain's PTR record

Community Support Mail
1

I have two domains that are both functioning well on Hestia.

The first domain is using the default RoundCube email setup provided by Hestia. Everything works perfectly, with emails being sent and received from all providers without any issues.

The second domain is configured with Office 365 DNS, and it seems to be operating smoothly as well. However, I’m encountering an issue when sending emails from this domain (office 365) to the first domain (using Hestia and RoundCube). I receive the following error:

A security check at hestia-round-cube-domain.com failed due to misconfigured settings at 365-domain.com.

More Info for Email Admins
Status code: 550 5.7.363

It appears that the recipient’s email server at hestia-round-cube-domain.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 365-domain.com isn’t set up correctly.

Set up or fix your domain’s PTR record - If you’re the admin for 365-domain.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.

Are there any specific DNS records that need to be added?

2

With only fake domain names to work with, your guess is as good as anyone’s.

1 Like
3

It looks like misconfiguered PTR records as well as there maybe a slight chance of IP blacklist (not sure 100%). But this is what got pulled up on search:

4

Thanks for the response, everyone!

Is there a way to disable reverse DNS (rDNS) lookup security check on Hestia? My research indicates that this is an outdated security measure.

1 Like
5

Your DNS records look fine. Thanks for the DM.

I don’t install the HestiaCP email components or use exim, so I cannot readily answer your question on how to adjust that setting.

It depends how it’s implemented, but it certainly can have more aggressive results than needed.

1 Like
6

I know you started a new topic, but I don’t know if this question fits there. Have you looked at your HestiaCP mail logs for one of those messages that is refused by your HestiaCP exim?

Can you share the log from one such transaction here. You can substitute example.com and example.net if you want to keep the domains private.

7

Just sent you the log inbox.

1 Like
8

You can see from your logs (edited for privacy) that there is a PTR on the relay host IP.

2025-05-23 17:13:57 H=mail-bn8nam11on2127.outbound.protection.outlook.com (NAM11-BN8-obe.outbound.protection.outlook.com) [40.107.236.127] sender verify fail for [email protected]: Unrouteable address
2025-05-23 17:13:57 H=mail-bn8nam11on2127.outbound.protection.outlook.com (NAM11-BN8-obe.outbound.protection.outlook.com) [40.107.236.127] X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_128_GCM:128 CV=no SNI=mail.example.com [email protected] rejected RCPT [email protected]: Sender verify failed

Sender verify failed is the interesting part.

It looks like your exim is trying to verify the existence of the sending email address and not finding a satisfactory response at the server it is querying.

Does the email address of [email protected] exist on the mail system that is operating at the MX for that (sending) domain? Does it exist in the M365 tenant that is sending the mail? (It may not need to, but I don’t know which host would be checked by sender verification, as I don’t use any such feature.)

You don’t have email set up without any users on HestiaCP for the sending domain, do you? We don’t want exim thinking that it is supposed to be sending or receiving email for that domain.

9

The email address [email protected] (edited email) is valid and fully operational on Microsoft 365.

It appears to be functioning properly with most other email providers, such as Gmail and Outlook, but is encountering issues specifically with Hestia.

Since all users are configured on Microsoft 365, I have not created them on Hestia.

By configuring the “accept senders” How can I disable the reverse DNS lookup security check in Hestia/Exim?, I was able to resolve the issue of emails sending from Microsoft 365 to Hestia. However, emails sent from Hestia to Microsoft 365 are still not going through.

I sent you the logs for your review.

10

Good. HestiaCP should not have that domain configured as a mail domain when it uses another system for its mail.

Speaking of, your MX records for that domain do not point to M365. If you are using some MX based filtering system in front of M365, make sure that it accepts email for any addresses that you have configured in M365 in case that is where exim is attempting to validate the sender.