The long-awaited roll-out is finally here! Microsoft is sending DMARC RUA aggregate reports to their users and chances are you may have not noticed it. Microsoft DMARC aggregate reports are sent from the following email address: [email protected]. The raw Microsoft DMARC aggregate file is sent in standard XML format. Microsoft has finally embraced DMARC reporting, which essentially means that now Hotmail, Outlook, Live, and msn.com users will be able to enjoy the various benefits of Microsoft DMARC aggregate data.

Processing Microsoft DMARC Aggregate Data

PowerDMARC report analyzer parses the Microsoft DMARC aggregate data into an organized format that would aid you in processing it more efficiently.  

To help users avail of the benefits of aggregate report data sent by Microsoft, PowerDMARC’s DMARC report analyzer has been preconfigured to receive their reports directly on the platform. All that users need to do is add their domains on the PowerDMARC platform along with configuring the DMARC DNS record, while we process and present the reports in an easy and understandable way. Here you will find:

  • DMARC aggregate data sent from Hotmail, Outlook, Live,  and msn.com recipient addresses parsed from the raw XML file format into simple and readable information organized into tables
  • PowerDMARC is preconfigured to bypass RFC violations, enabling us to receive and parse your DMARC data sent by Microsoft servers without you having to worry about it
  • Register multiple domains, monitor your email channels and make DNS changes directly from the dashboard with actionable buttons at your fingertips
  • Filter results into assorted categories such as per result, per sending source, per organization, per country, geolocation, and  detailed stats or search results per domain on the search bar
  • Get deeper insights into the performance of your emails, and quickly pick up on attempts at domain spoofing, impersonation, or fake emails being sent using your Microsoft business domains. You will also be able to analyze any SPF, DKIM failures from your sending sources.

Displayed above is a screenshot of our DMARC aggregate reports per organization displaying DMARC RUA data sent from Microsoft.

Issues you might be facing while handling Microsoft DMARC Aggregate Reports on your own

Microsoft DMARC Aggregate Emails are not RFC-Compliant

The primary issue that users have been facing with these emails containing reports being sent by Microsoft is that they do not conform to the RFC specifications for internet emails. While RFC 5322 chapter 2.1.1 clearly states that a line of characters must not exceed 78 characters, the BASE64 attachment data in these Microsoft DMARC aggregate emails is a continuous line without proper line breaks that exceeds the 78 character limit. The resultant RFC violation is the reason why most of these emails are landing up in the user’s rejection log instead of being delivered to their inbox. 

Raw XML files are hard to read

Much like the DMARC data sent by all reporting organizations, the raw RUA file is in extensible markup language (XML) that is difficult to read and understand.

Prerequisites for Receiving Microsoft DMARC RUA

To receive aggregate reports for your domains on outlook.com, you need to ensure that you have a valid PowerDMARC record published on your DNS, along with a defined DMARC policy. Reporting organizations will then send aggregate report data to your specified web server or email address. This will help you gain visibility and DMARC compliance on your third-party email vendors which you otherwise have no control over. 

Protect your domains on Microsoft Office365 and others by starting your email authentication journey today. Get on board with a free DMARC trial or schedule a DMARC demo, and explore the benefits of implementing a robust email security posture at your organization!

In case you have come across the “MTA-STS policy is missing: STSFetchResult.NONE ” command while using online tools, you have come to the right place. Today we are going to discuss how to fix this error message and get rid of it by incorporating an MTA-STS policy for your domain. 

Simple Mail Transfer Protocol, aka SMTP, is the standard email transfer protocol used by a majority of email service providers. It isn’t an alien concept that SMTP has been facing security challenges since the dawn of time, challenges that they haven’t been able to come up with as of yet. This is because, in order to make the emails backward compatible, SMTP introduced opportunistic encryption in the form of a STARTTLS command.  This essentially means, in case an encrypted connection cannot be negotiated between two communicating SMTP servers, the connection gets rolled back to an unencrypted one, and messages are sent in cleartext. 

This makes emails transferred via SMTP vulnerable to pervasive monitoring and cyber eavesdropping attacks like Man-in-the-middle. This is risky for both the sender and the receiver and can lead to the breach of sensitive data. This is where MTA-STS swoops in and makes TLS encryption mandatory in SMTP to stop emails from being delivered over unsecured connections. 

What is an MTA-STS Policy?

In order to improve your SMTP email security and make the most out of authentication protocols like MTA-STS, the sending server should have support for the protocol and the email receiving server should have an MTA-STS policy defined in their DNS. An enforced policy mode is also encouraged to further amplify security standards. The MTA-STS policy defines the email servers using MTA-STS in the receiver’s domain. 

