DMARC, short for Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol that tells receiving mail servers what to do when an email fails identity checks. It builds on two existing standards, SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), by adding a policy layer and a reporting mechanism. When a DMARC policy is set to p=reject, spoofed emails impersonating your domain get blocked outright before they ever reach an inbox. According to IBM’s 2025 Cost of a Data Breach Report, phishing was the initial attack vector in 16% of breaches, costing an average of $4.8 million per incident. That number alone should settle the debate about whether DMARC email security is optional.

Most business owners I talk to have heard of DMARC but have never actually set it up. They assume their email provider handles it. It doesn’t. Your domain is sitting there unprotected, and attackers know it.

What Is DMARC? Definition and Overview

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a published email authentication standard, defined under RFC 7489, that gives domain owners control over how unauthenticated email from their domain is handled by receiving mail servers.

Before DMARC existed, nothing stopped a criminal from sending an email that appeared to come from your domain. SPF and DKIM existed independently, but there was no mechanism to tell a receiver what to do if those checks failed. DMARC fills that gap.

A domain owner publishes a DMARC record as a DNS TXT record. That record tells the world: “If an email claims to be from my domain but fails authentication, here’s what I want you to do with it.” The options are monitor it, quarantine it, or reject it entirely.

DMARC also introduces reporting. Receiving servers send back data showing which emails passed or failed authentication, who sent them, and from which IP addresses. For a business owner, that’s gold. You can see exactly who is sending email on behalf of your domain, including senders you didn’t authorize.

Valid DMARC adoption grew to 52.1% of the top 1.8 million most-visited global domains in early 2026, according to EasyDMARC’s 2026 DMARC Adoption Report. That means nearly half of major domains are still unprotected. If your domain is in that half, attackers already know it.

How DMARC Works: Step-by-Step Breakdown

DMARC works by requiring that an incoming email passes either SPF or DKIM authentication, and that the authenticated domain aligns with the domain in the email’s From header, before the receiving server applies the domain owner’s stated DMARC policy.

That sounds technical. It isn’t complicated once you break it down.

The Five-Step Authentication Process

1. Email arrives at the receiving server. A sender claims the email comes from yourcompany.com.
2. The server runs an SPF check. It looks up the DNS TXT record for yourcompany.com and asks: “Is the sending IP address on the authorized list?” If yes, SPF passes.
3. The server runs a DKIM check. It looks for a cryptographic signature in the email header, then retrieves the matching public key from the sender’s DNS to verify the signature. If it matches, DKIM passes.
4. The server checks domain alignment. At least one of the authenticated domains (from SPF or DKIM) must align with the domain in the From header. This is where DMARC catches spoofing that SPF and DKIM alone would miss.
5. The server applies the DMARC policy. The receiving server fetches the DMARC record from the domain’s DNS and applies the p= policy: none, p=quarantine, or p=reject. It then sends a report back to the address specified in the DMARC record.

If either SPF or DKIM passes with proper alignment, DMARC passes. Both don’t need to pass. But if neither passes, DMARC fails and the policy kicks in.

This is the critical detail most guides skip: DMARC doesn’t just check authentication, it checks alignment. A phishing email can sometimes pass SPF on its own by using a different domain in the envelope. DMARC catches that mismatch.

DMARC, SPF, and DKIM: How They Work Together

DMARC requires both SPF and DKIM to be in place because it uses the results of both checks to make its final authentication decision, and each protocol protects a different part of the email delivery chain.

Think of SPF, DKIM, and DMARC as three layers of a security system. SPF is the guest list at the door. DKIM is the tamper-evident seal on the package. DMARC is the policy that decides what happens if either check fails, and the camera that records the outcome.

Sender Policy Framework (SPF) Explained

Sender Policy Framework (SPF) is a DNS-based protocol that lets a domain owner specify which mail servers are authorized to send email on behalf of that domain. The receiving server checks the sending IP against a list published in the domain’s DNS TXT record. If the IP isn’t listed, SPF fails.

SPF checks the envelope sender, not the From header the user sees. That distinction matters. Attackers can pass SPF using their own domain in the envelope while spoofing your brand name in the visible From field. That’s why SPF alone isn’t enough.

DomainKeys Identified Mail (DKIM) Explained

DomainKeys Identified Mail (DKIM) uses public-key cryptography to sign outgoing emails. The sending server adds a digital signature to each email header using a private key. The receiving server retrieves the corresponding public key from the sender’s DNS and verifies the signature. If the signature is valid, two things are confirmed: the email came from an authorized server, and its content wasn’t altered in transit.

DKIM survives email forwarding better than SPF does. When an email is forwarded, the sending IP changes, which can break SPF. The DKIM signature remains intact as long as the message body isn’t modified.

Where DMARC Sits in the Stack

