DMARC records are a concoction of various mechanisms or DMARC tags that communicate specific instructions to email receiving servers during mail transfer. Each of these DMARC tags contains a value that is defined by the domain owner. Today we are going to discuss what are DMARC tags and what each of them stand for. 

Here are all the available DMARC tags that a domain owner can specify in their DMARC record:

DMARC Tag Type Default value What it means
v mandatory The v tag represents the DMARC protocol version and always has the value v=DMARC1 
pct optional 100 This tag represents the percentage of emails to which the policy mode is applicable. Read more about DMARC pct tag
p mandatory This tag addresses the DMARC policy mode. You can select from reject, quarantine, and none. Learn more about what is DMARC policy to gain clarity on which mode to select for your domain. 
sp optional The policy mode configured for your main domain(p) Specifying the subdomain policy, the sp tag is configured to define a policy mode for your subdomains. Learn more about DMARC sp tag to understand when you should configure it. 
rua Optional but recommended The rua tag is an optional DMARC tag that specifies the email address or web server wherein reporting organizations are to send their DMARC aggregate rua data

Example: rua=mailto:[email protected];

ruf Optional but recommended Similarly, the ruf mechanism specifies the address to which the DMARC forensic ruf report is to be sent. Currently, not every reporting organization sends forensic data. 

Example: ruf=mailto:[email protected]

fo optional 0 The fo tag caters to the available failure/forensic reporting options domain owners can choose from. If you have not enabled ruf for your domain, you can ignore this. 

The available options to choose from are: 

0:  a DMARC failure/forensic report is sent to you if your email fails both SPF and DKIM alignment

1:  a DMARC failure/forensic report is sent to your when your email fails either SPF or DKIM alignment

d: a DKIM failure report is sent if the email’s DKIM signature fails validation, regardless of the alignment

s: a SPF failure report is sent if the email fails SPF evaluation, regardless of the alignment.

aspf optional This DMARC tag stands for the SPF alignment mode. The value can be either strict(s) or relaxed(r)
adkim optional Similarly, the adkim DMARC tag stands for the DKIM alignment mode, the value of which can be either strict(s) or relaxed(r) 
rf optional afrf The DMARC rf tag specifies the various formats for Forensic reporting.
ri optional 86400 The ri tag addresses the time interval in seconds between two consecutive aggregate reports sent by the reporting organization to the domain owner.

To create a record for DMARC instantly, use our free DMARC generator tool. Alternatively, if you have an existing record, check its validity by conducting a DMARC lookup

Sign up today for a free DMARC trial to gain expert advice on how you protect your domain from spoofers. 

If you as a domain owner want to specify what to do with an email that fails authentication, DMARC records can help you with that. A company can publish a text record in the DNS and specify what they want to happen to emails that fail source alignment by determining whether to deliver it, quarantine it, or even outright reject it. The DMARC pct tag is part of this record and tells an email receiver what percentage of messages under this policy will be affected.

What does pct mean in DMARC?

A TXT record for any email authentication protocol contains a bunch of mechanisms or tags that signify instructions dedicated to the email receiving servers. In a DMARC record, pct is an acronym for percentage which is included to address the percentage of emails that the DMARC policy defined by the domain owner is applied to.

Why do you need the DMARC pct tag?

The pct tag is an oft-overlooked, but nevertheless effective way to set up and test your domain’s DMARC policies. A DMARC record with a percentage tag looks something like the following: 

v=DMARC1; p=reject; pct=100; rua=mailto:[email protected];

In the DMARC DNS record shown above, the percentage of emails for which the DMARC reject policy is applicable is 100%. 

The time that it takes for a domain to go from not using DMARC at all, to using the most restrictive settings is a ramp-up period. This is intended to give domains time to become comfortable with their new settings. For some businesses, this could take a few months. It’s possible for domains to do an instant upgrade, but this is uncommon due to the risk of higher errors or complaints. The pct tag was designed as a way to gradually enforce DMARC policies to cut down on the roll-out period for online businesses. The intent is to be able to deploy it for a smaller batch of emails first before deploying it fully to the whole mail stream like in the case shown below: 

v=DMARC1; p=reject; pct=50; rua=mailto:[email protected];

In this DMARC DNS record, the reject policy for DMARC applies to only 50% of the emails, while the other half of the volume is subjected to a quarantine policy for DMARC, which is the second strictest policy in line. 

What will happen if you don’t include a pct tag in your DMARC record?

While creating a DMARC record using a DMARC record generator, you might choose not to define a pct tag and leave that criterion empty. In this case, the default setting for pct is set to 100, which means that your defined policy will apply to all your emails. Hence, if you want to define a policy for all your emails, a simpler way to go about it would be to leave the pct criterion blank, like in this example: 

