The Complete Guide to DMARC: From Setup to Full Enforcement

If you send email from your business domain — whether it is marketing campaigns, invoices, or day-to-day communication — you need DMARC. Without it, anyone can send email pretending to be you. Your customers, vendors, and partners have no reliable way to tell the difference between a legitimate message from your team and a phishing attack using your domain name.

DMARC fixes that problem. It gives you control over who can send email as your domain and tells receiving mail servers what to do when someone unauthorized tries.

This guide walks you through the entire DMARC journey, from understanding the basics to reaching full enforcement. Whether you are starting from scratch or trying to tighten an existing setup, you will find what you need here.

What Is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication protocol that builds on two existing standards — SPF and DKIM — to protect your domain from unauthorized use.

In plain terms, DMARC lets you publish a policy in your DNS records that tells the world:

1. How to verify that email claiming to come from your domain is actually legitimate.
2. What to do with email that fails verification (let it through, quarantine it, or reject it outright).
3. Where to send reports about who is sending email using your domain.

DMARC was created in 2012 by a coalition of major email providers and senders, including Google, Microsoft, Yahoo, and PayPal. Today it is widely supported across virtually every major email platform.

For a deeper look at the fundamentals, read our article on what DMARC is and why it matters.

Why You Need DMARC

Many business owners assume email security is something only large enterprises need to worry about. That is a dangerous misconception. Small and mid-sized businesses are actually more frequently targeted by email spoofing attacks precisely because attackers know they are less likely to have protections in place.

Protection Against Email Spoofing

Email spoofing — where an attacker forges the "From" address to impersonate your domain — is one of the most common tactics in phishing attacks. Without DMARC, there is nothing stopping a bad actor from sending an email that appears to come from billing@yourdomain.com and tricking your customers into wiring money or sharing credentials.

DMARC gives receiving mail servers the information they need to detect and block these forged messages before they reach anyone's inbox. Learn more about how DMARC prevents email spoofing.

Better Email Deliverability

DMARC does not just block bad email — it helps your legitimate email get delivered. Major inbox providers like Google and Microsoft use DMARC as a trust signal. Domains with a properly configured DMARC policy see better inbox placement rates because providers can confidently verify the email is authentic.

If you have ever wondered why your marketing emails or transactional messages end up in spam, a missing or misconfigured DMARC record could be part of the problem. Read more about DMARC and email deliverability.

Compliance Requirements

Increasingly, DMARC is not optional. Google and Yahoo began requiring DMARC for bulk senders in early 2024. PCI DSS 4.0 now includes DMARC requirements. Many industries have their own compliance mandates that reference email authentication.

If you are unsure whether DMARC applies to your situation, check out Do I Need DMARC? for a straightforward breakdown by business type and size.

How DMARC Works

DMARC does not work alone. It sits on top of two other email authentication protocols — SPF and DKIM — and ties them together with a concept called alignment.

SPF (Sender Policy Framework)

SPF lets you publish a list of servers authorized to send email for your domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to see if the sending server is on the approved list. If it is not, SPF fails.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to your outgoing emails. The receiving server can verify this signature against a public key published in your DNS. If the signature checks out, the server knows the message was not tampered with in transit and was sent by an authorized party.

How DMARC Brings Them Together

Here is where DMARC adds its value. SPF and DKIM on their own have a gap: they authenticate the sending server and the message integrity, but they do not necessarily verify the "From" address that the recipient actually sees.

DMARC introduces alignment — it checks that the domain authenticated by SPF or DKIM matches the domain in the visible "From" header. The message must pass at least one of these checks (SPF or DKIM) and the passing check must be aligned with the "From" domain.

For a deeper dive into how alignment works and the difference between relaxed and strict modes, read DMARC Alignment Explained. For a side-by-side comparison of all three protocols, see SPF vs. DKIM vs. DMARC.

Creating Your First DMARC Record

A DMARC record is a TXT record you add to your domain's DNS. It tells receiving mail servers your DMARC policy and preferences. The record is published at a specific subdomain: _dmarc.yourdomain.com.

DMARC Record Structure

Every DMARC record starts with a version tag and a policy tag. Here is what a basic record looks like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;

Let's break that down:

• v=DMARC1 — The version tag. Always DMARC1.
• p=none — The policy. This tells receiving servers what to do with emails that fail DMARC. none means take no action (just report).
• rua= — The address where you want to receive aggregate reports about email sent using your domain.

There are additional tags you can use to fine-tune your record, including settings for subdomain policies, alignment modes, reporting formats, and the percentage of messages to apply the policy to. For a full breakdown of every available tag, see DMARC Record Syntax and Tags.

Use the DMARC Record Generator

You do not need to write your DMARC record by hand. Our free DMARC record generator builds a valid record for you based on your preferences. Just enter your domain and choose your settings.

