What is DMARC? Complete Guide to Email Authentication

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS-based email authentication protocol that tells inbox providers — such as Gmail, Outlook, and Yahoo Mail — what to do when an email claiming to come from your domain fails SPF or DKIM verification checks. It is the most important protocol for preventing email spoofing and phishing attacks.

Published as RFC 7489 by the IETF, DMARC builds on two existing authentication standards — SPF and DKIM — and adds a critical policy and reporting layer. Without DMARC, inbox providers have no way to know what you, the domain owner, want them to do when authentication fails. With DMARC, you explicitly instruct them to monitor, quarantine, or reject unauthenticated messages.

According to research from Valimail, fewer than 30% of domains globally have a DMARC record at enforcement (quarantine or reject). This means the vast majority of organizations remain vulnerable to domain spoofing — a gap that attackers actively exploit. The FBI's Internet Crime Complaint Center (IC3) reported that business email compromise (BEC) attacks caused over $2.9 billion in losses in 2023 alone, and domain spoofing is a primary vector for these attacks.

How DMARC Works

DMARC operates through a straightforward three-step process every time an email is received by an inbox provider. Understanding this flow is essential for configuring DMARC correctly and troubleshooting authentication failures.

Step 1: An Email is Sent

When your mail server (or a third-party service like Mailchimp, SendGrid, or Google Workspace) sends an email on behalf of your domain, the message includes headers that identify the sending domain. The two key headers are the Return-Path (envelope sender, used by SPF) and the From header (visible to the recipient, used by DMARC alignment).

Step 2: The Receiving Server Checks SPF and DKIM

When the email arrives at the recipient's inbox provider, the server performs two independent authentication checks:

• SPF check: The server looks up the SPF record for the Return-Path domain and verifies that the sending IP address is authorized to send on behalf of that domain.
• DKIM check:The server retrieves the DKIM public key from DNS and uses it to verify the cryptographic signature in the email's DKIM-Signature header, confirming the message was not altered in transit.

Step 3: The DMARC Policy is Applied

After SPF and DKIM checks complete, the receiving server queries the DMARC record for the domain in the From header. DMARC then evaluates alignment — it checks whether the domain that passed SPF or DKIM matches (or aligns with) the domain in the From header. If at least one protocol passes and aligns, DMARC passes. If both fail or neither aligns, the DMARC policy (p=) dictates what happens next:

• p=none: Deliver the message normally but send a report to the domain owner.
• p=quarantine: Route the message to the spam or junk folder.
• p=reject: Block the message entirely — it is never delivered.

Alignment is the concept that makes DMARC more powerful than SPF or DKIM alone. There are two alignment modes:

• SPF alignment: The domain in the Return-Path must match the domain in the From header. In relaxed mode (the default), the organizational domain must match (e.g., bounce.example.com aligns with example.com). In strict mode, an exact match is required.
• DKIM alignment: The d= domain in the DKIM signature must match the domain in the From header. Relaxed mode allows organizational domain matching; strict mode requires an exact match.

DMARC Policy Types

DMARC defines three policy levels, each representing a different level of enforcement. The recommended approach is to start with the least restrictive policy and gradually increase enforcement as you gain confidence in your authentication setup.

p=none (Monitor Only)

The p=none policy is the monitoring-only mode. When a message fails DMARC, the inbox provider delivers it normally but sends an aggregate report (XML) to the address specified in your rua tag. This policy does not protect your domain from spoofing, but it gives you complete visibility into who is sending email using your domain — both legitimate services and unauthorized senders.

This is the recommended starting point for every DMARC deployment. It allows you to discover all legitimate sending sources, verify their SPF and DKIM configurations, and identify potential issues before enforcement causes legitimate mail to be blocked.

p=quarantine

The p=quarantinepolicy instructs inbox providers to treat failing messages as suspicious. In practice, this typically means the message is delivered to the recipient's spam or junk folder rather than the inbox. This is the intermediate enforcement step — it protects recipients from most spoofing attempts while providing a safety net for legitimate messages that may still have authentication issues.

You can use the pct tag to apply quarantine to only a percentage of failing messages (e.g., pct=25 applies the policy to 25% of failures), allowing you to ramp up enforcement gradually.

p=reject (Maximum Protection)

