DMARC Fail — What It Means and How to Fix It

March 4, 2026 · 7 min read · Tomas Hojgr · dmarc

dmarc email-authentication troubleshooting

What DMARC Fail Means

DMARC fail occurs when an email sent from your domain does not pass authentication checks on the receiving server. The receiver determined that the message does not meet your DMARC policy requirements — either SPF failed, DKIM failed, or the authentication results did not align with the domain in the From header.

The consequences depend on your published policy:

Policy	What happens on DMARC fail
`p=none`	Email is delivered; the receiver only sends a report about the failure
`p=quarantine`	Email lands in spam or quarantine
`p=reject`	Email is rejected at SMTP level — never delivered

With p=none, DMARC failures do not affect delivery, but they signal a configuration problem. With p=quarantine or p=reject, DMARC failures cause legitimate emails — invoices, notifications, marketing campaigns — to go undelivered.

How DMARC Evaluates an Email

DMARC does not work in isolation. It ties SPF and DKIM results to the From header domain through a mechanism called alignment.

An email passes DMARC if it meets at least one of these conditions:

SPF pass + SPF alignment — the domain from the envelope sender (Return-Path) matches the From header domain
DKIM pass + DKIM alignment — the domain in the DKIM signature (d=) matches the From header domain

Alignment has two modes:

Relaxed (default, aspf=r / adkim=r) — organizational domain match is sufficient. An email from news.example.com passes alignment for example.com.
Strict (aspf=s / adkim=s) — exact domain match required. An email from news.example.com fails alignment for example.com.

DMARC fail does not simply mean "SPF or DKIM failed." It can occur even when both SPF and DKIM pass — if neither result is aligned with the From header domain.

Common Causes of DMARC Failure

Missing or Incomplete SPF Record

The sending server is not included in your domain's SPF record. This typically happens when you add a new service (helpdesk, invoicing system, CRM) that sends emails from your domain, but its IP address or include mechanism is missing from SPF.

v=spf1 include:_spf.google.com -all

If Mailchimp sends emails on behalf of example.com and include:servers.mcsv.net is missing from the record, SPF will fail for those messages.

Missing or Incorrect DKIM Signature

The email has no DKIM signature, or it is signed with a key from a different domain. Without DKIM, the email relies entirely on SPF — and if SPF also fails (e.g., due to forwarding), DMARC has nothing to evaluate as pass.

Check your DKIM record and verify that every service sending email from your domain signs with your domain's DKIM key (not the provider's default domain).

Alignment Failure

SPF and DKIM can both technically pass, yet DMARC still fails. Example:

From header: info@example.com
Return-Path: bounce@mailservice.com (SPF pass for mailservice.com, but alignment fail for example.com)
DKIM signature: d=mailservice.com (DKIM pass for mailservice.com, but alignment fail for example.com)

Both checks passed — but neither relates to the example.com domain. DMARC evaluates the message as fail.

The fix: configure the sending service to use your domain in the Return-Path (SPF alignment) or in the DKIM signature (d=example.com). Most modern ESPs (email service providers) support both.

SPF DNS Lookup Limit Exceeded

SPF has a limit of 10 DNS lookups per record (RFC 7208, Section 4.6.4). The mechanisms include:, a:, mx:, ptr:, exists: and the redirect= modifier each generate a DNS lookup. Exceeding the limit causes a PermError — SPF evaluates as failure regardless of whether the sender is authorized.

Check your lookup count with our SPF analyzer. If you exceed the limit, consider SPF flattening or consolidating sending services.

Email Forwarding

Forwarding is a classic SPF problem. When a server forwards an email, the sending IP address changes — the new IP is not in the original domain's SPF record, and SPF fails. If the email lacks a valid DKIM signature aligned with the From header domain, DMARC fails as well.

DKIM is more resilient — the signature survives forwarding as long as the forwarding server does not modify the body or signed headers. This makes DKIM critical for reliable DMARC authentication.

Receiving servers that support ARC (Authenticated Received Chain) can verify the authentication chain across forwarding hops. ARC adoption is growing but not yet universal.

Third-Party Services Without Proper Configuration

