>>Last time he sent invoices the emails were rejected by various other >>Outlook 365 customers because 'DirectSend' is set to forbidden for the >>sending domain.
This is because DirectSend is kind of a "MS internal policy". In the same way, you can't send emails from this server (dns2.sebbe.eu) with a sender of [email protected] unless you are authenticated. Its a local policy, it has nothing to do with SPF. Even if I would set my SPF policy to +all, it wouldn't accept the mail still, because its a local ACL that controls that. Because a server can't ask the SPF on itself if you understand what I mean. It wouldn't make sense to check if 127.0.0.1 is allowed to use [email protected] SPF is used between EXTERNAL to EXTERNAL servers. Sending mail from Microsoft 365 to Microsoft 365 is INTERNAL mailing. Like you would mail from [email protected] to [email protected] >>The customer confirmed, according to their security requirements as a >>government related company, they were instructed to disable 'DirectSend' >>on their Outlook 365 service for their domain, to prevent third parties >>to fake their envelope sender. Yes exactly. Thats because, Microsoft 365 doesn't require authentication unless you are RELAYING email. And Microsoft 365 to Microsoft 365 is still internal mail. So you could spoof a email by directly sending to a Microsoft 365 server, which then sends to another Microsoft 365 server, as those mails never leave MS premises. >>Aehm, this is what SPF is already doing - in a correct way - why does >>this DirectSend setting override SPF which would allow the envelope >>sender from our ip range? NO! SPF don't handle local policies. Imagine whats happens inside MS premises. Of course, its a server that would be called like 10.0.0.6 that would mail to a server called 10.5.6.10 Since both customers are MS customers, theres no need to route the traffic outside Microsoft premises. How would that be handled in SPF? And why should internal servers have to ask external servers for a policy when sending internally? This is why Microsoft invented the "DirectSend" , which was invented in 2016, to facilitate mailing between Microsoft servers without having to rely on external communication. The feature got misused, why they added the option to disable it for the sender domain, which means, a Microsoft server will not accept a non-authenticated mail that was sent from a Microsoft server to a Microsoft server. Meaning the sender has to be authenticated with SMTP Auth to send. >>So am I getting this correctly? Microsoft does not rely on SPF anymore >>but has invented an alternative called DirectSend which is not IPv6 >>compatible? OF COURSE NOT! Its not about "not relying on SPF anymore", but its about internal communication. You can't validate SPF on a mail that is sent from 10.0.0.6 til 10.5.6.10 Micrsooft still relies on SPF from external mail, but its when a Microsoft server sends to another Microsoft server, where the DirectSend setting applies. The second Microsoft Server that receives the mail from the first Microsoft Server can't verify SPF on internal mail, why it then looks up that server's "DirectSend" setting instead. If the original sender's IP is not in DirectSend and the SMTP user is not authenticated, then mail is rejected. So think "DirectSend" as some sort of local ACL for local servers on a local network talking to each other. Suggestion: Have your customers set up a mail account instead, and use smarthost with locked sender adress for each customer with specified user account and password. Then it will always work past DirectSend. Best regards, Sebastian Nielsen _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