The p=reject policy provides the highest level of protection. It instructs inbox providers to completely block any message that fails DMARC — the email is never delivered to the recipient. This is the gold standard for domain protection and is the policy that organizations should aim to reach after completing their monitoring and quarantine phases.

According to data from the Global Cyber Alliance, domains with p=reject see a significant reduction in phishing emails that successfully impersonate their brand. However, moving to reject prematurely — before all legitimate senders are properly authenticated — can cause legitimate email to be lost. Always complete the monitoring and quarantine phases first.

DMARC Record Syntax

A DMARC record is a TXT record published in DNS at the subdomain _dmarc.example.com. Here is an example of a well-configured DMARC record:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100

Each DMARC record is composed of tag-value pairs separated by semicolons. Here is a complete reference of all available tags:

• v (required): Protocol version. Must be DMARC1. This must be the first tag in the record.
• p (required): Policy for the domain. Values: none, quarantine, or reject.
• rua: Reporting URI for aggregate reports. Specifies where daily XML aggregate reports should be sent. Example: mailto:dmarc-reports@example.com. Multiple URIs can be comma-separated.
• ruf: Reporting URI for forensic (failure) reports. Specifies where individual failure reports should be sent. Note that many inbox providers do not send forensic reports due to privacy concerns.
• sp: Subdomain policy. Overrides the ptag for subdomains. If omitted, subdomains inherit the parent domain's policy.
• adkim: DKIM alignment mode. Values: r (relaxed, default) or s (strict). Relaxed allows organizational domain matching; strict requires an exact domain match.
• aspf: SPF alignment mode. Values: r (relaxed, default) or s (strict). Same behavior as adkim but applied to SPF.
• pct: Percentage of messages to which the DMARC policy applies. Values: 1 to 100 (default: 100). Useful for gradual rollout — start at pct=25 and increase over time.
• fo: Failure reporting options. Values: 0 (report if all mechanisms fail, default), 1 (report if any mechanism fails), d (report DKIM failures), s (report SPF failures). Using fo=1 provides the most comprehensive failure data.

Why DMARC Matters in 2026

DMARC has moved from a best practice to a hard requirement. Over the past two years, the world's largest inbox providers have systematically begun rejecting email from domains that lack proper DMARC authentication. If your domain does not have a DMARC record, your emails are increasingly likely to land in spam — or never be delivered at all.

• Google (Gmail): Since February 2024, Google requires all senders who send more than 5,000 emails per day to Gmail addresses to have a DMARC record. Senders without DMARC face temporary errors (421) and eventual rejection (550) of their messages.
• Yahoo Mail: Yahoo implemented matching requirements in February 2024, requiring DMARC authentication for bulk senders. Non-compliant senders see degraded deliverability and increased bounce rates.
• Microsoft Outlook: In May 2025, Microsoft began enforcing DMARC requirements for Outlook.com, Hotmail, and Live.com. Domains sending over 5,000 messages per day must have valid SPF, DKIM, and DMARC records. Non-compliant messages are routed to junk, with full rejection planned for subsequent phases.
• CISA BOD 18-01: The U.S. Cybersecurity and Infrastructure Security Agency (CISA) mandated DMARC at p=reject for all federal agency domains under Binding Operational Directive 18-01. This directive has been fully enforced since 2018 and has served as a model for similar mandates in the UK (NHS, government), Australia, and the EU.

Beyond compliance, DMARC directly impacts email deliverability. Research from Return Path (now Validity) showed that domains with DMARC at enforcement saw a 10% increase in inbox placement on average. For organizations that rely on email for marketing, transactional communications, or customer support, this improvement translates directly to revenue.

DMARC and SPF and DKIM: How They Work Together

DMARC does not work in isolation. It is built on top of two foundational email authentication protocols — SPF and DKIM — and ties them together with alignment and policy enforcement. Understanding how these three protocols interact is critical for a successful deployment.

• SPF (Sender Policy Framework): SPF is a DNS record that lists the IP addresses and servers authorized to send email for your domain. When a message arrives, the receiving server checks the sending IP against the SPF record for the Return-Pathdomain. SPF answers the question: "Is this server allowed to send mail for this domain?"
• DKIM (DomainKeys Identified Mail):DKIM uses public-key cryptography to sign outgoing messages. The sending server attaches a digital signature to each email, and the receiving server verifies it using a public key published in DNS. DKIM answers the question: "Was this message altered in transit?"
• DMARC: DMARC takes the results of SPF and DKIM checks and adds two critical layers: alignment (ensuring the authenticated domain matches the visible Fromdomain) and policy (telling inbox providers what to do when authentication fails). DMARC answers the question: "What should happen to unauthenticated mail?"

