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.

  • Closely related, to the point of possibly being a duplicate: security.stackexchange.com/questions/185898/…
    – IMSoP
    Commented Jun 13, 2019 at 15:28
  • Indeed, the question is similar, except the other one was not focused on O365
    – Ixiliae
    Commented Jun 14, 2019 at 7:34
  • Right, but if you rephrased the question as "Does Microsoft properly implement access control when you pay them for cloud services?" it would probably be closed as off-topic, because a) only Microsoft could answer; and b) any answer other than "yes" would be a huge scandal.
    – IMSoP
    Commented Jun 14, 2019 at 9:08

3 Answers 3


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.


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.

  • Thanks a lot. My question was indeed mostly about the internal checks that Microsoft may have set up. As for the DKIM, it by default setup for Office365, without the company publishing its DKIM record ? How would that work if the check is made on the TXT dns records of the company's domain ? I understand that would workd for company.onmicrosoft.com domains, but not for company.com
    – Ixiliae
    Commented Jun 11, 2019 at 10:12
  • O365 might have published it for you. You can try a DKIM checker and look up your domain. What any one hosting company does internally is entirely up to them. and for O365, the options change based on the level of protection you buy. If you are specifically concerned about O365 and want details, you will need to contact their support.
    – schroeder
    Commented Jun 11, 2019 at 10:30
  • I contacted their support and even some internal contact at Microsoft, which were of absolutely no help on the matter - their answers were completely out of the context. My goal was to determine if someone with only an SPF published was at a "higher risk" of being spoofed than someone without SPF in the case of tenants like O365
    – Ixiliae
    Commented Jun 11, 2019 at 11:48
  • There is no higher risk of being spoofed with SPF. It just offers no protection in this case.
    – schroeder
    Commented Jun 11, 2019 at 11:51
  • 1
    That's not a higher risk of spoofing, that's a higher risk of not understanding the limitations of this one control.
    – schroeder
    Commented Jun 11, 2019 at 14:42

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.

  • This is exactly what I was trying to assess here : if Microsoft was actually performing those checks. The problem being that I have not been able to reach to anyone that has a definite answer, and that I do not have in my possession a test tenant allowing me to try that out. Thank you for your answer.
    – Ixiliae
    Commented Jun 13, 2019 at 8:12
  • I think you're unlikely to get a satisfactory answer, because you're basically asking them if they're doing their job, like asking McDonald's if their burgers are safe to eat. This isn't really about SPF, it's just basic account security: if you log in with a particular username, you should only be able to do things as that user. If you don't trust Microsoft to perform basic security, use a service you do trust.
    – IMSoP
    Commented Jun 13, 2019 at 8:42
  • I do think they perform this access control - I would just need an official response for clients I have been working with.
    – Ixiliae
    Commented Jun 13, 2019 at 11:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .