Email authentication

What is DMARC?

DMARC tells receiving servers what to do when email fails authentication checks. It adds policy and reporting on top of SPF and DKIM, and major mailbox providers now expect it from bulk senders.

Why DMARC matters in 2026

DMARC went from “recommended” to “required” in the space of 18 months:

• Gmail (February 2024): All senders must authenticate with SPF or DKIM. Bulk senders (5,000+ messages/day) must publish a DMARC record with alignment.
• Yahoo (February 2024): Bulk senders must have SPF, DKIM, and a DMARC policy with at least p=none.
• Microsoft Outlook (May 2025): Domains sending 5,000+ messages/day to Outlook.com consumer mailboxes must pass SPF, DKIM, and DMARC or face rejection with 550 5.7.515.

Beyond deliverability, DMARC is increasingly part of security and compliance conversations. NIST SP 800-177 recommends SPF, DKIM, and DMARC as core email authentication mechanisms. In practice, DMARC also comes up frequently in security reviews, cyber insurance questionnaires, and broader compliance discussions.

For MSPs, DMARC is no longer a project you sell — it's a baseline expectation. Clients whose domains lack DMARC enforcement are exposed to spoofing, deliverability failures, and compliance gaps.

How DMARC works

DMARC builds on two existing authentication mechanisms — SPF and DKIM — and adds three things: alignment, policy, and reporting.

Alignment

SPF and DKIM can both pass without DMARC passing. That's because DMARC adds one check that neither protocol has on its own: does the domain that passed authentication match the domain in the visible From: header?

• For SPF, the Return-Path domain must align with the From: domain.
• For DKIM, the d= signing domain must align with the From: domain.
• DMARC requires at least one — SPF or DKIM — to both pass and align.

Alignment can be relaxed (organizational domain match — mail.example.com aligns with example.com) or strict (exact domain match). Relaxed is the default and works for most deployments.

→ For a deeper explanation of alignment and the common pass-pass-fail pattern: DMARC alignment failure

Policy

DMARC is published as a DNS TXT record at _dmarc.yourdomain.com. The p= tag tells receiving servers what to do with messages that fail DMARC:

• p=none — deliver normally, just send reports (monitoring only)
• p=quarantine — route to spam/junk
• p=reject — block delivery entirely

A DMARC record also supports sp= for subdomain policy, pct= for gradual rollout (apply the policy to a percentage of messages), and rua= / ruf= for reporting addresses.

A minimal DMARC record:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

This publishes a monitoring-only policy and starts sending aggregate reports to the specified address.

Reporting

Aggregate reports (RUA) are XML files sent by receiving providers (typically daily) summarizing authentication results for all mail they received from your domain. Each report includes sending IPs, SPF/DKIM pass/fail results, alignment status, and message counts.

RUA reports don't contain message content or personal data — just metadata and counts. They're the primary data source for understanding who's sending as your domain.

Forensic reports (RUF) are copies of individual messages that failed DMARC, potentially including headers and content. Due to privacy concerns, most receiving providers either don't send RUF reports or heavily redact them. RUF is optional and not required for DMARC compliance.

The challenge with aggregate reports is that they arrive as XML that's difficult to read manually. A single domain receiving reports from multiple providers can generate hundreds of XML files per month. This is the core problem DMARC monitoring tools solve.

DMARCit processes your aggregate reports and turns them into a readable sender list with pass/fail status, alignment details, and actionable recommendations.

Moving from p=none to p=reject

DMARC enforcement is a process, not a switch. The standard path:

Phase 1: Monitor (p=none)

Publish a DMARC record at p=none with rua= pointing to your reporting address. Let it run for 2-4 weeks (longer for complex environments). Use the aggregate reports to identify every service sending as your domain and whether each one passes SPF/DKIM with alignment.

During this phase, no mail is blocked. You're gathering data.

Phase 2: Fix authentication gaps

For each sending source that fails DMARC:

• Configure custom DKIM signing for your domain (preferred — survives forwarding)
• Or configure a custom Return-Path under your domain for SPF alignment
• Or move the sender to a subdomain with its own SPF/DKIM

Common third-party senders that need attention: Mailchimp, HubSpot, Salesforce, Zendesk, SendGrid, and any SaaS tool that sends email as your domain. Most start misaligned by default. → See: DMARC alignment failure

Phase 3: Gradual enforcement (p=quarantine)

After fixing known senders, move to p=quarantine. Use pct= for gradual rollout:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com

Start at pct=10, monitor reports for legitimate mail landing in spam, increase to pct=50, then pct=100.

Phase 4: Full enforcement (p=reject)

Once confident all legitimate mail passes, move to p=reject. Apply the same gradual pct= ramp if needed. Set sp=reject for subdomains.

Phase 5: Ongoing monitoring

Even after reaching enforcement, continue monitoring. Mail flows change — new services get adopted, DKIM keys rotate, SPF records drift, vendors change their infrastructure. What passed last month may fail today.

Monitoring-only (p=none) should not be the end state. For most domains, the long-term goal is to move to enforcement once legitimate senders are fully authenticated.

Common DMARC problems and how to fix them

• Alignment failures (pass-pass-fail): SPF and DKIM both pass, but DMARC fails because neither aligned with the From: domain. This is the most common source of confusion. → DMARC alignment failure
• Gmail rejection — 550 5.7.26: The most common DMARC rejection since Gmail's 2024 enforcement changes. → Fix 550 5.7.26
• Outlook rejection — 550 5.7.515: Microsoft's new bulk sender rejection, enforced since May 2025. → Fix 550 5.7.515
• SPF exceeding the 10-lookup limit: A broken SPF record cascades into DMARC failure if DKIM isn't aligned. → SPF PermError
• DKIM body hash failure: The message was modified after signing — a different problem from alignment. → DKIM body hash did not verify
• Stuck at p=none: Many domains publish a DMARC record at p=none and never progress to enforcement. Monitoring-only provides visibility but no protection — spoofed mail is still delivered.
• Subdomain gaps: A domain at p=reject with no sp= policy may leave subdomains unprotected. Set sp=reject or create explicit _dmarc records for subdomains that need different handling.
• Third-party sender friction: Every SaaS tool that sends as your domain needs authentication configured. Vendors are often unfamiliar with DMARC alignment requirements and may provide incomplete setup instructions.

How DMARC connects to SPF, DKIM, and BIMI

DMARC doesn't work alone. It sits on top of SPF and DKIM, and it's the prerequisite for BIMI:

• SPF authorizes which servers can send as your domain. DMARC uses SPF pass + alignment as one path to authentication.
• DKIM cryptographically signs messages. DMARC uses DKIM pass + alignment as the other path — and the one that survives forwarding.
• BIMI displays your brand logo in supported inboxes, but only after DMARC is at enforcement (p=quarantine or p=reject with pct=100).

For most organizations, the practical priority is: get SPF and DKIM working → publish DMARC at p=none → monitor and fix → enforce → then consider BIMI as the visible payoff for the authentication work.

Related content