Without SPF and DKIM, there is nothing for DMARC to evaluate. Without DMARC, SPF and DKIM results are advisory only — inbox providers may or may not act on them. All three protocols must work together for comprehensive email authentication.

For a detailed comparison of all three protocols, including configuration examples and common pitfalls, see our guide: SPF vs DKIM vs DMARC Explained.

DMARC Reporting: RUA and RUF

One of DMARC's most valuable features is its built-in reporting mechanism. DMARC reports provide visibility into every email sent using your domain, whether legitimate or fraudulent. There are two types of reports:

Aggregate Reports (RUA)

Aggregate reports are XML files sent daily (typically once every 24 hours) by inbox providers to the address specified in your rua tag. Each report contains a summary of all emails the provider received claiming to be from your domain, including:

• The sending IP address and volume of messages
• SPF and DKIM authentication results for each source
• DMARC alignment and disposition (pass, quarantine, reject)
• The DMARC policy that was applied

Aggregate reports are the primary data source for understanding your email authentication posture. They reveal which services are sending email on your behalf, whether those services are properly authenticated, and how much unauthorized email is being sent using your domain. Major providers like Google, Yahoo, Microsoft, and Comcast all send aggregate reports.

Forensic Reports (RUF)

Forensic reports (also called failure reports) contain detailed information about individual messages that failed DMARC. They typically include sanitized copies of the email headers and sometimes portions of the message body. Forensic reports are useful for diagnosing specific authentication failures, such as determining exactly which third-party sender is misconfigured.

However, forensic reports have significant limitations. Due to privacy regulations (including GDPR), many major inbox providers — including Google and Microsoft — do not send forensic reports. Among providers that do send them, the reports are often redacted. For this reason, aggregate reports should be your primary monitoring tool, with forensic reports as a supplementary diagnostic resource.

Why monitoring matters before enforcement: Moving to p=quarantine or p=reject without first analyzing your aggregate reports is one of the most common and costly DMARC mistakes. If a legitimate sending service (such as your CRM, marketing platform, or transactional email provider) is not properly authenticated, enforcing DMARC will cause those messages to be quarantined or rejected. Always spend 2 to 4 weeks in p=none mode, reviewing your aggregate reports and remediating authentication issues, before moving to enforcement.

How to Implement DMARC

Implementing DMARC is a phased process that typically takes 4 to 8 weeks from initial setup to full enforcement. Rushing this process risks blocking legitimate email. Follow these five steps for a safe and effective deployment.

Step 1: Verify SPF and DKIM

Before publishing a DMARC record, ensure that all your legitimate email sources have valid SPF and DKIM configurations. This includes your primary mail server (e.g., Google Workspace or Microsoft 365), marketing platforms (e.g., Mailchimp, HubSpot), transactional email services (e.g., SendGrid, Postmark), and any other system that sends email using your domain. Use a tool like our SPF Checker and DKIM Checker to verify each source.

Step 2: Publish a DMARC Record with p=none

Add a TXT record at _dmarc.yourdomain.com with a monitoring-only policy. Include a rua tag so you receive aggregate reports. Example:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

The fo=1 tag ensures you receive failure reports for any mechanism failure, not just when all mechanisms fail. DNS propagation typically completes within a few hours, and you should start receiving aggregate reports within 24 to 48 hours.

Step 3: Monitor Reports for 2-4 Weeks

Analyze your aggregate reports to build a complete picture of your email ecosystem. Identify every IP address and service sending email using your domain. For each source, verify that SPF and DKIM are correctly configured and that alignment passes. Fix any authentication issues before proceeding. A DMARC monitoring tool (such as Inbox Insignia) automates this analysis and alerts you to problems.

Step 4: Move to p=quarantine

Once you are confident that all legitimate senders pass DMARC, update your policy to quarantine. Consider starting with a partial rollout using the pct tag:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=25; fo=1

Monitor for another 1 to 2 weeks. If no legitimate mail is being quarantined, increase pct to 50, then 100.

Step 5: Move to p=reject

