DMARC Email Auth Guide [2026]

What Is DMARC?

DMARC lets domain owners tell email receivers how to handle messages that fail authentication checks. Without DMARC, anyone can send email that appears to come from your domain, and receivers have no way to know whether to trust it. Attackers exploit this to send phishing emails, business email compromise scams, and brand impersonation attacks that damage your reputation and hurt your customers.

DMARC builds on two existing protocols — SPF and DKIM — and adds the critical missing piece: alignment. This means the domain in the visible From: header must match the domain authenticated by SPF or DKIM. It also provides reporting, so you can see exactly who is sending email claiming to be from your domain.

Domain-based Message Authentication, Reporting & Conformance (DMARC) is defined in RFC 7489 and has become a de facto standard for email security. Our 2026 email authentication research shows adoption accelerating rapidly. Since 2024, Google and Yahoo require DMARC enforcement for bulk senders, making it essential infrastructure for anyone sending business email.

How DMARC Works

DMARC authentication happens when an email receiver processes an incoming message. Here’s the step-by-step flow:

1. The receiver checks SPF and DKIM. It validates whether the message passes SPF (by checking the sending IP against your SPF record) and DKIM (by verifying the cryptographic signature against your DKIM public key).

2. The receiver performs alignment checks. DMARC requires that the domain authenticated by SPF or DKIM matches the domain in the From: header. This is what prevents spoofing — an attacker can’t pass DMARC by authenticating a different domain.

3. The receiver applies your policy. If the message fails both SPF and DKIM, or if neither passes alignment, the receiver follows the policy you set in your DMARC record: none (monitor only), quarantine (send to spam), or reject (block delivery).

4. The receiver sends you reports. Email providers send daily aggregate reports to the address in your rua tag, showing authentication results for all messages claiming to be from your domain. Some providers also send forensic reports (to your ruf address) with details about individual failures.

DMARC, SPF, and DKIM: How They Work Together

DMARC doesn’t work in isolation. It relies on SPF and DKIM to do the actual authentication work. Here’s how the three protocols complement each other:

SPF (Sender Policy Framework) authorizes which IP addresses or servers can send email for your domain. It prevents unauthorized servers from sending on your behalf, but it only checks the envelope-from address (the return-path used during SMTP), not the visible From header.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the email headers. The receiving server verifies this signature against a public key published in your DNS. DKIM proves the message hasn’t been tampered with and verifies the signing domain, but it doesn’t require the signing domain to match the From header.

DMARC ties them together by requiring that the domain in the From: header aligns with the domain authenticated by SPF or DKIM. This prevents attackers from passing SPF or DKIM for their own domains while spoofing your domain in the visible From address.

All three protocols together create defense in depth. If one authentication method fails, DMARC can still pass as long as the other succeeds and aligns. This provides resilience against email forwarding scenarios that break SPF, or mailing list modifications that invalidate DKIM signatures.

The DMARC Record: Anatomy and Syntax

A DMARC record is a DNS TXT entry published at _dmarc.yourdomain.com. You can use a DMARC record generator to create one quickly, or build it manually. Here’s a typical example:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r; fo=1

Here’s what each tag means:

The only required tags are v and p. Everything else is optional, but you should always include rua to receive aggregate reports.

DMARC Policies: none, quarantine, reject

DMARC has three policy levels that control what happens to messages that fail authentication:

p=none — Monitor only. Messages are delivered normally regardless of DMARC results, but you receive reports showing authentication outcomes. This is where every deployment should start. It lets you identify all legitimate senders and verify they’re passing SPF or DKIM before enforcing a stricter policy.

p=quarantine — Failed messages go to spam. Most receivers interpret this as “deliver to the junk folder,” but some may use other quarantine mechanisms. This policy protects end users while still allowing them to recover false positives from the spam folder.

p=reject — Failed messages are blocked at the SMTP level. The receiving server refuses delivery during the initial connection, so the message never reaches the inbox or spam folder. This is full DMARC enforcement and provides the strongest protection against spoofing.

Most organizations follow a gradual path to enforcement:

1. Start with p=none and monitor reports for 2-4 weeks
2. Identify all legitimate senders and fix any SPF or DKIM issues
3. Move to p=quarantine with pct=10 (apply to 10% of traffic) to test impact
4. Increase pct to 100 over several weeks
5. Move to p=reject with pct=10, then gradually increase to 100

Jumping straight to p=reject without monitoring can block legitimate email from third-party services like marketing platforms, ticketing systems, or CRM tools that send on your behalf. Always monitor first.

DMARC Alignment: Relaxed vs Strict

