DMARC Explained: What It Is and How to Set It Up

DMARC is a DNS TXT record that ties SPF and DKIM together by adding two things neither protocol provides on its own: alignment (does the authenticated domain match the visible From: address?) and policy (what should receivers do when alignment fails?). Without DMARC, an attacker can pass SPF under their own domain while spoofing yours in the From: header, and the receiving server has no instruction to stop it.

This guide covers how DMARC works, what alignment means in practice, the syntax of every DMARC tag, and a step-by-step rollout from monitoring (p=none) to full enforcement (p=reject).

What DMARC does

DMARC answers a specific question that neither SPF nor DKIM can answer alone: "Does the From: address that the recipient sees match the domain that SPF or DKIM actually authenticated?" SPF authenticates the envelope sender (Return-Path). DKIM authenticates the signing domain (d= tag). Neither one checks the From: header. DMARC bridges that gap.

DMARC also introduces reporting. The rua tag tells receivers to send aggregate reports (XML files listing source IPs, message counts, and pass/fail results) to an address you specify. These reports show you exactly who is sending email as your domain, both legitimate services and attackers.

For a broader overview of how SPF, DKIM, and DMARC work together in the authentication chain, see our email authentication explained guide.

DMARC alignment explained

Alignment is the concept that makes DMARC different from just running SPF and DKIM. It requires that the domain authenticated by SPF or DKIM matches the domain in the From: header. DMARC passes if at least one of the two (SPF or DKIM) both passes its check and aligns with From:.

SPF alignment

SPF alignment compares the domain in the Return-Path (envelope sender) to the domain in the From: header. If the Return-Path is [email protected] and the From: is [email protected], SPF alignment depends on the mode:

• Relaxed alignment (aspf=r, the default): The organizational domains must match. mail.example.com and example.com share the same organizational domain, so this passes.
• Strict alignment (aspf=s): The domains must be an exact match. mail.example.com does not equal example.com, so this fails.

DKIM alignment

DKIM alignment compares the d= domain in the DKIM signature to the domain in the From: header. If the DKIM signature has d=example.com and the From: is [email protected], alignment passes under both modes. If the DKIM signature has d=sendgrid.net (because the third-party service signed with their own domain), alignment fails regardless of the mode.

• Relaxed alignment (adkim=r, the default): Organizational domains must match. d=mail.example.com aligns with From: [email protected].
• Strict alignment (adkim=s): Exact match required. d=mail.example.com does not align with From: [email protected].

DMARC record syntax: every tag explained

A DMARC record is published as a DNS TXT record at _dmarc.example.com. Here is a typical record:

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

This record says: "Quarantine emails that fail alignment. Send daily aggregate reports to [email protected] and failure reports to [email protected]. Use relaxed alignment for both DKIM and SPF. Apply the policy to 100% of failing messages."

Only v and p are required. The simplest valid DMARC record is v=DMARC1; p=none;. However, without rua, you receive no reports, which makes the monitoring phase useless. Always include rua.

The three DMARC policies

Your DMARC policy determines what receiving servers do with email that fails alignment. The three levels represent increasing protection.

Among Fortune 500 companies, approximately 48% have reached p=reject, 14% use p=quarantine, and 38% remain at p=none (Valimail, 2025). The high percentage at p=none shows how common it is for organizations to start monitoring but never progress to enforcement.

Google, Yahoo, and Microsoft now require at minimum p=none with a valid DMARC record for bulk senders (over 5,000 messages per day). See our bulk sender requirements guide for the full list of requirements from each provider.

Step-by-step: setting up DMARC

DMARC aggregate reports: what they contain and how to read them

Aggregate reports (sent to the rua address) are XML files, usually compressed as .gz or .zip. They do not contain message content, subject lines, or recipient addresses. What they do contain:

• Report metadata: The reporting organization (e.g., google.com), report ID, and date range covered.
• Published policy: Your DMARC record as the receiver saw it at the time of evaluation.
• Record rows: Each row represents a group of messages from a specific source IP. It includes the IP address, message count, the policy applied (none, quarantine, or reject), SPF result, SPF alignment result, DKIM result, DKIM alignment result, and the From: domain.

