DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It’s an outbound email security protocol that allows domain owners to take back control of their email identity by telling receiving inboxes to reject spoof emails.

DMARC stops bad actors from pretending to be you and sending phishing emails to your employees, customers, and supply chain. This authentication of an email’s origin with DMARC also greatly improves deliverability. 

The more companies and institutions enforce a DMARC policy of p=reject for their outbound email, the safer the email ecosystem becomes overall. This is because attackers and bad actors will have fewer domains to ride on the back of to carry out attacks. So as a result, more sensitive information is protected, industry requirements are met, more money is saved and fewer attacks are successful.

DMARC is an outbound security protocol, meaning it simultaneously protects recipients and your brand reputation from being exploited. It’s important to remember that bad actors who use your domain to trick people into opening emails aren’t doing so by chance, they’re piggybacking off the weight of your brand reputation and relying on it to encourage email opens. 

DMARC stops this exact domain impersonation, by telling recipient servers not to accept any emails which aren’t authenticated to have come from you. So, bad actors cannot use your domain to send phishing emails and carry out Business Email Compromise (BEC).

Aside from providing a strong email security posture, DMARC can offer some real business benefits too. Below are some of the key advantages of implementing DMARC.

DMARC provides reports showing most, if not all, emails that come from your organization’s domain. This contrasts with traditional cybersecurity solutions which only pick up inbound phishing emails. Without DMARC, organizations are not getting a complete picture of the number and scale of attacks against them.  

Phishing attacks that use exact impersonation can cause considerable reputational damage. Phishing scams attract negative press, with liability often attributed to the organization that has been impersonated. 

Paying fake invoices or completing wire transfers from emails impersonating a business’ CEO is common. 

BIMI (Brand Indicators for Message Identification) is a standard that enables your registered logo to be visible in the avatar slot of any DMARC authenticated emails you send, by using Verified Mark Certificates. BIMI increases your brand impressions, and research has found it has a significant positive impact on consumer trust, interaction, and purchasing decisions. Being DMARC compliant means you’re eligible to take advantage of this brand-enhancing reward.  

When DMARC is set up correctly at a policy of p=reject, senders signal to ISPs that they are actively taking measures to authenticate their emails and improve their domain security. This builds trust with ISPs, reducing the likelihood of legitimate emails being mistakenly marked as spam or phishing attempts.

Organizations that fail to take the necessary precautions to prevent email spoofing are likely to be considered less trustworthy. Customers may not trust emails that supposedly come from these organizations and could be deterred from using email to communicate with them, which can impact on those organizations’ ability to communicate effectively with their customers. By implementing DMARC, you’re putting a robust measure that confirms your organization’s identity in place 

Shadow IT refers to legacy systems or technology set up by various departments in a business to plug a gap in existing infrastructure, and it’s not always easy to identify or remove. DMARC gives you the visibility necessary to identify and resolve any outlying software or systems, meaning nothing will accidentally be sent out by these legacy systems. Implementing DMARC uncovers all the email services sending emails from your domain, whether you officially know about them or not.

DMARC helps organizations comply with email security recommendations made by global government bodies such as NIST, NCSC, and the European Commission.

The EU's revised Directive on Security of Network and Information Systems (NIS2 Directive) has dramatically increased the regulatory pressure on organizations to take proactive action against phishing through a DMARC policy of "reject.”

The NIS2 Directive is an EU regulation that establishes a high common level of cybersecurity across the EU. For 'Essential and Important Entities,' compliance with this directive is mandatory.

Although the text of the NIS2 Directive does not explicitly mention DMARC or a "reject" policy, several of its requirements are related to the principles that DMARC upholds, and the absence of a DMARC policy of "reject" could be considered to weaken compliance with as many as five of direct NIS2 requirements or principles. 

1. Security by Design and by Default: The NIS2 Directive requires ‘providers of public electronic communications networks or of publicly available electronic communications services’ to implement security by design and by default. As a global and well-accepted internet standard for the prevention of email domain impersonation, a DMARC policy of “reject” forms an important part of a security by design and by default strategy. 
2. Risk Management Measures: The NIS2 Directive requires 'Essential and Important Entities' to take appropriate and proportionate technical and organizational measures to manage the risks posed to the security of network and information systems. A DMARC "reject" policy aligns with this requirement as it is a key measure to manage the risk of email phishing and spoofing attacks, which can lead to the risks outlined in this document.
3. Supply Chain Security: The NIS2 Directive requires entities to ensure the security of their network and information systems, including those of their supply chain. A DMARC "reject" policy can help by ensuring that only authorized third-party vendors can send emails on behalf of the entity, which can help prevent phishing attacks that originate from compromised vendors as well as protect the third-party vendors themselves from becoming victims of attacks that impersonate an organization.
4. Incident Reporting: Entities must report incidents having a significant impact on the continuity of essential services. While DMARC itself is not a reporting mechanism for security incidents, the detailed aggregate and forensics reports it generates can help organizations identify and respond to security incidents related to email spoofing.
5. Resilience: Entities are required to take measures to ensure the resilience of their systems and networks. A DMARC "reject" policy contributes to this by protecting the organization's email communication system, a critical part of its network, from being misused by unauthorized senders.