DMARC ties SPF and DKIM together by introducing the alignment requirement and the policy enforcement layer. Without DMARC, a receiving server might note that SPF or DKIM failed and simply do nothing. DMARC instructs the server to quarantine or reject that email, and to report the outcome back to the domain owner.

SPF without DMARC gives you partial authentication. DKIM without DMARC gives you signing with no enforcement. DMARC without SPF and DKIM gives you a policy with nothing to enforce. All three together form a functioning email authentication system.

What Is a DMARC Record? Syntax and Structure

A DMARC record is a DNS TXT record published at the subdomain _dmarc.yourdomain.com that contains the domain owner’s authentication policy and reporting instructions in a structured tag-value format.

It always starts with v=DMARC1. Everything else is configurable. Here’s a real-world example of a DMARC record:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r;

Breaking Down the DMARC Record Tags

• v=DMARC1 — Version identifier. Always the first tag. Required.
• p= — Policy tag. Defines what to do with email that fails DMARC. Values: none, quarantine, or reject. Required.
• rua= — Aggregate report URI. The email address where aggregate DMARC reports are sent. Highly recommended.
• ruf= — Forensic report URI. The email address for failure (forensic) reports. Optional, not universally supported.
• pct= — Percentage of messages the policy applies to. Defaults to 100. Useful for gradual rollout when lowered.
• adkim= — DKIM alignment mode. r for relaxed, s for strict. Defaults to relaxed.
• aspf= — SPF alignment mode. r for relaxed, s for strict. Defaults to relaxed.
• sp= — Subdomain policy. Applies a separate policy to subdomains. If omitted, the parent policy applies.

To publish a DMARC record, you create a DNS TXT record at _dmarc.yourdomain.com with this string as the value. Most DNS management interfaces (in providers like Cloudflare or AWS Route 53) let you add TXT records through a simple form. Propagation usually takes under an hour.

Start with p=none while you’re still auditing your sending sources. It’s the monitoring-only mode. No emails get blocked. You just receive reports.

DMARC Policies: None, Quarantine, and Reject

DMARC defines three policy options that control what a receiving mail server does with email that fails the DMARC authentication check: p=none for monitoring only, p=quarantine to divert failing email to spam, and p=reject to block failing email entirely.

Choosing the wrong policy at the wrong time causes real problems. Jump straight to p=reject before you’ve audited your sending sources and you’ll block legitimate email from your own marketing platform or third-party CRM. That’s not a hypothetical. It happens regularly.

p=none: Monitor Without Blocking

With p=none, the receiving server applies no action to emails that fail DMARC. They’re delivered normally. But the DMARC reporting mechanism still runs, so you receive aggregate reports showing which emails passed and which failed. This is your starting point.

Use p=none for at least 30 days before moving to enforcement. During that window, review your aggregate reports. Identify every legitimate sending source: your email provider, your CRM, your marketing automation tool, your helpdesk software. Make sure each one is covered by SPF or DKIM.

p=quarantine: Route Failures to Spam

The p=quarantine DMARC policy tells receiving servers to deliver failing emails to the recipient’s spam or junk folder rather than the inbox. It’s the middle step between monitoring and full enforcement.

This is where most organizations should spend time before moving to p=reject. The pct= tag is useful here. Set pct=10initially and the policy only applies to 10% of failing messages. Increment it gradually: 25, 50, 75, then 100. That gives you a safety net if you missed a legitimate sender.

p=reject: Block Spoofed Email Entirely

The p=reject DMARC policy instructs receiving servers to reject emails that fail DMARC outright. They’re not delivered to spam. They don’t reach the recipient at all. This is the goal.

The impact of p=reject enforcement is measurable. Following DMARC enforcement on UK central government domains, over 80 million spoofed emails were blocked in a single 30-day period, according to the UK National Cyber Security Centre. That’s 80 million phishing attempts that never reached a government inbox.

Get to p=reject. Just don’t rush it. The rollout matters as much as the destination.

DMARC Domain Alignment: Strict vs. Relaxed

DMARC domain alignment is the requirement that the domain authenticated by SPF or DKIM must match the domain in the email’s visible From header, and this check is what separates DMARC from simple SPF or DKIM authentication alone.

This is the mechanism that makes DMARC effective against domain spoofing. An attacker might set up their own domain, pass SPF on their own domain, and still write “From: yourbank.com” in the header. Without alignment, that email sails through. With DMARC alignment, the mismatch is caught.

SPF Alignment

For SPF alignment to pass, the domain in the email’s MAIL FROM (also called the envelope sender or return-path) must match the domain in the From header. In relaxed alignment mode, subdomains are acceptable: mail.yourdomain.com aligns with yourdomain.com. In strict alignment mode, they must match exactly.

DKIM Alignment