For a complete walkthrough of the process — from deciding your initial policy to adding the record in your DNS — read How to Create a DMARC Record.

DMARC Policy Levels

DMARC has three policy levels, and they represent a progression from monitoring to full enforcement. Understanding when and how to move between them is one of the most important parts of your DMARC journey.

p=none (Monitor Only)

This is the starting point. With a none policy, receiving servers will not take any action on emails that fail DMARC. They will, however, send you reports. This phase is about gathering data — finding out who is sending email using your domain, whether your legitimate senders are properly authenticated, and identifying any issues before you start enforcing.

Most organizations should spend at least two to four weeks in this phase, though it can take longer if you have many third-party senders to configure.

p=quarantine (Soft Enforcement)

Once you are confident that your legitimate email sources are properly authenticated, you can move to quarantine. This tells receiving servers to treat failing messages with suspicion — typically by routing them to the spam or junk folder instead of the inbox.

Quarantine is a good intermediate step because it protects your recipients from most spoofing attempts while giving you a safety net. If a legitimate sender was missed during the monitoring phase, their email lands in spam rather than being outright rejected.

p=reject (Full Enforcement)

This is the goal. With a reject policy, receiving servers will block emails that fail DMARC entirely. They never reach the recipient at all. This provides the strongest protection against spoofing and phishing.

Moving to reject requires confidence that all your legitimate email sources pass DMARC. The monitoring and quarantine phases are how you build that confidence.

For a detailed comparison of each policy level and guidance on when to move between them, read DMARC Policy Levels Explained. You can also see a head-to-head comparison at DMARC Quarantine vs. Reject.

Setting Up DMARC with Your Provider

The actual process of adding a DMARC record to your DNS varies depending on two things: your email provider and your DNS hosting provider.

Your email provider (Google Workspace, Microsoft 365, Zoho, etc.) determines how SPF and DKIM are configured. Each provider has its own SPF include values and DKIM setup process. Getting these right is essential because DMARC depends on SPF and DKIM passing and aligning.

Your DNS hosting provider (Cloudflare, GoDaddy, Namecheap, Route 53, etc.) is where you actually publish your DMARC, SPF, and DKIM records as TXT entries.

Because the steps differ significantly between providers, we have created dedicated guides for each:

• Email Provider DMARC Setup Guides — Step-by-step instructions for configuring SPF, DKIM, and DMARC with Google Workspace, Microsoft 365, and other popular email platforms.
• DNS Hosting DMARC Setup Guides — Instructions for adding DMARC records in Cloudflare, GoDaddy, Namecheap, and other DNS hosts.

Reading DMARC Reports

One of the most valuable features of DMARC is the reporting it provides. When you include an rua tag in your DMARC record, receiving mail servers send you aggregate reports about every email they process that claims to come from your domain.

What Aggregate Reports Tell You

DMARC aggregate reports are XML files sent daily (usually) by receiving mail servers. Each report covers a specific time period and includes:

• Sending IP addresses — Every server that sent email using your domain.
• Message volume — How many messages came from each source.
• Authentication results — Whether each source passed or failed SPF, DKIM, and DMARC.
• Alignment results — Whether the authenticated domains aligned with the "From" address.
• Policy applied — What action the receiving server took based on your DMARC policy.

This data is essential during the monitoring phase. It helps you identify all the legitimate services sending email on your behalf (your email provider, marketing platform, CRM, transactional email service, etc.) and verify that each one is properly authenticated before you move to enforcement.

Making Sense of the Data

Raw DMARC reports are XML files, and they are not designed to be human-friendly. Reading them directly is possible but tedious, especially if you receive reports from dozens or hundreds of receiving servers.

For practical guidance on interpreting these reports, see How to Read DMARC Reports. If you are dealing with a high volume of reports flooding your inbox, read Managing DMARC Report Emails for strategies to keep things under control.

Monitoring and Enforcement

Setting up DMARC is not a one-time task. Email infrastructure changes — you add new sending services, switch providers, update configurations. Each change can affect your DMARC alignment. Ongoing monitoring ensures you catch issues before they become problems.

The Path to Enforcement

Here is the recommended progression from initial setup to full enforcement:

For detailed guidance on each phase, read DMARC Monitoring: What to Track and When to Act. For a broader set of recommendations, see DMARC Best Practices.

Troubleshooting Common DMARC Issues

DMARC issues are common, especially during initial setup and when moving between policy levels. Most problems fall into a few predictable categories.

Authentication Failures

The most frequent issue is legitimate email failing DMARC. This usually happens because:

• A third-party sender (marketing platform, CRM, helpdesk tool) is not included in your SPF record.
• DKIM signing is not configured for a sending service.
• SPF or DKIM is passing but not aligned with the "From" domain.

Record Configuration Errors

