>> The scenario was when [email protected] was sending their mail to >> [email protected] (external to op.pl, totally different service), and >> [email protected] in turn forwarded the mail to [email protected], the op.pl >> server rejected the mail with a message requring authentication - because it >> Saw a sender address from op.pl domain. I think I see similar >> misconfiguration here.
Exactly what im saying. The third server has no way of validating "its own hosted domain" to "itself" to what to say. As I made the example with "sebbe.eu" validating "127.0.0.1" against SPF. Thats why DirectSend exist. To facilitate this type of validation. But since its Microsoft 365, this restriction suddenly applies to ALL tenants, so when [email protected] mails to [email protected] both hosted at microsoft, suddenly the DirectSend restriction applies like in the op.pl case, like both of the domains were op.pl Its extremely hackish, I know, and there is no "industry accepted solution" or "standarized solution for this other than having a internal policy. Could kinda work with kind of a internal SPF policy, like: tenantdomain.com IN TXT "v=intspf1 domain:exampledomain.com user:[email protected]" Which would then mean that a tenant on the same server as tenantdomain.com having the domain exampledomain.com may mail with @tenantdomain.com as sender. And a user [email protected] can mail as tenantdomain.com when tenantdomain.com and example.org is hosted on the same server. You understand the idea? That would need to be standarized in some way. So multi-tenant email servers can allow domain owners to set up a secure policy for allowing other tenants to mail with their domain without going through SPF. Best regards, Sebastian Nielsen _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
