Split domain with office 365
Problem reported by Sérgio Rocha - 7/14/2020 at 4:32 PM
Submitted
Hi Everyone,

We have a client that want to split email hosting with office 365.
Before we validate with the client that works, I search and follow this article:


That resume in this steps:

  1. (365) Add the domain in O365
  2. (DNS) Configure the required O365 DNS records including pointing MX records to 365
  3. (DNS) Tweak the SPF record to accommodate the smartermail server usage
  4. (365) Change the domain to internal relay
  5. (365) Create a connector to point back to smartermail (i.e. 365 to my mail server)
  6. (SM) Configure the domain  in smartermail: Domain Location=External (Use MX record), Tick 'delivery locally if user exists'
With the domain we used to test everything worked fine.

Now we are trying do with the client domain and we always getting the erro (on smartermail):

rsp: 550 Authentication is required for relay

I try almost everything but always the same error, can everyone give me a clue?

Thanks


30 Replies

Reply to Thread
0
Sérgio Rocha Replied
I saw in release notes that was a problem in the 7208, but I'm on 7242
0
Sérgio Rocha Replied
anyone?
Thanks
0
Sérgio Rocha Replied
Hi,

We did the upgrade to the last version and the problem persists.

Regards,

0
Paul Blank Replied
I have a SM / Office 365 split domain working on the near-bulletproof SM 15.7.6970*, SM Enterprise, set up for one domain only. Some of the SM settings for this are not exactly clear, but it works pretty much perfectly. 

Regarding SM delivery to Office 365 servers...

This is what I have set for external delivery in V15 - not sure how your SM config screen(s) look:

Domain Location: External
External Host Address: [domain-com].mail.protection.outlook.com
and of course you've already checked "Deliver locally if user exists"

You might try contacting Linda Pagillo of mailsbestfriend.com, known for Declude. She's on here a lot, with tons of helpful info.

*nobody uses the Outlook desktop app, so that's not a concern
0
Sérgio Rocha Replied
Hi Paul,

Thanks for your response.
Yes we set domain records like o365 recommends.
The problem is in SM (v17-last) receive an email for a local account from office 365 account with the same domain (non local) rejects the email with the error: 550 Authentication is required for relay. And yes, in the domain in the inbound local delevery we set: External (use MX Record), and we already try with External Host Address, same result, SM ignore the External Configuration.

We tested with another domain and it worked well. Now in the real client domain doesn't work.

Regards
0
Paul Blank Replied
I don't have a good answer for you at this point, but I'm curious as to where the 550 message is originating, SM or Office 365. 
0
Paul Blank Replied
Also, have you entered contacts in Office 365 for all users on the SM server?  
0
Sérgio Rocha Replied
Error is on SM, on email reception from office 365 connector. The problem is in intra-domain email  messages, for example an account that only exist in Office 365 send an email for another account hosted in smartermail. The enter in the office 365 connector and because the "from:" came from an account that does no exist in local smartermail domain, he reject.
0
Paul Blank Replied
So, messages from outside the domain are getting through to SM, but not - as you said - intra-domain emails?
0
Sérgio Rocha Replied
Yes, the problem is when the from address its from the same domain and came from an outside server.
I open a support ticket for this issue
2
Sérgio Rocha Replied
So I open a support ticket related to this issue, and after a few post, in resume:

"this was submitted to the product backlog because it is a deviation from the current product behavior" 

We have a product that in every release give features and take out others. I bit tired of the last years path of development.

0
Paul Blank Replied
I have no idea what that message means. SM should certainly work in a split-domain environment. 

And if it worked OK in a test environment with the same software version, why would it not work in a similar environment? 
0
Sérgio Rocha Replied
I repeat the test with test domain and didnt work intradomain accounts. It doesnt work any more. I try upgrade to version 17 to see if any of the upgrade resolve, without success. The only think I get with the upgrade was lost the list of EAS accounts. Another feature that disappear.

They say that this issue goes to backlog. It only one more lots feature. And they propose that I open a forum post to get support from the community to resolve this "deviation".


0
Andrea Rogers Replied
Employee Post
Hello, 

We've found that this issue occurs because Require SMTP Authentication is enabled for the domain. SmarterMail is expecting authentication, and the delivery fails because it is not provided. At this time, the only solution for bypassing that requirement is to whitelist the IP. However, we've escalated this functionality for review, as we can see how that is not an ideal solution. 

Paul, I understand you are running a similar setup in version 15.x. Can you confirm whether you have SMTP Authentication enabled for that domain?

Andrea Rogers
SmarterTools Inc.
877-357-6278

www.smartertools.com

0
Sérgio Rocha Replied
Hello Andrea,

But if you don't select Requere SMTP Authentication you create an open relay. I show that option to tony, but its not an option.

Regards,
 