Syntax errors in your DMARC record — typos, missing semicolons, invalid tag values — can cause the entire record to be ignored. Similarly, having multiple DMARC records published for the same domain will cause problems.

Email Forwarding

Email forwarding is one of the trickiest scenarios for DMARC. When an email is forwarded, it often breaks SPF because the forwarding server is not authorized to send for your domain. DKIM signatures can also break if the forwarding server modifies the message content. This is one of the primary use cases for ARC (Authenticated Received Chain), which we cover in the advanced topics section below.

Policy Not Enabled

If you have published a DMARC record but checks show your policy is not enabled, there could be a DNS propagation delay, a formatting issue with your record, or the record might be published at the wrong location in your DNS.

For step-by-step troubleshooting guides, see:

• DMARC Troubleshooting Guide — A comprehensive hub covering the most common issues and their solutions.
• DMARC Failure: How to Fix It — Specific guidance for diagnosing and resolving DMARC authentication failures.
• DMARC Policy Not Enabled: What It Means — What to check when your DMARC record is not being recognized.

DMARC and Compliance

DMARC is increasingly tied to regulatory and industry compliance requirements. What started as a voluntary best practice has become a formal requirement in multiple contexts.

PCI DSS 4.0

The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 introduced anti-phishing requirements that include DMARC. Organizations that process credit card payments are expected to implement DMARC as part of their security controls. The enforcement deadline for these requirements means businesses need to act now if they have not already.

For a detailed breakdown of what PCI DSS requires and how to meet it, read DMARC and PCI DSS Compliance.

Industry-Specific Requirements

Beyond PCI DSS, many industries have their own email authentication mandates:

• Financial services — Regulators in many jurisdictions expect email authentication as part of fraud prevention.
• Healthcare — Protecting patient communications from spoofing is a growing priority.
• Government — Many government agencies are required to implement DMARC at enforcement level.
• Education — Institutions handling student data and financial aid are increasingly expected to protect their email domains.

For guidance specific to your industry, see our DMARC Compliance by Industry hub.

Advanced Topics

Once you have DMARC at enforcement level on your primary domain, there are several additional areas worth considering.

Subdomain Policies

Your main DMARC policy covers your root domain, but what about subdomains? The sp tag in your DMARC record lets you set a separate policy for subdomains. This is important because attackers often target subdomains that are not actively used for email — domains like marketing.yourdomain.com or test.yourdomain.com — precisely because they are less likely to be protected.

A strong approach is to set sp=reject for subdomains that do not send email, even if your root domain is still at a lower policy level.

ARC (Authenticated Received Chain)

ARC is a protocol designed to solve the email forwarding problem. When an email is forwarded through a trusted intermediary (like a mailing list or forwarding service), ARC preserves the original authentication results so that the final receiving server can still validate the message, even though SPF and DKIM may have broken in transit.

ARC support is growing among major email providers and helps reduce false DMARC failures caused by legitimate forwarding.

BIMI (Brand Indicators for Message Identification)

BIMI lets you display your brand's logo next to your emails in supported inboxes. It requires a DMARC policy of quarantine or reject at 100% — so achieving full DMARC enforcement is a prerequisite. BIMI is a visible reward for doing DMARC right and helps your legitimate emails stand out.

MTA-STS and TLS Reporting

While not directly part of DMARC, MTA-STS (Mail Transfer Agent Strict Transport Security) complements your email authentication setup by enforcing encrypted connections between mail servers. Combined with TLS reporting (TLS-RPT), it gives you visibility into whether email in transit is being properly encrypted.

Ongoing Record Management

As your organization grows and your email ecosystem evolves, your DMARC, SPF, and DKIM records will need to be updated. SPF records in particular have a 10 DNS lookup limit that can be easy to exceed as you add sending services. Regularly auditing your records with tools like spfcreator.com and dmarcrecordchecker.com helps prevent issues before they affect delivery.

Getting Started

DMARC can feel complex, but the core concept is straightforward: tell the world which servers are allowed to send email as your domain, and what to do when someone else tries.

The hardest part is not the technical setup — it is the patience required to monitor, verify, and gradually tighten your policy. But the payoff is significant. With DMARC at full enforcement, your domain is protected from spoofing, your email deliverability improves, and you meet an expanding set of compliance requirements.

Here is what to do next:

1. Check your current status. Use dmarcrecordchecker.com to see if you already have a DMARC record published.
2. Generate a DMARC record. If you do not have one, use our free DMARC record generator to create one with a p=none policy.
3. Add it to your DNS. Follow the guide for your DNS hosting provider to publish the record.
4. Monitor your reports. Review your aggregate reports for two to four weeks to understand your email landscape.
5. Progress toward enforcement. Move through quarantine to reject as your confidence grows.

You do not have to do this alone. Use deliverabilitychecker.com to set up ongoing monitoring that alerts you when something breaks, so you can focus on running your business while your email stays protected.