v=DMARC1; p=quarantine; rua=mailto:[email protected];

Warning: If you want an enforced policy for DMARC, do not publish a record with pct=0

The logic behind this is simple: if you want to define a reject or quarantine policy in your record, you essentially want the policy to be levied on your outbound emails. Setting your pct to 0 nullifies your effort as your policy is now applicable to zero emails. This is the same as having your policy mode set at p=none. 

Note: In order to protect your domain from spoofing attacks and stop any chances of your domain being impersonated by attackers, the ideal policy should be DMARC at p=reject; pct=100; 

Shift to DMARC enforcement safely by starting your DMARC journey with PowerDMARC. Take a free DMARC trial today!

The “sp” attribute is short for subdomain policy and is not currently a widely used attribute. It allows a domain to specify that a different DMARC record should be used for subdomains of the specified DNS domain. To keep things simple, we recommend that the ‘sp’ attribute be omitted from the organizational domain itself. This will lead to a fallback default policy that prevents spoofing on subdomains. It is important to remember that subdomain behavior is always determined by the overriding organizational policy. 

Subdomains inherit the parent domain’s policy unless explicitly overruled by a subdomain policy record. The ‘sp’ attribute can override this inheritance. If a subdomain has an explicit DMARC record, this record will take precedence over the DMARC policy for the parent domain, even if the subdomain uses the default setting of p=none. For example, if a DMARC policy is defined for priority ‘all’, the ‘sp’ element will influence DMARC processing on subdomains not covered by any specific policy.

Why do you need the DMARC sp tag?

If you have your DMARC record as: 

v=DMARC1; p=reject; sp=none; rua=mailto:[email protected];

In this case, while your root domain is protected against spoofing attacks, your subdomains even if you don’t use them to exchange information would still be vulnerable to impersonation attacks.

If you have your DMARC record as: 

v=DMARC1; p=none; sp=reject; rua=mailto:[email protected];

In this case, while you are not committing to a reject policy on the root domain that you use to send your emails, your inactive subdomains are still protected against impersonation. 

If you want your domain and subdomain policies to be the same, you can leave the sp tag criterion blank or disabled while creating a record, and your subdomains would automatically inherit the policy levied on the main domain. 

In case you are using our DMARC record generator tool for creating a DMARC record for your domain, you need to manually enable the subdomain policy button and define your desired policy, like shows below: 


After creating your DMARC record it is important to check the validity of your record using our DMARC record lookup tool to make sure that your record is error-free and valid. 

Start your DMARC journey with PowerDMARC to maximize your domain’s email security. Take your free DMARC trial today! 

Due to the threats lurking online, businesses must prove that they are legitimate by employing strong authentication methods. A common method is through DomainKeys Identified Mail (DKIM), an email authentication technology that uses encryption keys to verify the domain of the sender. DKIM along with SPF and DMARC has drastically improved the email security posture of organizations globally. 

Read more on what is DKIM

While configuring DKIM for your emails, one of the primary decisions you have to make is determining the DKIM key length. In this article, we will take you through the recommended key length for better protection and how to upgrade your keys in Exchange Online Powershell.

Importance of Upgrading your DKIM Key Length

Choosing the 1024 bit or 2048 bit is an important decision that must be made when choosing your DKIM key. For years, PKI (public key infrastructure) has used 1024 bit DKIM keys for their security. However, as technology is becoming more complex, hackers are working hard to find new methods to cripple security. Because of this, key lengths have become increasingly important.

As hackers continue to invent better ways to break DKIM keys. The length of the key is directly correlated with how hard it is to break the authentication. Using a 2048 bit key provides enhanced protection and improved security against current and future attacks, highlighting the importance of upgrading your bitness.

Manually Upgrading your DKIM keys in Exchange Online Powershell

  • Start off by connecting to Microsoft Office 365 PowerShell as the admin (Make sure your Powershell account is configured to run signed Powershell scripts)
  • In case DKIM is preconfigured, to upgrade your keys to 2048 bits run the following command on Powershell: 

Rotate-DkimSigningConfig -KeySize 2048 -Identity {Guid of the existing Signing Config}

  • In case you have not implemented DKIM previously, run the following command on Powershell: 

New-DkimSigningConfig -DomainName <Domain for which config is to be created> -KeySize 2048 -Enabled $true

  • Finally, to verify that you have successfully configured DKIM with an upgraded bitness of 2048 bits, run the following command:

Get-DkimSigningConfig -Identity <Domain for which the configuration was set> | Format-List

Note: Make sure you are connected to Powershell throughout the completion of the procedure. It can take up to 72 hours for the changes to be implemented. 

DKIM isn’t enough to protect your domain against spoofing and BEC. Upgrade your domain’s email security by configuring DMARC for office 365.

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 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 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, 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: *

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. 
  • 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!