To protect your domain and online identity from fraudsters trying to pass off as you, you need to set up DMARC for your email domains. DMARC works by the cumulative email authentication efforts of SPF and DKIM protocols. Subsequently, DMARC users also benefit from receiving reports on delivery issues, authentication, and alignment failures for their emails. Learn more about what is DMARC here. 

If your DMARC aggregate report says “SPF alignment failed” let’s discuss what it means to have your SPF in alignment and how you can resolve this issue.

What is SPF alignment?

An email message is made up of several different headers. Each header contains information about certain attributes of an email message, including the date sent, where it was sent from, and who it was sent to. SPF deals with two types of email headers:

  • The <From:> header
  • The Return-Path header

When the domain in the From: header and the domain in the return-path header is a match for an email, SPF alignment passes for that email. However, when the two are not a match, it consequently fails. SPF alignment is an important criterion that decides whether an email message is legitimate or fake.

Shown above is an example where the From: header is in alignment (exactly matches) with the Return-path header (Mail From), hence SPF alignment would pass for this email.

Why Does SPF alignment fail?

Case 1: Your SPF alignment mode is set to strict

While the default SPF alignment mode is relaxed, setting a strict SPF alignment mode can lead to alignment failures if the return-path domain happens to be a subdomain of the root organizational domain, while the From: header incorporates the organizational domain. This is because for SPF to align in a strict mode, the domains in the two headers must be an exact match. However, for relaxed alignment, if the two domains share the same top-level domain, SPF alignment will pass.

Shown above is an example of a mail that shares the same top-level domain but the domain name isn’t an exact match ( the Mail From domain is a subdomain of the organizational domain In this case, if your SPF alignment mode is set to “relaxed”, your email will pass SPF alignment, however for a strict mode, it will fail the same. 

Case 2: Your domain has been spoofed

A very common reason for SPF alignment failures is domain spoofing. This is the phenomenon when a cybercriminal takes over your identity by forging your domain name or address to send emails to your receivers. While the From: domain still bears your identity, the Return-path header displays the original identity of the spoofer. If you have SPF authentication in place for your forged domain, the email inevitably fails alignment on the receiver’s side.

Fixing “SPF alignment failed”

To fix SPF alignment failures you can: 

  • Set your alignment mode to “relaxed” instead of “strict” 
  • Configure DMARC for your domain, atop SPF and DKIM, so that even if your email fails SPF header alignment and passes DKIM alignment, it passes DMARC and gets delivered to your recipient

Our DMARC report analyzer can help you gain 100% DMARC compliance on your outgoing emails and prevent spoofing attempts or alignment failures due to protocol misconfigurations. Enjoy a safer and reliable authentication experience by taking your free DMARC trial today!

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. Why is DMARC important? 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 why is DMARC important and what you can do to implement it correctly for your domain.

What is DMARC?

DMARC is an email authentication standard that helps to protect your organization from phishing attacks.

When you set up DMARC, it tells the world whether or not your emails are coming from you. This is called alignment. If your emails are aligned, it means that the domain is sending emails that are coming from your domain.

DMARC protects against this by setting up a system where you can specify what email domains are allowed to use your domain name in their “From” field. This way, if someone tries to send an email from a domain that isn’t on your whitelist, you can choose for it to be rejected by the receiving server before it even gets to your receiver’s inbox.

You can also use DMARC to monitor the abuse of your domain name by sending daily reports about any unauthorized emails sent with your domain in their From field. This is important because it helps you identify which messages are being sent without authorization and who might be sending them—which could be useful if there are any legal issues down the road

Why is DMARC important and 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 to better understand why is DMARC important:

  • 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 and 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 preserve their brand reputation and identity. 

How does DMARC protect your organization?

Email spoofing is when someone uses your company’s name to send emails in an attempt to scam or defraud people. Phishing emails are designed to look like official communications from someone you trust so that when you open them, you’ll be tricked into giving up information like passwords or credit card numbers.

Find the most recent statistics on phishing attacks here.

DMARC protects against these types of attacks because it lets recipients know if the email is legitimate or not. It also reports on any suspicious activity happening on your domain. DMARC helps minimize attacks by letting you set up policies that tell the world exactly how you want your emails authenticated and verified. If someone tries to send an email claiming to be from your company but doesn’t follow those policies, then DMARC will block that message before it reaches its destination thereby explaining why is DMARC important.

How to establish your domain’s DMARC record? 

DMARC is a policy that tells recipients of emails sent from your domain how to treat the messages they receive. The most basic level of protection requires that all emails sent from your domain be authenticated, so any unauthenticated messages are automatically rejected by the recipient. At the next level of protection, you can specify a policy for how to handle unauthenticated messages—for example, reporting them to you or rejecting them outright. You can also specify which addresses should be allowed to send mail on behalf of your domain (such as an address for customer service representatives), and which should not be allowed to do so.

By creating a DMARC record, you can establish a baseline of protection against phishing scams, but you’ll also get some very valuable information about how people are using email from your company—information that can help guide future decisions about what kinds of messages might be appropriate for various audiences.

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

In Conclusion

To conclude why is DMARC important, DMARC has not only gained substantial importance in recent years but some companies are striving toward 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. 

Types of DMARC Tags

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 is one of the DMARC tags representing 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 one of the optional DMARC tags that specify 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 tag 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 DMARC 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 tag stands for the SPF alignment mode. The value can be either strict(s) or relaxed(r)
adkim optional Similarly, the adkim 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.

If you don’t have a record in place yet, create a record for DMARC instantly, using 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. 

The DMARC pct tag is part of this record and tells an email receiver what percentage of messages under this policy will be affected. 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. 

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.