DMARC is a standard email authentication protocol that when configured on top of existing SPF and DKIM records helps you in confirming whether either or both of the authentication checks have failed. Let’s say someone sends an email on behalf of your company and it fails DMARC, meaning you can take an authoritative action. DMARC has been designed to stop spam and phishing in its tracks by helping businesses deal with email security. One of the main goals is to help companies protect their brands and maintain their reputation. DMARC protects emails in transit and helps prevent spoofing and phishing attacks by rejecting messages that don’t meet certain standards. Mail servers can also report messages they receive from other mail servers to help the sender fix any problems.

Protecting your emails is important for keeping your customers safe from cybercriminals who might steal their personal information. In this blog post, we’ll explain the importance of DMARC and what you can do to implement it correctly for your domain.

Why should you use DMARC?

If you are still unsure about whether you should be using DMARC, let’s count down a few benefits that it provides:

  • DMARC is about email security and deliverability. It provides robust authentication reporting, minimizes phishing, and reduces false positives.
  • Increase deliverability and reduce bouncing
  • Receive comprehensive reports of how messages are authenticated
  • The DMARC protocol helps identify spammers and prevents bogus messages from reaching inboxes
  • DMARC helps reduce the chances of your emails being marked or flagged as spam
  • Gives you better visibility and authority over your domains and email channels

Who can use DMARC?

DMARC is supported by Microsoft Office 365, Google Workspace, and other popular cloud-based solutions. Since 2010, DMARC has been a part of the email authentication process. Its aim was to make it more difficult for cybercriminals to send spam emails from a valid address, helping to combat the epidemic of phishing attacks. Domain owners of small businesses, as well as enterprises, are encouraged by industry experts to create a DMARC record to provide instructions for how their email domain is to be protected. This in turn helps protect their brand reputation and identity. 

How to establish your domain’s DMARC record? 

Steps to configure your domain with email authentication protocols are as follows: 

  • Create an SPF record and check it using an SPF checker to make sure the record is functional and devoid of possible syntactical errors
  • Enable DKIM authentication for your domain
  • Finally set up your domain with DMARC and enable DMARC reporting by configuring our DMARC report analyzer free

DMARC has not only gained substantial importance in recent years but some companies are striving towards making it mandatory for their employees so as to prevent the loss of sensitive data and resources. Hence, it is time that you took into consideration its various benefits and shifted towards a safer email experience with DMARC. 

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