0
Paul Blank Replied
This is for SMTP authentication from O365 -> SM? I will check how I have that connector set up. 
0
Lakshan Salgado Replied
If this is sorted out it will help us keep some accounts from moving to 0365. I'd rather get rid of the super large mailboxes to them and keep the smaller ones on prem.@Sergia, if you can update this thread when you got it going that will be great.
1
Nathan Y Replied
We run split-domain configuration across multiple client domains in combination with Microsoft 365 (O365) and encounter no problems under v17 including the latest 30th July 2020 build. Nothing, fancy, the config follows the steps outlined in the first post so nothing unusual.

Outline of the config:

1. Public MX points to M365
2. Domain configured within 365 as internal relay
3. A connector scopes all tenant domains, delivers to the hostname of smartermail, TLS enabled
4. Smartermail configuration:
4a. Inbound message delivery = external MX
4b. Deliver local = yes
4c. SMTP authentication = yes

Any given user is only defined in 365 or Smartermail so that mail flows between environments.
0
Paul Blank Replied
@ Nathan: Per Microsoft, I created an (O365) Exchange contact for each non-O365 account (in this case, each SM user or alias), for O365 delivery to SM. 

It's working fine; my config doesn't work without this contact list. However, do you have a way around this? 
0
Nathan Y Replied
@Paul,

I suspect that is the problem, there is no need to create contacts unless you want it for the purpose of a 'unified' GAL in 365. We do not do that. 

If you need it, the only real option I can see would be to give your Smartermail domain an alias of client-domain.onsome-other-domain.com (you get the idea, an alias in another domain so mail can be routed out of the tenacy) and configure the contacts with the alias domain based email address. This way intra-org emails will flow transparently, albeit using an alias for 365 > Smartermail if using the GAL. Externally everyone's real email address would work.

As mentioned, we do not complicate matters with attempting to created a unified GAL either within 365 or Smartermail. We leave that limitation as it is. However, the workaround suggested would work in both directions with domain aliases.


0
Sérgio Rocha Replied
Hi Nathan,

I did exactly what you describe, but don't work in my setup, that's the reason why I open a ticket, because maybe it was something in other configuration that conflict with, maybe it was some of the N upgrades that I made that leave something to upgrade. But the response for the ticket is that my result its the expected.

On your configuration the user that only exist in O365 can exchange email with user that only exist In SM?

@Paul, the problem is when the email arrive to SM, because the exchange connector does what is supposed, when an account for the domain not exist in O365 it puts the email in the connector that deliver to SM (and SM reject the email)
0
Nathan Y Replied
Hi Sergio,

I thought I would sanity check that 365 and Smartermail users in the same domain can exchange email and I can confirm that we have full two way email comms between them in the split-domain configuration. 

This is with the current build but from our perspective it has worked without issue since we moved from v15 directly to v17 following the beta period. We never deployed any of the beta builds in production.

Do you have a h/w firewall performing SMTP inspection /  have to feed it with a list of 'internal' domains? 
0
Sérgio Rocha Replied
Hi,

No I do not have firewall check, and I have sure that the email is rejected by smartermail. Should be some configuration not related with the domain that block the email.

Maybe SM knows a bit more about this.
0
Sérgio Rocha Replied
Nathan,

Can you compare your configuration with this imagem

In configurations » Protocols

Thanks
0
Paul Blank Replied
@Nathan

I don't need a GAL, but that's what I worked out with Microsoft techs when I set things up. This client even wants all mis-addressed messages delivered to a catch-all, and that's also working fine (Microsoft doesn't officially support this, but does allow it).

At some point I'd like to know more about how you've got your split domain set up, but at this time I have other non-email fish to fry. Cheers. 


1
Nathan Y Replied
Sergio... Spotted the problem,  'Enable domain's SMTP auth setting for local deliveries' is disabled on our setup which makes sense. It appears to be a setting that does not have a use case in my opinion :-)

Reading the help file, enabling this forces authentication if an email is 'from' another user in the domain but originates outside of smartermail. This perhaps makes sense 90% of the time but what about systems the legitimately 'spoof' emails from a sender that lives on your domain as is the case in a split-domain scenario. It could equally apply in many other situations.
0
Sérgio Rocha Replied
Nathan,

Thank you! I will investigate a little more about the impact of disable the option. But its a litle bit sad that the resolution came from the community and not from the SM support team that should understand the all process. ( I had a open ticket )
Any way the option should except only the domains with external local delivery and not all domains.

Thanks
0
HCardoso Replied
Any update on this? How can we use a hybrid environment without disabling the function "Enable domain's SMTP auth setting for local deliveries"?

Thanks
1
Paul Blank Replied
Re: Enable domain's SMTP auth setting for local deliveries:

FYI on my v15 install with split domain, that box is un-checked as well (under Protocol Settings / SMTP in).

I do not recall if it was enabled by default, or if I had to do anything with it in order to make the split domain work. We've had no local delivery compromises or issues, so I'm going to leave that as it is.
1
Sérgio Rocha Replied
Hi,

I have an open ticket with smarter tools and the issue is not forgotten, they email few weeks ago with questions.
The change that they need to do is very simple, they must check if the domain has the local delivery set to External, and in this case ignore the general option, Enable domains SMTP auth setting for local delivery.

Regards  

Reply to Thread