Feedback by UserVoice

Michael K

My feedback

  1. 2,896 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Michael K supported this idea  · 
  2. 64 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    working on it  ·  3 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Michael K commented  · 

    There are a number of changes that could be included under this suggestion:
    1. Support enforcing MTA-STS for mail being sent from Office 365 to Third Party Domains.
    2. Permit Office 365 users to publish an MTA-STS policy for their own domains.

    I have being publishing this MTA-STS policy since September 2018 without issue.

    version: STSv1
    mode: testing
    mx: <mydomain>.mail.protection.outlook.com
    max_age: 86400

    Confirmation from Microsoft that the certificates will always be *.mail.protection.outlook.com, and some brief documentation about MTA-STS would enable users to turn a similar policy on immediately and without significant (or any) changes on Microsofts side.

    I do not see any benefit in using Policy Delegation (https://tools.ietf.org/html/rfc8461#section-8.2) unless the certificate domain is expected to change. Operationally, having Microsoft generate certificates for mta-sts.<my domain> is going to be painful for everybody, and given that it was never done for Autodiscovery, Sharepoint, etc. makes me believe that is is not planned for MTA-STS.

    So permitting MTA-STS policies to be published should be quick win on the second element. As Microsoft were one of the authors of the RFC I'm surprised it has not been implemented yet.

  3. 2,023 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    An error occurred while saving the comment
    Michael K commented  · 

    This requires DNSSEC to be enabled on the outlook.com domain, or to create a second secure domain, and migrate customers MX records to the second one. I cannot see the risk in the first, but if Microsoft are worried about a breaking change, then option 2 gives customers the option to secure their email environment.

Feedback and Knowledge Base