For DKIM alignment to pass, the d= domain in the DKIM signature must match the From header domain. Relaxed mode allows subdomain matches. Strict mode requires an exact match.

Relaxed alignment is the right default for most organizations. Strict alignment is useful for domains that need tighter control, but it can cause failures with some legitimate third-party senders that sign using their own subdomain.

One of the two alignment checks (SPF or DKIM) must pass for DMARC to pass. If both fail alignment, DMARC fails regardless of whether SPF or DKIM passed their individual checks. That’s the part attackers count on people not knowing.

DMARC Reports: Aggregate vs. Forensic

DMARC generates two types of reports that domain owners receive from participating mail servers: aggregate reports (RUA), which summarize authentication results in bulk, and forensic reports (RUF), which provide message-level detail on individual failures.

Without DMARC reports, you’re flying blind. You have a policy published, but no visibility into whether it’s working or what it’s catching. Reports are how DMARC gives you that visibility.

Aggregate Reports (RUA)

Aggregate DMARC reports are XML-formatted files sent daily by receiving mail servers to the address specified in the rua= tag of your DMARC record. Each report covers a 24-hour period and includes the source IP addresses that sent email claiming to be from your domain, whether those emails passed or failed SPF and DKIM, and whether they passed or failed DMARC alignment.

The XML format isn’t human-readable at a glance, which is why DMARC report analysis tools exist. Services like Dmarcian and MXToolbox parse these reports into readable dashboards. Use one. Don’t try to read raw XML by hand.

Aggregate reports are your primary tool for identifying unauthorized senders. If an IP address in a report doesn’t match any of your known sending services, that’s a red flag worth investigating.

Forensic Reports (RUF)

Forensic DMARC reports, also called failure reports, are generated per message when an email fails DMARC checks. They include a copy of the email headers (and sometimes the full message body) and are sent to the address in the ruf=tag.

Forensic reports are more detailed than aggregate reports, but they come with two caveats. Not all major receiving servers send them. And some organizations avoid them for privacy reasons, since they can contain personal data. In European jurisdictions, processing forensic report data can carry GDPR implications.

For most SMEs, aggregate reports are sufficient. Set up RUF reporting, but build your monitoring workflow around RUA.

The Real Benefits of DMARC Email Security

DMARC email security delivers four concrete benefits: it stops domain spoofing and email phishing attacks, it provides visibility into unauthorized email sending, it improves email deliverability for legitimate messages, and it satisfies growing compliance and regulatory requirements.

The phishing threat isn’t abstract. According to the FBI IC3’s 2025 annual report, cybercrime complaints totaled 1,008,597 with losses of $20.877 billion. Phishing and email-based fraud account for a significant portion of that. Business email compromise (BEC) is consistently one of the costliest categories. DMARC directly cuts off the domain spoofing that enables most BEC attacks.

Brand Protection Against Domain Spoofing

Domain spoofing is when an attacker sends email that appears to come from your domain. Employees, clients, and suppliers receive what looks like an email from you, click a link, and hand over credentials or wire funds to a fraudulent account. With a p=reject DMARC policy in place, those emails never arrive.

Business email compromise attacks built on domain spoofing have cost organizations billions. DMARC doesn’t eliminate BEC entirely, but it closes the easiest attack path: impersonating your exact domain.

Email Deliverability and Compliance

In February 2024, Google and Yahoo mandated that bulk email senders implement SPF, DKIM, and DMARC policies as a condition of inbox delivery, according to Google’s official Gmail security announcement. Senders who don’t comply risk having their email routed to spam or rejected outright by Gmail and Yahoo Mail.

That covers a significant share of every business’s email recipients. DMARC isn’t just a security measure now. It’s a deliverability requirement. Organizations without a valid DMARC record are already paying the price in inbox placement rates.

Beyond Google and Yahoo, frameworks like PCI DSS and government cybersecurity mandates in multiple jurisdictions have incorporated email authentication requirements that DMARC satisfies.

How to Implement DMARC: A Gradual Rollout

DMARC implementation follows a four-phase process: audit your sending sources, configure SPF and DKIM for all legitimate senders, publish a monitoring DMARC record at p=none, then gradually escalate to p=quarantine and finally p=reject as you confirm all legitimate email is authenticating correctly.

Don’t skip phases. Every organization that has broken their own email flow did so by skipping the audit step and jumping straight to enforcement.

Phase 1: Audit Your Email Sending Sources

List every service that sends email using your domain. Your primary mail server is obvious, but don’t forget your CRM (like Salesforce), marketing platforms (like Mailchimp), helpdesk tools, HR systems, and any third-party service that sends notifications on your behalf.

Each of these needs to be authorized via SPF or properly signing with DKIM using your domain. If a service can’t sign with DKIM, make sure its sending IPs are in your SPF record.

Phase 2: Configure SPF and DKIM