Reading raw XML is tedious. Free tools like Google Postmaster Tools can help, and many DMARC monitoring services parse the XML into dashboards. At a minimum, focus on two things: (1) which source IPs are failing alignment, and (2) whether any of those IPs belong to legitimate services you forgot to authorize.

If you see high volumes of failing messages from IPs you do not recognize, that is spoofing. Your DMARC policy is working. If you see failing messages from IPs belonging to your marketing platform or CRM, those services need proper DKIM configuration before you move to enforcement.

DMARC and third-party senders

Third-party services (Mailchimp, HubSpot, SendGrid, Salesforce, and similar platforms) are the most common source of DMARC alignment failures. The reason: many of these services sign emails with their own domain by default (e.g., d=sendgrid.net), not yours. SPF may pass because you added their include: to your SPF record, but SPF alignment fails because the Return-Path domain is the provider's, not yours.

The fix is DKIM delegation. Most email service providers support custom DKIM signing, where they sign messages with your domain (d=yourdomain.com) using a key pair you publish in your DNS. This gives you DKIM alignment. The setup typically involves:

1. Generating a DKIM key pair in the provider's dashboard.
2. Publishing the CNAME or TXT record they provide in your DNS.
3. Enabling custom DKIM signing in the provider's settings.

SPF include: alone is not enough for DMARC. You need either SPF alignment (the provider uses your domain as the Return-Path) or DKIM alignment (the provider signs with your domain). DKIM delegation is the more reliable approach because it survives email forwarding.

For details on setting up DKIM with third-party providers, see our DKIM setup guide.

DMARC and email forwarding: the ARC protocol

Email forwarding is DMARC's biggest operational challenge. When a message is forwarded (e.g., from a university address to a personal Gmail account), the forwarding server's IP replaces the original. SPF fails because the forwarding server is not in the sender's SPF record. DKIM may survive if the forwarding server does not modify the message, but many forwarders add headers, footers, or subject line tags that break the DKIM signature.

If both SPF and DKIM fail after forwarding, DMARC fails, and a p=reject policy blocks the legitimate message.

ARC (Authenticated Received Chain)

ARC (RFC 8617) was designed to address this problem. Each server in the forwarding chain adds three ARC headers that capture the authentication state of the message at that point: ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. These form a chain of custody.

When the final receiving server evaluates DMARC and sees that SPF and DKIM have failed, it can check the ARC chain. If a trusted intermediary (like Google or Microsoft) vouches that the message passed authentication before forwarding, the receiver can choose to honor the original result instead of applying the DMARC policy.

ARC is not a guarantee. Receivers are not required to trust ARC headers. Google, Microsoft, and Yahoo support ARC, but the decision to override DMARC based on ARC is at the receiver's discretion. Still, ARC significantly reduces false rejections from forwarded mail, and its adoption continues to grow.

Common DMARC mistakes

1. Staying at p=none indefinitely

Approximately 29.4% of domains with DMARC remain at p=none with no plan to enforce (EasyDMARC, 2025). Monitoring without enforcement provides zero protection against spoofing. Attackers can spoof your domain freely because the policy tells receivers to take no action. Treat p=none as a temporary phase, not a permanent configuration.

2. Ignoring the sp= tag

Without sp=, subdomains inherit the parent policy. If your parent domain is at p=reject but you have not considered subdomains, that inheritance may be exactly what you want. But if you have subdomains with different sending requirements, or if you want to explicitly block non-sending subdomains, set sp=reject on the parent or publish separate DMARC records on each subdomain.

3. Not monitoring rua reports

Publishing rua=mailto:... and then ignoring the reports defeats the purpose of the monitoring phase. Aggregate reports reveal unauthorized senders, misconfigured third-party services, and forwarding issues. Review them weekly during the p=none phase, and continue monitoring after enforcement to catch new sending services that need authorization.

