Was anything ever completed on this?

just bumping this thread, awaiting a solution...

I'll bump this too. It's only gotten worse in the two years since this was started.  Most of our clients use some sort of SAAS solution that uses their domain now.  The biggest issue we are having is Shopify users not getting their orders. 

Smartermail seems to have gone silent on this like so many other issues.

Isn't this normal behavior of all email servers? I'm not saying that it shouldn't be handled like it was proposed here but IMHO other mail servers are acting the same when they have local domain configured?

 

I think this should be handled just like it was with external MX servers:

 

 

Next to Inbound Message Delivery should be another dropdown or checkbox which would allow domain configuration to check SPF record during delivery for accepting remote emails for this domain. IMPORTANT thing that this scenariu should be also handled in incoming scenario gateway using web service validation.

just bumping this as it's late 2020 and I think this is still pending ?!?

just bumping this again as it's 2021 now ?!?

Hello everyone. I became aware of this thread this afternoon, and I am in the process of reviewing its entire history now. That being said, the behavior originally reported (550 authentication required for relay) in this scenario (sending from a third party server) is expected, and is being handled similarly to other email server software installations as well. 

The recommended fix is to implement a whitelist entry for that third-party server IP under Settings>Security>Whitelist including the SMTP Authentication Bypass toggle. There are no alternative solutions that I am aware of. 

That’s great, but that that doesn’t solve the issue of auto-whitelisting ip’s/domains based on SPF records for the domain, and the fact that you can only whitelist IP addresses in SM which can change often for any 3rd party service like Shopify. I whitelist their IP’s but after a little time they swap them out and I’m back to looking though the logs or perform NS lookups for the new ip addresses to manually whitelist (they refuse to give a list of IP’s) them again. All this while my clients are pissed at me as they are getting bounces that they feel they shouldn’t get, although they don’t understand the issues.

Other email services include the SPF record to allow email from those servers. Like I mentioned above, I have no problem adding to the waitlist but having the ability to whitelist a domain name to bypasss auth would be immensely helpful and would solve this whole issue.

Thanks!

David

I think all of us understand how to whitelist by IP, but like David said, that's just not always an viable solution. Shopify if a prime example, we've had the same issue with them, but they are just one of many. A mail server honoring it's own domain's SPF records doesn't seem like it would cause any problems... I'm not sure the reluctance to implement this.

Thanks for your feedback on this. I do believe we have a feature request in for this, but under the current functionality, you'll need to add an SMTP Authentication Bypass whitelisting for the third-party server so that SmarterMail knows to exclude them from those requirements. Have a good one!

LOL. Five years later and there’s a “feature request”. Under the current functionality, the best solution is another mail server vendor for customers that depend on SaaS providers.

We have the same problem.

But today I tried to send to myself via SMTP in a gmail account. It came out immediately. The email stated my own address as the sender. In the header was the gmail address as Return-Path.

So if the Return-Path differs from the real sender, it works. Apparently, not all SMTP servers have this feature, so there will be problems for them.