Alignment is what makes DMARC effective. It requires that the domain authenticated by SPF or DKIM matches the domain in the visible From: header. Without alignment, an attacker could pass SPF for their own domain while spoofing your domain in the From address.

DMARC supports two alignment modes:

Relaxed alignment (default) — The organizational domains must match, but subdomains are allowed. For example, if the From address is [email protected], SPF can pass alignment by authenticating example.com or any subdomain like send.example.com. This is controlled by the aspf=r (SPF) and adkim=r (DKIM) tags.

Strict alignment — The exact domains must match. If the From address is [email protected], SPF must authenticate mail.example.com exactly, not example.com or send.example.com. Set this with aspf=s (SPF) and adkim=s (DKIM).

Most deployments use relaxed alignment because it accommodates legitimate sending scenarios where mail servers use different subdomains. Strict alignment provides stronger security but requires precise configuration of all sending sources.

For SPF alignment, the comparison is between the From domain and the envelope-from domain (also called return-path or RFC5321.MailFrom). For DKIM alignment, the comparison is between the From domain and the d= parameter in the DKIM signature.

Here’s a concrete example:

From: [email protected]
Return-Path: [email protected]
DKIM-Signature: d=mail.example.com; ...

With relaxed alignment: This message passes SPF alignment (mail.example.com and example.com share the organizational domain) and DKIM alignment (same reason). DMARC passes.

With strict alignment: This message fails both SPF and DKIM alignment because neither mail.example.com matches example.com exactly. DMARC fails.

Understanding DMARC Aggregate Reports (RUA)

DMARC reporting is what sets it apart from SPF and DKIM. Aggregate reports give you visibility into who is sending email claiming to be from your domain, whether those messages are passing authentication, and what policy was applied.

Aggregate reports are XML files sent daily by email receivers to the address in your rua tag. Each report covers a 24-hour window and includes:

• Source IP addresses that sent email claiming to be from your domain
• Volume counts for each source
• SPF results (pass, fail, none) and the domain checked
• DKIM results (pass, fail, none) and the domain checked
• Alignment results for both SPF and DKIM
• Policy evaluation (whether DMARC passed or failed, and what action was taken)
• Metadata like the reporting organization, date range, and report ID

The reports are verbose and technical, which is why most organizations use a DMARC reporting tool to parse and visualize them. Without reports, you’re flying blind — you won’t know if legitimate senders are failing DMARC until users complain about missing email.

Common insights from aggregate reports:

• Unknown senders appear in your reports, indicating possible spoofing attempts or forgotten third-party services
• Legitimate senders that fail SPF or DKIM, often due to missing SPF includes or incorrectly configured DKIM signing
• Volume patterns that reveal which mail streams are highest risk if you move to enforcement
• Subdomain gaps where your main domain has p=reject but subdomains remain unprotected

If you don’t receive aggregate reports after publishing a DMARC record with an rua tag, check that the email address is valid and can receive large XML attachments. Some receivers also require you to verify ownership of the reporting address if it’s on a different domain.

DMARC Forensic Reports (RUF) and ARF

Forensic reports (also called failure reports) provide message-level details about individual DMARC failures. Unlike aggregate reports, which summarize results for thousands of messages, forensic reports contain the headers and sometimes the body of a single failed message.

Forensic reports are sent to the address in your ruf tag and use the ARF (Abuse Reporting Format) structure. They include the full SMTP headers, authentication results, and the DMARC policy evaluation.

Why you might not receive forensic reports:

Most major email receivers (Gmail, Yahoo, Outlook.com, etc.) do not send forensic reports due to privacy concerns. The reports can contain sensitive information from the message body or headers, creating legal and data protection risks for the receiver. Even if you specify a ruf address, you’ll likely only receive forensic reports from smaller providers or enterprise mail gateways.

The fo tag controls when forensic reports are sent:

• fo=0 — Send reports only if both SPF and DKIM fail (default)
• fo=1 — Send reports if either SPF or DKIM fails
• fo=d — Send reports if DKIM fails
• fo=s — Send reports if SPF fails

Because forensic reports are rarely sent, most organizations rely entirely on aggregate reports for DMARC monitoring. If you do receive forensic reports, they’re useful for diagnosing specific authentication failures, but they shouldn’t be the primary monitoring mechanism.

Why DMARC Fails: Common Causes and Fixes

Understanding DMARC failure is critical before moving to enforcement. A DMARC failure means the email failed both SPF and DKIM, or neither passed the alignment check. Here are the most common causes:

1. Email forwarding breaks SPF