SaaS tools (helpdesks, CRMs, marketing platforms) often send emails "on behalf of" your domain. If they do not have DKIM configured with your domain and their sending servers are not in your SPF record, DMARC failure is inevitable.

Common services where this occurs:

Helpdesk and ticketing (Freshdesk, Zendesk)
CRM systems (HubSpot, Salesforce)
Marketing tools (Mailchimp, ActiveCampaign)
Transactional email (SendGrid, Amazon SES, Mailgun)
Invoicing and accounting systems

For each service, verify that it supports custom DKIM domains and is included in your SPF record.

How to Identify the Cause of DMARC Failure

DMARC Reports

Aggregate DMARC reports (rua) are the primary diagnostic tool. They contain sending server IP addresses, SPF and DKIM check results, and alignment status.

If your reports are directed to SPF Monitor, you get a clear visualization — no need to manually parse XML. Look for records with dmarc=fail and identify:

Sender IP address — does it belong to your server or service? Or is it unknown?
SPF result — pass, fail, or permerror?
DKIM result — pass, fail, or missing?
Alignment — do the SPF/DKIM domains match the From header?

If you have not set a rua= tag in your DMARC record, you have no data to work with. Add a reporting address — without it, diagnosis is impossible. See How to set up a DMARC record for the setup process.

Email Headers

For a specific email that failed, check the Authentication-Results header. It contains the SPF, DKIM, and DMARC check results performed by the receiving server:

Authentication-Results: mx.google.com;
  dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.com;
  spf=pass (google.com: domain of bounce@mailservice.com designates 192.0.2.1 as permitted sender) smtp.mailfrom=mailservice.com;
  dkim=pass header.i=@mailservice.com header.s=selector1

In this example, SPF and DKIM both passed — but for the domain mailservice.com, not for example.com in the From header. Alignment failed, hence DMARC fail.

Common Error Messages

When a DMARC reject occurs, the receiver returns an SMTP error response. The most common formats:

550 5.7.1 Email rejected per DMARC policy — standard rejection per the sender's DMARC policy
550 5.7.0 Email rejected per DMARC policy for example.com — explicitly names the domain whose policy caused the rejection
550 5.7.26 This message fails authentication checks — Gmail-specific error message

The 550 status code indicates permanent rejection — the sending server should not retry.

What to Do When DMARC Fails

Systematic Approach

Identify the source — from DMARC reports or email headers, determine which server sent the email and why authentication failed.
Distinguish legitimate senders from spoofing — if the IP address belongs to your service, it is a configuration issue. If unknown, it is likely spoofing — and DMARC is working as intended.
Fix the configuration based on the failure type:
- SPF fail → add the sending server to your SPF record
- DKIM fail → configure DKIM signing with your domain for the service
- Alignment fail → set up a custom domain in the Return-Path or DKIM signature at the sending service
- SPF PermError → reduce DNS lookups below the limit of 10
Verify the fix — after changing DNS records, wait for propagation (minutes to hours) and check with the SPF, DKIM, and DMARC analyzers.
Monitor reports — confirm in subsequent DMARC reports that the failures have stopped.

When DMARC Fail Is Expected

Not every DMARC failure requires a fix. If an unknown IP address sends emails using your domain and you do not use that service, it is a spoofing attempt. DMARC is doing exactly what it should — protecting your domain.

Preventing DMARC Failures

Before deploying a new sending service, always add its records to SPF and configure DKIM first. Only then start sending emails.
Monitor continuously — check DMARC reports regularly. Configurations change, services add new sending servers, DKIM keys expire.
Keep your SPF record under the limit — verify DNS lookup count with the SPF analyzer after every change.
Prefer DKIM — DKIM is more resilient than SPF, survives forwarding, and has no lookup limit. Configure DKIM with your own domain for every sending service.
Start with p=none — if you are just deploying DMARC, begin with a monitoring policy. Tighten only after thorough report analysis. See How to set up a DMARC record for the full process.

Run a complete analysis of your domain to uncover SPF, DKIM, and DMARC configuration issues in one place — including alignment and DNS lookup limits.