The Digital Operational Resilience Act (DORA) is a regulatory framework by the European Union aimed at ensuring the digital operational resilience of the financial sector. It seeks to establish a stringent, harmonized set of rules for digital operational resilience, including areas such as ICT risk management, incident reporting, digital operational resilience testing, and more. 

Even if an organization is not classified as a financial institution, DORA defines criticality thresholds for services provided to financial institutions. If an organization is a direct service provider to a financial institution and its services meet these thresholds, then the company is subject to DORA. Furthermore, it is likely that under DORA, these financial institutions push more stringent security controls onto their providers, including DMARC with a policy of “reject”.

While DORA does not go into specific technical detail, it does press three relevant aspects for DMARC at a policy of “reject”:

1. ​​ICT Risk Management: One of DORA's key aspects is to ensure effective ICT risk management. Implementing a DMARC "reject" policy directly contributes to this by preventing phishing attacks, email spoofing, and other email-based threats. This enhances the security of the ICT ecosystem, aligning with DORA's objectives.
2. Third-Party Risk: One of DORA's key aspects is to ensure effective ICT risk management. Implementing a DMARC "reject" policy directly contributes to this by preventing phishing attacks, email spoofing, and other email-based threats. This enhances the security of the ICT ecosystem, aligning with DORA's objectives.
3. Operational Resilience: DORA places a strong emphasis on the operational resilience of financial services providers. A DMARC "reject" policy can help enhance operational resilience by ensuring the integrity and authenticity of email communications, reducing the risk of disruptive incidents caused by phishing or other email-based attacks.

General Data Protection Regulation (GDPR) came into force in May 2018, requiring you to have Data Processing Agreements (DPAs) with every cloud service provider that handles EU consumer data on your behalf. With DMARC, if a cloud service provider does send emails using your company’s domain name in the ‘From’ field, then DMARC will reveal them to you. While a DMARC "reject" policy is not explicitly required by GDPR.

DMARC has been widely adopted by most email receivers (including Google, Yahoo, and Microsoft), which means that most consumer inboxes are already protected.

In addition, since February 2024, Google and Yahoo have introduced new email requirements for bulk senders (those who send more than 5,000 emails a day). These requirements stipulate that you:

• Send from a domain with a DMARC policy of at least p=none
• Set up one-click unsubscribe for recipients of promotional mail
• Keep spam rates under 0.10%

Those who fail to meet these requirements will see Google and Yahoo limiting sending rates or marking legitimate messages as spam. To find out more, visit our informational Google and Yahoo page.

DMARC works using the existing security protocols SPF and DKIM. Your SPF record is a whitelist of IP addresses you’ve authorized to send emails using your domain. DKIM acts like a digital signature, letting the recipient know you are who you say you are. When you first configure DMARC, you’ll spend some time classifying which senders you’ve authorized to send emails using your domain, and which you haven’t.

Both SPF and DKIM are essential to your email security setup, but neither prevents exact impersonation. While the protocols tell the recipient who the email is from, the recipient has no instruction to act on this knowledge, i.e. it doesn’t know what to do with your email. 

So, DMARC works by combining the results of SPF and DKIM to determine if your email is authentic and authorized. Then, the DMARC policy you have in place tells recipient servers what to do with it. 

Your DMARC policy is essentially the instruction you give to receiving servers, telling them what to do with emails that come from your domain. There are three policies to choose from:

• p=none: this policy tells the recipient server to accept all emails from your domain, regardless of whether they pass authentication or not.
• p=quarantine: this policy tells the recipient server to send any emails from your domain that fail authentication to spam.
• p=reject: this policy tells the recipient server to reject any emails coming from your domain that fail authentication.

Typically, when you implement DMARC for the first time you will start with a policy of p=none. This policy means that you are in reporting-only mode and you don't want any policy to be applied to your emails if they fail DMARC. During this stage you are simply gaining visibility into how your domain is being used around the world and what services are sending emails on your behalf. At this stage you simply identify your legitimate sending services and configure each one with SPF and DKIM so that they send DMARC compliant emails.

Once you are confident that your sending services are fully configured you can change your DMARC policy from p=none; to p=quarantine. This means that from this point on any emails that fail DMARC will have this policy applied to them, which means that usually they will be sent to the spam folder of the recipient.

If you do not encounter any issues during the p=quarantine; stage and only spoofing emails are being quarantined you can change the policy once more from p=quarantine to p=reject. At p=reject, you are telling recipients to reject any emails that fail DMARC. This means that end recipients will never receive the emails as they will simply be rejected at the SMTP level. This is the strongest level of protection which means that no one will be able to spoof your domain. Any emails that do not originate from your legitimate sending services will be rejected as they will fail DMARC. 

To learn more about the technical ins and outs of DMARC, visit our dedicated DMARC chapter in our Technical Configuration Guide.