SPF and Office 365 email accounts spoofing other Office 365 email accounts

Question

After an incident, I have a question which answer's I cannot find. I cannot provide the real headers as they come from a client.

Let’s consider a company which uses an Office365 tenant as mail server. Its domain is example.com, and mail addresses are [email protected]. Employees thus all have a [email protected] account.

The company has published the default Office365 SPF: v=spf1 include:spf.protection.outlook.com -all

The company does not have either a DKIM published nor a DMARC policy.

Would it be possible to connect with a random Outlook account ([email protected]) to smtp-mail.outlook.com or Outlook.office365.com with protocol SMTP, and then craft an email using [email protected]?

The SPF would pass as the mail is sent from the right servers. The question is more about Microsoft performing access control on emails sent through their SMTP servers.

This question would probably exist for other companies managing mails for you that also host public-accessible emails.

Answer 1

Would it be possible to connect with a random Outlook account ([email protected]) to smtp-mail.outlook.com or Outlook.office365.com with protocol SMTP, and then craft an email using [email protected]?

Generally not. By default, all SMTP connections to O365 must be authenticated first.

In the case of a domain having a non-authenticated SMTP connector set up, it would typically be restricted to accept mail from specific IP addresses only, i.e. ones that you trust to send email for your domain.

Third party email providers may handle authentication differently, and may in fact be susceptible to this type of spoofing.

Answer 2

SPF works well, but it has significant limitations. For multi-tenant email servers, if you specify their servers as an authorised sender, then anyone using that sender would also be authorised, unless the email service does internal checks to make sure that an email cannot be sent from its service to a domain it hosts. But that kind of checking is simply a business logic check to protect its customers and is up to each email hosting service.

For Office 365, specifically, they set up DKIM for the initial domain, which solves the problem you describe, at least on one level. If they sign emails with their own central signing process (indications are that they do), then even DKIM will not help because the spoofed header will be valid.

Answer 3

When you include any mail server in your SPF record, what you are specifying is that you trust that server to only send mail with your permission.

Consider the case where you run an SMTP server for a single domain, example.com, and you give out logins to that server to various users. You take on a student placement, and give them an address [email protected]. They discover that you have messed up the server's security, and they can write mail from [email protected] without it being rejected or rewritten. SPF cannot detect this abuse, because it only ties the domain to the server, and has no knowledge of users.

If you delegate SMTP services to a server that runs multiple domains, the situation is effectively the same: it is up to that server to determine which user is authorised to send from which domain (and which address on that domain). If Microsoft failed to do this with Office365, it would be considered a major security breach, but SPF would not detect it.

Note that the same applies to DKIM: the signature is generally added on a shared server, after the mail has been submitted by a client (Outlook, Thunderbird, etc) so you are trusting that server to only sign legitimate messages.

The only way you can remove this layer of trust is to sign or encrypt the message in the mail client, before sending it to any SMTP server (e.g. using GPG or S/MIME). However, support for this is far from universal, and you need a way to inform people that they should check messages against a particular public key, so it's not particularly useful for every-day spam prevention.