4. Not authorizing third-party senders before enforcing

Moving to p=quarantine or p=reject before configuring DKIM delegation for your marketing platform, CRM, or transactional email service will cause legitimate messages from those services to be quarantined or blocked. Audit every third-party sender in your aggregate reports, configure custom DKIM for each one, and verify alignment passes before increasing your policy level.

5. Jumping to p=reject without gradual rollout

Going directly from p=none to p=reject is risky. Use the pct tag to phase in enforcement. Start with p=quarantine; pct=10 and increase the percentage over several weeks. This limits the blast radius if you missed a legitimate sender. Only move to p=reject after running at p=quarantine; pct=100 with clean results.

DMARC adoption statistics

DMARC adoption has grown significantly since Google and Yahoo announced their bulk sender requirements in late 2023. The number of domains publishing DMARC records has more than doubled since early 2024. However, the enforcement gap remains large: most domains that publish DMARC stay at p=none, providing no real protection against spoofing.

For domains serious about email security, the goal should be p=reject on both the parent domain and all subdomains. If your emails are ending up in spam despite having DMARC configured, the issue may be related to sender reputation or content filtering. See our guide to fixing emails going to spam for troubleshooting steps.

How to verify your DMARC record

1. Generate or check your record: Use our DMARC Record Generator to build a correctly formatted record, or check your existing record for syntax errors and missing tags.
2. Run a full domain health check: The Email Health Score tool checks SPF, DKIM, and DMARC together, along with blacklist status and overall sending reputation.
3. Verify bulk sender compliance: If you send more than 5,000 emails per day, run the Bulk Sender Compliance Checker to confirm you meet Google, Yahoo, and Microsoft requirements.
4. Test with a real email: Send a message to a Gmail account, click the three-dot menu, select "Show original," and look for dmarc=pass in the Authentication-Results header.

For a complete overview of all three protocols and how they interact, see our email authentication explained guide. For definitions of technical terms used in this article, check the email glossary.

Frequently asked questions

What is DMARC and why do I need it?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record that tells receiving mail servers what to do when an email fails SPF and DKIM alignment checks. Without DMARC, an attacker can spoof your From: address even if you have SPF and DKIM configured, because neither protocol alone verifies that the visible From: header matches the authenticated domain. DMARC closes that gap by requiring alignment and letting you set an enforcement policy (none, quarantine, or reject). Google, Yahoo, and Microsoft require DMARC for bulk senders.

What is the difference between p=none, p=quarantine, and p=reject?

The three DMARC policies control what happens to emails that fail alignment. p=none is monitoring only: failing emails are delivered normally, but you receive aggregate reports showing who is sending as your domain. p=quarantine tells receiving servers to route failing emails to the spam or junk folder. p=reject instructs receivers to block failing emails entirely, preventing them from reaching the recipient. Most security experts recommend starting at p=none, moving to p=quarantine after reviewing reports, and ultimately reaching p=reject for full protection.

How does DMARC alignment work?

DMARC alignment checks whether the domain in the visible From: header matches the domain authenticated by SPF or DKIM. For SPF alignment, the Return-Path (envelope sender) domain must match the From: domain. For DKIM alignment, the d= domain in the DKIM signature must match the From: domain. DMARC passes if either SPF or DKIM both passes its authentication check and passes alignment. Relaxed alignment (the default) allows subdomain matches (e.g., mail.example.com aligns with example.com). Strict alignment requires an exact domain match.

How long does it take to go from p=none to p=reject?

A typical rollout takes 4 to 12 weeks. Start with p=none for 2 to 4 weeks to collect aggregate reports and identify all legitimate sending sources. Then move to p=quarantine with a low pct value (10 to 25%) and gradually increase over 2 to 4 weeks while monitoring for delivery issues. Once you are confident that all authorized senders pass alignment, move to p=reject. Rushing the process risks blocking legitimate email from third-party services that have not been properly configured with DKIM delegation.