Cannot receive email from a Office365-hosted domain

Sygmoral

Verified User
Joined
Aug 15, 2012
Messages
63
I am hosting the email for "Site A" with DirectAdmin. Another domain (not administered by me), "Domain B", has its email hosted at Office 365 (aka Microsoft 365). Now, when they try to send email from "Domain B" to "Site A", it fails with a notice from the Microsoft server, saying it tried to deliver the email, but the DirectAdmin server responded that it does not accept the email due to a misconstrued PTR / rDNS record.

Okay, great, but it's impossible for a Office 365 email hosted domain to fix that, because the emails are sent by various IP addresses at Microsoft (as explained here by a MS agent).

I tried adding Domain B to the SpamAssassin whitelist for Site A, but of course that has no effect because SpamAssassin is never even triggered. As far as I understand, this is being blocked at the connection level, before any content is actually sent. (Which explains why the failure notice has a Office365 layout.)

Confusingly, when I send an email from another Office365-email-hosted email (that I do administer), everything does work. But I cannot find a fault in "Domain B"'s records, it has the correct Office365 DNS records (MX, SPF, autodiscover).

Sooo. How can I stop my DirectAdmin server from blocking emails from this Office365-hosted domain? Can I "whitelist" everything being sent by *. protection.outlook.com, for example (not in SpamAssassin but "before" that)?
 
Last edited:
It's possible to whitelist outlook.com however it's odd that the server responded it's due to an incorrect PTR/rDNS record. This can easily be checked.

You stated you have all records setup correctly like MX, SPF, Autodiscover. Did you also unselected this option on the mx page?
Use this server to handle my emails.
If not, change the MX record and uncheck this option

And "Select your remote email provider" set to Microsoft 365 (which automatically makes the autodiscover etc. for you)?

Especially unchecking the first option I mentioned is important, maybe you already did, just checking to be sure.
 
I am hosting the email for "Site A" with DirectAdmin. Another domain (not administered by me), "Domain B", has its email hosted at Office 365 (aka Microsoft 365). Now, when they try to send email from "Domain B" to "Site A", it fails with a notice from the Microsoft server, saying it tried to deliver the email, but the DirectAdmin server responded that it does not accept the email due to a misconstrued PTR / rDNS record.

Okay, great, but it's impossible for a Office 365 email hosted domain to fix that, because the emails are sent by various IP addresses at Microsoft (as explained here by a MS agent).

I tried adding Domain B to the SpamAssassin whitelist for Site A, but of course that has no effect because SpamAssassin is never even triggered. As far as I understand, this is being blocked at the connection level, before any content is actually sent. (Which explains why the failure notice has a Office365 layout.)

Confusingly, when I send an email from another Office365-email-hosted email (that I do administer), everything does work. But I cannot find a fault in "Domain B"'s records, it has the correct Office365 DNS records (MX, SPF, autodiscover).

Sooo. How can I stop my DirectAdmin server from blocking emails from this Office365-hosted domain? Can I "whitelist" everything being sent by *. protection.outlook.com, for example (not in SpamAssassin but "before" that)?
I have the exact same problem.

Did you solve this problem eventually?
 
I have the exact same problem.

Did you solve this problem eventually?
I am sad to say that I have not been able to solve the issue. In fact, I am in the process of discontinuing use of all mailboxes hosted on my DirectAdmin server, and migrating them to Google Workspace or Microsoft 365... It's just too much trouble trying to solve all the little issues related to email and spamfilters etc, for me anyway.

Sorry for the disappointing reply :)
 
Odd.... we also receive mails from Office 365 but don't encounter this issue.
I do have outbound.protection.outlook.com put into my /etc/virtual/whitelist_domains file so that might also be of use.
 
Same here, never have problems with receiving emails from with outlook / Hotmail domains.
Usually people complain about the delivery to this domains but its now opposite :)
 
Found it!

The office365 sender domain www.example.com (I name it example.com to keep my domain anonymous) was also configured on the direct admin server, cause we host the website www.example.com for that domain there.
Because of that direct admin examines that incoming mail differently. Its an office 365 email being sent to a directadmin server which actually has that domain configured aswell!

I resolved it by following Richard's instructions, logging in to the useraccount for example.com -> MX records, deselecting the option for the directadmin to handle mail and selecting office 365 as the mail provider!

The Mail response from Office 365 basically confused the fridge out of me, but it makes sense.
 
I have the same issue. Client has his hosting with hosting company A. I host company B and my own company C on a VPS server. My client can no longer mail to B and C. I can no longer mail to my client. The hosting A says they can not fix the problem since microsoft switches IP adress. How can i adjust my vps to receive mails from this client? Spam assist doesn' t work. Do i have to adjust this? if so where and how? 'I do have outbound.protection.outlook.com put into my /etc/virtual/whitelist_domains file so that might also be of use.'

this is the error i recieve:
Fout:550 5.7.363 Remote server returned sender verification failed -> 550 Verification failed for <[email protected]>;Sender verify failed
Bericht geweigerd door:srv.moof.be
Meldingsdetails
Verzonden door:AS8PR02MB8496.eurprd02.prod.outlook.com
 
550 Verification failed for <[email protected]>;Sender verify failed
The server who has the rewah.com on his server should fix the issue imho. Some nameserver is not correctly and more important they used a CNAME record for an MX record. MX records always need to be an A record.

So the server with rewah.com needs to fix those DNS records, you can find more info here:

You can also whitelist all Office365 ip's but I wouldn't do that, here's a list:

But as you can see, using the *.protection.outlook.com should be enough anyway. Fix the MX records and try to not use CNames.
 
Back
Top