In order to enable MTA-STS for your domain as the email receiver, you need to host an MTA-STS policy file in your DNS. This allows external email senders to send emails to your domain that are authenticated and TLS encrypted with an updated version of TLS (1.2 or higher). 

Not having a published or updated policy file for your domain can be the primary reason for coming across error messages like “MTA-STS policy is missing: STSFetchResult.NONE”, implying that the sender’s server couldn’t fetch the MTA-STS policy file when it queried the receiver’s DNS, finding it to be missing.

Prerequisites for MTA-STS:

Email servers for which MTA-STS will be enabled should be using a TLS version of 1.2 or more, and should have TLS certificates in place that adhere to current RFC standards and specifications, are not expired, and server certificates that are signed by a trusted root certificate authority.

Steps to Fix “MTA-STS Policy is Missing”

1. Creating and publishing an MTA-STS DNS TXT record 

The first step is to create an MTA-STS record for your domain. You can create a record instantly using an MTA-STS record generator, providing you with a custom-tailored DNS record for your domain. 

2. Defining an MTA-STS policy mode

MTA-STS offers two policy modes for users to work with.

  • Testing mode: This mode is ideal for beginners who have not configured the protocol before. The MTA-STS testing mode allows you to receive SMTP TLS reports on problems in MTA-STS policies, issues in establishing encrypted SMTP connections, or failure in email delivery. This helps you respond to existing security issues pertaining to your domains and servers without enforcing TLS encryption.
  • Enforce mode: While you still receive your TLS reports, in course of time it is optimal for users to enforce their MTA-STS policy to make encryption mandatory while receiving emails using SMTP. This prevents messages from being changed or tampered with while in transit.

3. Creating the MTA-STS policy file

The next step is to host MTA-STS policy files for your domains. Note that while the contents of every file can be the same, it is mandatory to host policies separately for separate domains, and a single domain can have only a single MTA-STS policy file. Multiple MTA-STS policy files hosted for a single domain can lead to protocol misconfigurations. 

The standard format for an MTA-STS policy file is given below: 

File name: mta-sts.txt

Maximum file size: 64 KB

version: STSv1

mode: testing

mx: mail.yourdomain.com

mx: *.yourdomain.com

max_age: 806400 

Note: The policy file displayed above is simply an example.

4. Publishing Your MTA-STS policy file

Next, you have to publish your MTA-STS policy file on a public web server that is accessible to external servers. Make sure the server you host your file on supports HTTPS or SSL. The procedure for this is simple. Assuming that your domain is preconfigured with a public web server:

  • Add a subdomain to your existing domain that should begin with the text: mta-sts (e.g. mta-sts.domain.com) 
  • Your policy file will point to this subdomain that you created and has to be stored in a .well-known directory
  • The URL for the policy file is added to the DNS entry while publishing your MTA-STS DNS record so that the server can query the DNS to fetch the policy file during email transfer

5. Activate MTA-STS and TLS-RPT

Finally, you need to publish your MTA-STS and TLS-RPT DNS records in your domain’s DNS, using TXT as the resource type, placed on two separate subdomains (_smtp._tls and _mta-sts). This will allow only TLS encrypted messages to reach your inbox, that are verified and untampered. Furthermore, you will receive daily reports on delivery and encryption issues on an email address or web server configured by you, from external servers.  

You can verify the validity of your DNS records by performing an MTA-STS record lookup after your record is published and live.  

Note: On every occasion that you make alterations to the contents of your MTA-STS policy files, you must update it both on the public web server you are hosting your file on, as well as the DNS entry that contains your policy URL. The same holds true for every time you update or add to your domains or servers. 

How can Hosted MTA-STS Services Help in Resolving “MTA-STS Policy is Missing”?

Manual implementation of MTA-STS can be arduous and challenging and leave room for errors. PowerDMARC’s hosted MTA-STS services help catapult the process for domain owners, making protocol deployment effortless and speedy. You can: 

  • Publish your CNAME records for MTA-STS with a few clicks
  • Outsource the hard work involved in maintaining and hosting MTA-STS policy files and web servers
  • Change your policy mode whenever you wish to, directly from your custom-tailored dashboard, without having to access your DNS
  • We display SMTP TLS report JSON files in an organized and human-readable format that is convenient and comprehensible for technical and non-technical people alike

The best thing? We are RFC-compliant and support the latest TLS standards. This helps you get started with error-free MTA-STS configuration for your domain, and enjoy its benefits while leaving the hassles and complexities for us to handle on your behalf! 

Hope this article helped you get rid of the “MTA-STS policy is missing: STSFetchResult.NONE” prompt, and in configuring the protocols properly for your domain to mitigate the loopholes and challenges in SMTP security. 

Enable MTA-STS for your emails today by taking a free email authentication DMARC trial, to improve your defenses against MITM and other cyber eavesdropping attacks!