Update your SPF DNS TXT record to include all authorized sending IP ranges and mail servers. The record lives at your root domain and looks like this:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.42 -all

The -all at the end means “reject anything not explicitly listed.” Use ~all (softfail) while you’re still auditing, then switch to -all when you’re confident the list is complete.

For DKIM, follow the setup documentation for each sending service. Most will give you a public key to publish as a DNS TXT record at a specific selector subdomain (e.g., google._domainkey.yourdomain.com).

Phase 3: Publish a p=none DMARC Record

Once SPF and DKIM are configured, publish your first DMARC record at _dmarc.yourdomain.com:

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

Monitor aggregate reports for 30 to 60 days. Look for unexpected sending sources and any legitimate senders whose emails are failing authentication. Fix them before moving to enforcement.

Phase 4: Escalate to Quarantine, Then Reject

Once your reports show that all legitimate email is authenticating cleanly, update your DMARC policy to p=quarantine with a low pct= value, then raise it incrementally. When you’ve run at p=quarantine; pct=100 for a full reporting cycle without surprises, move to p=reject.

This is where your domain actually becomes protected. Don’t leave it at p=quarantine indefinitely. Quarantine still lets spoofed emails reach spam folders. p=reject blocks them entirely. That’s the goal.

If you want more detail on the full process for hardening your email environment alongside DMARC, the broader topic of email security for SMEs covers the surrounding controls that make DMARC enforcement more effective.

What DMARC Cannot Protect Against

DMARC protects against email spoofing of your exact domain, but it cannot block look-alike domain attacks, display name spoofing, account takeover, or phishing sent from legitimate domains that an attacker controls or has compromised.

This is the part nobody wants to hear. DMARC is a powerful tool. It’s not a complete solution. Knowing its limits is how you avoid a false sense of security.

Look-alike Domain Attacks

An attacker registers yourcompany-support.com or yourcompnay.com and sends phishing email from that domain. If they set up SPF, DKIM, and DMARC on their own domain, those emails pass all authentication checks. Your DMARC record doesn’t cover domains you don’t own.

Defense against look-alike domains requires domain monitoring tools and, for high-value targets, a proactive program of registering common typo variants of your domain. DMARC doesn’t help here.

Display Name Spoofing

An attacker sends email from [email protected] but sets the display name to “John Smith, CEO” or “Your Bank.” Many email clients show the display name prominently and hide the actual address. DMARC doesn’t check display names. It only checks authenticated domains.

Training people to verify the actual email address before acting on requests is the mitigation here. DMARC can’t do it for you.

Account Takeover and Compromised Legitimate Accounts

If an attacker gains access to a real email account on your domain, they’re sending from a legitimate, DMARC-authenticated address. Every email they send will pass DMARC cleanly. The Verizon 2026 DBIR notes that vulnerability exploitation surpassed stolen credentials as the leading initial access vector, but stolen credentials remain a major threat vector. Multi-factor authentication on email accounts is the control that addresses this, not DMARC.

Pair DMARC with MFA, endpoint protection, and staff phishing awareness training. None of these replace each other. For a fuller picture of protecting your team against phishing and social engineering, see our guidance on phishing protection strategies for small businesses.

DMARC FAQ

Does DMARC affect my ability to receive email?

No. DMARC only governs outbound email sent from your domain. It tells other servers how to treat email claiming to come from you. It has no effect on email sent to your domain from others.

Do I need DMARC if I already have SPF and DKIM?

Yes. SPF and DKIM authenticate email, but they don’t tell receiving servers what to do when authentication fails. Without a DMARC record, each server makes its own decision, and many will simply deliver the email anyway. DMARC is the enforcement and reporting layer that makes SPF and DKIM actionable.

How long does DMARC setup take?

Publishing the initial DMARC record at p=none takes about 30 minutes if SPF and DKIM are already configured. The full rollout to p=reject, done correctly, typically takes 60 to 90 days. That’s the monitoring and gradual escalation period. Rushing it causes problems.

Can DMARC break my email?

Only if you skip the audit phase and enforce policy before you’ve authorized all legitimate senders. A p=none DMARC record cannot break email. p=reject applied prematurely can. Follow the phased rollout.

What is a DMARC compliance rate?

Your DMARC compliance rate is the percentage of email sent from your domain that passes DMARC authentication. Aggregate reports show this. A rate below 95% before enforcement means you still have legitimate senders who aren’t properly authorized. Fix them before moving to p=quarantine or p=reject.

Is DMARC required for all businesses?

Technically no, but practically yes. Google and Yahoo’s bulk sender requirements from February 2024 made DMARC a deliverability prerequisite for high-volume senders. Beyond inbox placement, most serious cybersecurity frameworks now treat email authentication as a baseline control. If you have a domain and you send email, you need a DMARC record.