After confirming that quarantine at 100% causes no issues, update your policy to reject. This provides maximum protection against domain spoofing:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1

Continue monitoring your aggregate reports indefinitely. New sending services, infrastructure changes, or configuration drift can cause authentication failures at any time. Ongoing monitoring is essential for maintaining your DMARC posture.

For a detailed walkthrough with screenshots and configuration examples, see our step-by-step guide: How to Set Up DMARC.

Common DMARC Issues

Even well-intentioned DMARC deployments encounter common issues. Here are the most frequent problems and how to resolve them.

Alignment Failures

Alignment failures are the number one cause of DMARC failures for legitimate email. This occurs when the domain in the From header does not match the domain that passed SPF or DKIM. For example, if your marketing platform sends email with a Return-Path of bounce.esp-provider.com but the From header is you@yourdomain.com, SPF passes for the ESP's domain — but it does not align with your domain, so DMARC fails on SPF. The solution is to configure custom return-path domains and DKIM signing domains with each of your sending services.

Third-Party Senders Not Authenticated

Many organizations use dozens of third-party services that send email on their behalf: CRMs, helpdesks, billing systems, HR platforms, project management tools, and more. Each of these must be added to your SPF record and configured with DKIM signing for your domain. Missing even one service will cause those emails to fail DMARC once enforcement is enabled. Your aggregate reports will reveal any unauthenticated senders — review them carefully before moving past p=none.

Multiple DMARC Records

A domain must have exactly one DMARC record. If multiple TXT records exist at _dmarc.yourdomain.com, the DMARC check is considered to have failed entirely, and no policy is applied. This is a common mistake during migrations or when multiple teams manage DNS independently. Always verify that only one DMARC record exists for each domain.

Missing RUA Tag

Publishing a DMARC record without a rua tag means you will receive no aggregate reports. Without reports, you have no visibility into who is sending email using your domain and no data to guide your enforcement decisions. Always include at least one rua address, and ensure the receiving mailbox is monitored or processed by a DMARC analytics tool.

Check Your DMARC Record

Not sure if your domain has a DMARC record, or want to verify that it is configured correctly? Use our free DMARC Checker tool to instantly look up and validate your DMARC record. The tool checks for syntax errors, missing tags, alignment issues, and provides actionable recommendations to improve your configuration.

Frequently Asked Questions

Is DMARC required?

Yes. Google and Yahoo have required DMARC for bulk senders (5,000+ messages per day) since February 2024. Microsoft began enforcing DMARC for Outlook.com in May 2025. If you send email at any significant volume, DMARC is no longer optional — it is a requirement for reliable inbox delivery.

How long does DMARC take to set up?

The DNS record itself takes just a few minutes to publish. However, reaching full enforcement (p=reject) typically takes 4 to 8 weeks. This timeline allows you to collect aggregate reports, identify all legitimate sending sources, fix authentication issues, and gradually tighten your policy from p=none to p=quarantine to p=reject.

Does DMARC affect email deliverability?

Yes, positively. Domains with properly configured DMARC records have measurably higher inbox placement rates. Inbox providers like Gmail and Outlook use DMARC as a trust signal, and authenticated emails are more likely to reach the inbox rather than the spam folder. Studies consistently show a 5-10% improvement in deliverability for domains at DMARC enforcement.

What happens if I don't have DMARC?

Without DMARC, your emails risk being rejected or filtered to spam by Gmail, Yahoo, and Outlook — especially if you send more than 5,000 messages per day. Additionally, your domain can be freely impersonated by attackers in phishing campaigns, putting your customers, partners, and brand reputation at risk. There is no downside to deploying DMARC in monitor mode (p=none).

Can DMARC prevent all phishing?

DMARC prevents exact-domain spoofing, which is the most common and most damaging form of email impersonation. However, it does not protect against lookalike domain attacks (e.g., examp1e.com impersonating example.com) or display-name spoofing. DMARC should be part of a defense-in-depth strategy that includes employee training, email filtering, and domain monitoring.

Start Monitoring Your Domain for Free

Inbox Insignia provides automated DMARC monitoring, aggregate report parsing, and compliance scoring for your domains. Our platform alerts you to authentication failures, identifies unauthorized senders, and guides you through the path from p=none to p=reject with confidence. and start monitoring your DMARC compliance today.