When a user forwards an email, the forwarding server sends it on behalf of the original sender. This breaks SPF because the forwarding server’s IP isn’t in the original domain’s SPF record. DKIM usually survives forwarding, so the message can still pass DMARC if DKIM alignment succeeds. ARC helps receivers recognize legitimate forwarding.

2. Mailing lists modify content and break DKIM

Mailing lists often add footers or modify subject lines, invalidating the DKIM signature. If the list doesn’t re-sign with DKIM and SPF breaks due to the new sending source, DMARC fails. Well-configured mailing lists use DKIM signing or ARC to preserve authentication.

3. Third-party services send without proper authentication

Marketing platforms, CRM systems, and support ticketing tools often send email on your behalf. If they’re not included in your SPF record or not configured to sign with DKIM using your domain, they’ll fail DMARC. Always configure these services to authenticate correctly before enforcing DMARC.

4. Subdomain gaps

If you set p=reject on your main domain but don’t specify sp=reject for subdomains, attackers can still spoof subdomain.yourdomain.com. Always set a subdomain policy.

5. Alignment mode mismatch

If you’re using strict alignment (aspf=s or adkim=s) but your mail servers use different subdomains for the envelope-from or DKIM signature, you’ll fail alignment even if SPF and DKIM pass. Switch to relaxed alignment unless you have a specific reason for strict mode.

6. Missing or invalid SPF/DKIM records

If your SPF record has syntax errors, exceeds the 10 DNS lookup limit, or your DKIM keys aren’t published correctly, both SPF and DKIM will fail, causing DMARC to fail. Validate your SPF and DKIM configurations before relying on DMARC.

To diagnose DMARC failures, check your aggregate reports for patterns. Look at which sources are failing, whether they’re failing SPF, DKIM, or both, and whether alignment is the issue. For a step-by-step walkthrough, see DMARC Failed: How to Fix It. Fix the underlying SPF or DKIM problems before enforcing DMARC.

DMARC vs DKIM vs SPF

These three protocols work together but serve different purposes:

When to use each:

• Use SPF if you control the servers that send email for your domain and want to authorize specific IPs
• Use DKIM if you want to prove message integrity and verify the signing domain, especially for messages that pass through forwarders or mailing lists
• Use DMARC always, because it’s the only protocol that ties authentication to the From address and gives you visibility into your email ecosystem

You need all three for complete protection. SPF alone doesn’t prevent From header spoofing. DKIM alone doesn’t prevent an attacker from signing with their own domain. DMARC alone doesn’t authenticate anything — it just enforces alignment of the underlying SPF and DKIM results.

DMARC Monitoring

DMARC monitoring means actively reviewing aggregate and forensic reports to understand authentication results for your domain. Without monitoring, you won’t know:

• Who is sending email claiming to be from your domain
• Whether legitimate senders are failing DMARC
• Whether attackers are attempting to spoof your domain
• What impact enforcing DMARC would have on mail delivery

Manual monitoring is impractical because aggregate reports are verbose XML files, and high-volume domains receive hundreds of reports per day. Most organizations use a DMARC monitoring tool to parse reports, aggregate results, and visualize trends.

Key metrics to monitor:

DMARC pass rate — The percentage of messages that pass DMARC. You should aim for 95%+ before moving to enforcement.

Unauthenticated sources — IP addresses or domains sending email claiming to be from your domain that fail both SPF and DKIM. These could be attackers or misconfigured legitimate senders.

Volume by source — How much mail each authenticated source sends. This helps you prioritize which senders to fix first.

Policy override rate — How often receivers apply a different policy than your DMARC record specifies. This happens when the receiver has local policies (like allowlisting or mailing list detection) that override DMARC.

Subdomain coverage — Whether subdomains have DMARC records or inherit your main domain’s policy.

Monitoring should continue even after you move to enforcement. New third-party services may start sending on your behalf, attackers may try new spoofing techniques, and infrastructure changes can break authentication.

DMARC Best Practices

1. Start with p=none and monitor for at least 2 weeks

Don’t jump straight to enforcement. Collect reports to understand your email ecosystem first.

2. Fix SPF and DKIM issues before enforcing DMARC

DMARC only works if SPF or DKIM pass. Validate your SPF record syntax, ensure all legitimate senders are included, and verify DKIM signing for all outbound mail streams.

3. Set a subdomain policy

Use sp=quarantine or sp=reject to protect subdomains. Otherwise attackers can spoof anything.yourdomain.com even if your main domain is protected.

4. Use the pct tag for gradual rollout

When moving from none to quarantine or reject, start with pct=10 to apply the policy to 10% of traffic. Monitor for problems, then gradually increase to 100.

