Sending Email (Local Domain vs Remote Domain)
Problem reported by John Marx - September 14 at 5:32 AM
Submitted
We had a client this past week move off of our SmarterMail. They didn't tell us. No big deal. In time we always find these things out. The complaint was the speed of SmarterMail. Okay, I can accept that but that is not my concern/problem.

If we had domain xyz.com on our mail server with the MX to our server I would expect the mail to arrive on our server. No issue there.

If we had domain xyz.com on our mail server and the MX record is now on Office 365 I would expect the mail to arrive on the Office 365 server. This is not the case. The email still arrives on our server. 

How can this be fixed as it seems to be a big problem. To test this we added a domain to Office 365, made sure mail was working, added the domain to our server, changed the MX record. Sent an email to that domain from another Office 365 account and it hit our mail server and not Office 365. I repeated this with Gmail and it also worked as I would expect. So how can we get SmarterMail to perform the way other email programs (the true industry leaders) perform?

To me the solution is no matter if a domain is local or not that a DNS MX lookup be performed and not "ASSUME" that if a domain is local that is where the email should go.

As a benefit and suggestion for this scenario as well would be a report that goes to the administrator of a list of domains where the MX record is NOT pointing to the mail server. Obviously, if everything is right there would be no reason to send the email (we already get too much email). If something is broken/mis-configured then send off the email.

2 Replies

Reply to Thread
2
Robert Emmett Replied
Employee Post
John,

To ensure that their mail that does come into your server gets routed to the Office 365 account, please take the following steps:

1. In System Admin > Manage > click on domain in question;
2. In the domain settings > Email set Inbound Message Delivery to External; use MX record if it points to O365; use host address if that's known (Microsoft uses a rotating IP so this may be difficult);
3. Ensure "Deliver locally if user exists" is disable, if you want ALL email to route onto O365.

Please let me know if this works for you.
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
1
John Marx Replied
I set and will see. Is there any way we can get a nightly system check and when the MX record is not pointed at the mail server a report come through? This would help with DNS changes authorized or not to make certain clients are properly taken care of.

Reply to Thread