5. Monitor continuously

DMARC isn’t set-and-forget. New senders, infrastructure changes, and attack patterns evolve. Review reports regularly.

6. Publish DMARC on all domains you own

Even domains that don’t send email should have a DMARC record with p=reject to prevent attackers from using them for spoofing.

7. Consider BIMI once you have p=quarantine or p=reject

BIMI lets you display your brand logo in email clients, but it requires DMARC enforcement. It’s a tangible reward for achieving strong email authentication.

8. Use ARC-aware infrastructure

If you operate a mailing list or forwarding service, implement ARC to preserve authentication results. This prevents DMARC failures for forwarded messages.

9. Validate your DMARC record syntax

Use a DMARC record checker to validate syntax and flag common errors like missing required tags or invalid values.

10. Document all legitimate senders

Keep an inventory of all third-party services that send email on your behalf. When onboarding a new service, ensure it’s configured for SPF or DKIM before it goes live.

DMARC for Cybersecurity

DMARC has become a cornerstone of email security and is increasingly required by compliance frameworks and industry standards:

Business email compromise (BEC) prevention — DMARC blocks exact-domain spoofing, which is used in CEO fraud and vendor payment scams. Attackers can’t send email from your domain if you have p=reject enforced.

Brand protection — Phishing emails that appear to come from your domain damage customer trust. DMARC ensures only authorized senders can use your domain in the From address.

Compliance requirements — DMARC enforcement is required or recommended by frameworks like FedRAMP, NIST, DISA STIG, PCI DSS 4.0 email requirements, and the EU’s NIS2 directive.

Google and Yahoo sender requirements — As of February 2024, bulk senders (5,000+ messages/day) to Gmail or Yahoo must have DMARC enforcement (p=quarantine or p=reject). While not all organizations send bulk mail, this signals that DMARC is becoming baseline infrastructure.

DMARC complements other email security controls like spam filters, malware scanners, and security awareness training. It doesn’t replace them, but it’s the only protocol that gives domain owners control over their namespace and visibility into who is using it.

Frequently Asked Questions

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that tells email receivers how to handle messages that fail SPF or DKIM checks. It builds on SPF and DKIM by adding alignment requirements and reporting, helping domain owners protect their brand from spoofing and phishing attacks.

How does DMARC work?

DMARC works by checking whether an incoming email passes SPF or DKIM authentication and whether the authenticated domain aligns with the domain in the From header. If the email fails these checks, the receiver follows the policy you set in your DMARC record (none, quarantine, or reject). Receivers also send you aggregate reports showing authentication results for messages claiming to be from your domain.

What is the difference between DMARC, SPF, and DKIM?

SPF verifies that an email comes from an authorized IP address. DKIM verifies message integrity with a cryptographic signature. DMARC builds on both by requiring the authenticated domain to align with the visible From address, and it gives domain owners control over what happens when authentication fails. All three protocols work together to prevent email spoofing.

What happens when DMARC fails?

When DMARC fails, the email receiver follows the policy in your DMARC record. With p=none, the message is delivered normally for monitoring. With p=quarantine, it goes to spam. With p=reject, it’s blocked entirely. DMARC failures happen when both SPF and DKIM fail, or when neither passes alignment checks.

Do I need DMARC for my domain?

Yes, especially if you send business email or want to protect your brand. DMARC prevents attackers from sending phishing emails that appear to come from your domain. As of 2024, Google and Yahoo require DMARC for bulk senders (5,000+ messages/day), but all domains benefit from the visibility and protection DMARC provides.

What is a DMARC aggregate report (RUA)?

DMARC aggregate reports are XML files sent daily by email receivers to the address in your rua tag. They show which IP addresses sent email claiming to be from your domain, whether those messages passed SPF and DKIM, and what policy was applied. These reports are critical for understanding your email ecosystem before enforcing DMARC.

How do I set up a DMARC record?

To set up DMARC, add a DNS TXT record at _dmarc.yourdomain.com with a value like ‘v=DMARC1; p=none; rua=mailto:[email protected]’. Start with p=none to collect reports without affecting mail flow. Once you’ve identified all legitimate senders and verified they pass SPF or DKIM, you can move to p=quarantine or p=reject.

Related Protocols

• SPF — Authorizes which servers can send email for your domain
• DKIM — Adds a cryptographic signature to verify message integrity
• ARF — The format used for DMARC forensic reports
• ARC — Preserves authentication results through forwarding chains
• BIMI — Displays your brand logo in inboxes (requires DMARC enforcement)