DMARC認証失敗の原因7選と解決策（2026年ガイド）

29 min readDMARC failures bounce or junk legitimate email — and 9 out of 10 are caused by SPF/DKIM misalignment, third-party senders, or email forwarding. Below, walk through each cause, diagnose which one hit your domain, and fix it today.In May 2025, Microsoft began rejecting emails that fail DMARC checks with error code 550 5.7.515. If you have seen “sending domain does not meet the required authentication level” in your bounce logs, you are dealing with a DMARC failure — and you are not alone.Google and Yahoo reached full enforcement in November 2025, blocking bulk senders who lack proper SPF, DKIM, and DMARC configuration. Microsoft followed with outright rejection for consumer Outlook domains. The era of optional email authentication is over.But DMARC failures do not always mean your configuration is wrong. Email forwarding, third-party sending services, and alignment nuances cause legitimate messages to fail DMARC every day. A marketing email sent through Mailchimp or a transactional receipt routed through SendGrid can pass SPF and DKIM individually yet still fail DMARC because of a domain mismatch the sender never knew existed.According to Validity’s analysis of 22 million sending domains, 84% have no DMARC record at all (Validity, November 2024). Among those that do, alignment issues — not missing records — are the leading cause of failure.By the end of this guide, you will understand how to read DMARC aggregate reports, identify which of the seven most common failure causes applies to your domain, and implement platform-specific fixes for Google Workspace, Microsoft 365, and popular ESPs like SendGrid, Mailchimp, and Amazon SES.If you are starting from scratch, our DMARC setup guide walks through initial configuration. This guide focuses on diagnosing and fixing failures after your record is already published.What Is a DMARC Failure?DMARC stands for Domain-based Message Authentication, Reporting & Conformance, defined in RFC 7489. It builds on two existing protocols — SPF and DKIM — by adding a critical layer: alignment. (Note: DMARCbis, the successor to RFC 7489, is in the final stages of IETF publication as of 2026. The core alignment and policy mechanisms described in this guide remain unchanged.)SPF and DKIM can both pass their individual checks, yet DMARC can still fail. That is because DMARC does not just check whether authentication succeeded — it checks whether the authenticated domain matches the domain in the From header your recipient sees.When you receive an email, the receiving server adds an Authentication-Results header that looks like this:In this example, SPF passed (the sending IP is authorized by bounces.esp.com) and DKIM passed (the signature matches esp.com). But DMARC failed because neither bounces.esp.com nor esp.com aligns with the From domain example.com.SPF and DKIM can pass authentication but still fail DMARC alignment when the authenticated domain does not match the From header.DMARC has three possible outcomes:Pass — at least one of SPF or DKIM both passed and is aligned with the From domainFail — neither SPF nor DKIM passed with alignmentNone — no DMARC record exists for the domainA DMARC failure does not automatically mean the message is blocked. The outcome depends on your p= policy tag:With p=none, receivers only report failures.With p=quarantine, they route failing messages to spam.With p=reject, they block them outright.Google reported 265 billion fewer unauthenticated messages in 2024 — a 65% reduction — after enforcing authentication requirements for bulk senders (Google/M3AAWG, October 2024). That enforcement is what makes understanding DMARC failures urgent: receivers are now acting on your policy.You can check your DMARC record with our free DMARC checker to see your current policy, alignment settings, and whether aggregate reports are configured.The 7 Most Common Causes of DMARC FailuresBefore diving into each cause, here is the full list. Most domains encounter one or two of these; complex environments may face several simultaneously.Domain alignment failures — SPF or DKIM passes, but the authenticated domain does not match the From headerThird-party email services not configured — Mailchimp, SendGrid, HubSpot, or other services send on your behalf without proper SPF/DKIM setupEmail forwarding breaks SPF — forwarded messages change the sending IP, invalidating SPFMissing or misconfigured DKIM keys — selector typos, key rotation gaps, or DNS propagation delaysSPF 10-lookup limit exceeded — too many include: mechanisms cause a PermErrorDMARC record syntax errors — typos, missing tags, or invalid values prevent policy parsingSubdomain policy inheritance — subdomains inherit the parent domain’s strict policy unexpectedlyUnderstanding why DMARC is failing requires knowing which of these causes applies to your situation. The diagnostic approach is the same every time: check your aggregate reports, identify the failing sending source, and trace the authentication chain.Use this decision tree to identify which DMARC failure cause applies to your domain.DMARCguard’s sender identification feature names your sending sources — you see “Mailchimp” or “Amazon SES” instead of raw IP addresses — which cuts diagnostic time from hours to minutes.Cause #1 — Domain Alignment FailuresThis is the most common DMARC failure and the most misunderstood. Your SPF check passes, your DKIM check passes, but DMARC still fails. The reason: alignment.RFC 7489 Section 3.1 defines two types of alignment (see our DMARC protocol guide for the full specification breakdown):SPF alignment requires the domain in the Return-Path header (also called the envelope sender or smtp.mailfrom) to match the domain in the From header. If your From address is [email protected] but the Return-Path is [email protected], SPF passes for sendgrid.net but is not aligned with example.com.DKIM alignment requires the d= domain in the DKIM signature to match the From header domain. If the DKIM signature uses d=sendgrid.net but the From header says example.com, DKIM passes but is not aligned.DMARC supports two alignment modes, controlled by the aspf= and adkim= tags:Relaxed (aspf=r, the default): organizational domain match. mail.example.com aligns with example.com.Strict (aspf=s): exact domain match only. mail.example.com does not align with example.com.Consider a real-world scenario: you send transactional emails through SendGrid. The email From header shows [email protected], but SendGrid sets the Return-Path to [email protected] and signs with d=sendgrid.net.Both SPF and DKIM pass for SendGrid’s domain, but neither is aligned with example.com. Result: SPF and DKIM pass but DMARC fails.How to fix alignment failures:Configure DKIM with your own domain at the ESP. Most ESPs support custom DKIM signing where d=example.com instead of d=esp.com. This is the preferred fix because it survives forwarding.Set up a custom Return-Path at the ESP. SendGrid calls this “Authenticated Domain,” Mailchimp calls it “Verified Sending Domain.” This aligns SPF with your From domain.Check your alignment mode. If you switched from aspf=r to aspf=s (strict), subdomains no longer align with the organizational domain. Unless you have a specific reason for strict alignment, keep the default relaxed mode.You only need one mechanism (SPF or DKIM) to be aligned for DMARC to pass. Most ESP configurations rely on DKIM alignment because it is more resilient to forwarding and does not depend on the Return-Path.Cause #2 — Third-Party Email Services Not ConfiguredThis is the most common failure for organizations deploying DMARC for the first time. Marketing platforms, CRMs, ticketing systems, and transactional email services all send messages using your domain in the From header. If they are not authorized in your SPF record and do not have DKIM selectors configured, every message they send will fail DMARC.Each third-party service requires three things:An SPF include: mechanism in your DNS recordDKIM selectors added to your DNSYour custom domain configured as the sending domain inside the serviceHere are the DNS configurations for the most common platforms:ServiceSPF IncludeDKIM SetupMailchimpinclude:servers.mcsv.net3 CNAME selectors (k1, k2, k3)SendGridinclude:sendgrid.netAuthenticated Domain (2 CNAMEs)Amazon SESinclude:amazonses.comEasy DKIM (3 CNAME records)HubSpotinclude:_spf.hubspotemail.net2 DKIM CNAME recordsSalesforce Marketinginclude:exacttarget.comCustom sender profileESP DNS Configuration RequirementsA cautionary case study: the UK National Health Service delayed DMARC enforcement on NHSmail for six months because local NHS trusts had not configured third-party clinical email systems. The delay left the nhs.net domain vulnerable to spoofing throughout that period, with patient care communications at risk (Digital Health News, January 2020).How to discover unknown senders: Parse your DMARC aggregate reports. Every receiver that processes your email (Gmail, Outlook, Yahoo) sends daily XML reports listing every IP address that sent mail using your domain. Look for rows where dmarc=fail — the <source_ip> field tells you which server sent the message. Reverse DNS lookup on that IP often reveals the sending service.If you see a SendGrid DMARC fail in your reports, configure your Authenticated Domain in SendGrid’s dashboard and add the required DNS records. The same pattern applies to every ESP: identify the source, then add SPF and DKIM records for that service.Cause #3 — Email Forwarding Breaks SPFEmail forwarding is a protocol-level problem that no amount of configuration on your side can fully prevent. When someone forwards your email — through a university alumni address, a personal Gmail rule, or a corporate mail relay — the sending IP changes to the forwarder’s server, but the Return-Path stays yours.The receiving server performs an SPF check: “Is this IP authorized to send for example.com?” The forwarder’s IP is not in your SPF record, so SPF fails. If the forwarder also modifies the message — adding a footer, changing headers, or altering the subject line — the DKIM signature invalidates too. Both mechanisms fail, and DMARC fails with them.When email is forwarded, the sending IP changes to the forwarder's server, invalidating SPF. If the message body is also modified, DKIM breaks too.This is precisely what happened in April 2014 when Yahoo and AOL published p=reject for their consumer domains. Thousands of mailing lists globally broke overnight — every email from an @yahoo.com or @aol.com user sent through a mailing list was rejected by receiving servers worldwide.The Mailman project had to release version 2.1.16 with DMARC compatibility features that rewrote the From header. The IETF documented the collateral damage in RFC 7960 (PCWorld, April 2014).Fixes for forwarding-related DMARC failures:Rely on DKIM alignment. If your DKIM signature survives forwarding (the message was not modified), DMARC passes via DKIM even though SPF fails. This is why DKIM alignment is the preferred authentication mechanism for most organizations.SRS (Sender Rewriting Scheme): Forwarders can rewrite the Return-Path to their own domain, which fixes SPF at the cost of rewriting the envelope sender. Many mail servers support SRS natively.For mailing list operators: Modern list software (Mailman 3, Sympa) supports DMARC mitigations — either rewriting the From header or wrapping the original message.How to diagnose forwarding failures: In your aggregate reports, look for dmarc=fail entries where the <source_ip> belongs to Google, Microsoft, or another major provider. Low message counts (1-5 messages) from these IPs almost always indicate forwarding, not spoofing. High counts (thousands) from unknown IPs suggest an actual spoofing attempt.DMARCguard is the only DMARC monitoring tool that natively supports ARC chain analysis. You can trace exactly where in the forwarding chain authentication broke, and whether the ARC seal was valid — giving you confidence to distinguish legitimate forwards from spoofing attempts.Cause #4 — Missing or Misconfigured DKIM KeysDKIM (RFC 6376) works by signing outgoing messages with a private key stored on your mail server and publishing the corresponding public key in DNS. When these two halves get out of sync, DMARC verification fails.Common DKIM failures:Key rotation not synced. You generated a new private key but did not update the DNS TXT record (or vice versa). The signature references a public key that no longer matches.Selector typo. The email header references s=selector1 but your DNS record is published at selector2._domainkey.example.com. One character difference causes a complete failure.DNS propagation delay. You added the DKIM TXT record, but it has not propagated globally yet. This typically resolves within 24-48 hours.Key length too short. RSA keys shorter than 1024 bits are deprecated. The recommended minimum is 2048 bits (RFC 8301, which updates RFC 6376). Some older configurations still use 512-bit or 1024-bit keys.How to diagnose DKIM issues:If the response is NXDOMAIN, the selector does not exist in DNS. If it returns a record, verify the p= value (public key) matches your server configuration and that the key length is 2048 bits.A DKIM DNS record contains the version, key type, and public key. The selector in the email header must match the DNS record location.Platform-specific DKIM setup:Google Workspace: Admin Console > Apps > Google Workspace > Gmail > Authenticate Email. Generate a new DKIM key (select 2048-bit), copy the TXT record, add it to your DNS, then click “Start Authentication.”Microsoft 365: Microsoft Defender portal > Email & collaboration > Policies & rules > Threat policies > Email authentication settings. Select your domain, enable DKIM, and copy the two CNAME records (selector1._domainkey and selector2._domainkey) to your DNS.Self-hosted (Postfix with OpenDKIM):This generates selector1.private (private key) and selector1.txt (DNS record). Add the TXT record to DNS and configure OpenDKIM to sign with the private key.You can verify your DKIM configuration with our free DKIM checker, which validates the selector, key length, and DNS record format.Cause #5 — SPF 10-Lookup Limit ExceededRFC 7208 Section 4.6.4 imposes a hard limit: SPF evaluation must not require more than 10 DNS lookups. Every include:, a, mx, ptr, exists, and redirect= mechanism counts as one lookup. When you exceed 10, the SPF result is PermError — a permanent error that causes SPF to fail, which in turn causes DNS authentication DMARC fail if DKIM is also not aligned.The limit gets hit fast:ServiceLookupsRunning TotalGoogle Workspace22Mailchimp35HubSpot38Zendesk210Salesforce313SPF Lookup Count by ServiceAt 13 lookups, SPF returns PermError. Every message evaluated against this record fails SPF regardless of whether the sending IP is authorized.From our scan of 5.5 million Tranco domains, 4.8% of SPF-enabled domains (148,655 of 3,077,219) exceed the 10-lookup limit (DMARCguard Scanner, February 2026). That is 148,655 domains where SPF is effectively broken.How to diagnose:Then recursively check each include: domain. Count every include:, a, mx, redirect=, and exists: mechanism across all nested records. Our free SPF checker automates this and flags lookup limit violations instantly.Fixes:Remove unused includes. Audit your SPF record. If you discontinued a service six months ago, remove its include:. This is the lowest-effort, highest-impact fix.Use IP addresses. Replace include: mechanisms with ip4: or ip6: entries where the service uses stable IP ranges. IP mechanisms do not count toward the 10-lookup limit. Only do this for services with published, stable IP ranges.Subdomain splitting. Move some services to subdomains. Marketing emails send from marketing.example.com with its own SPF record, transactional emails from notify.example.com. Each subdomain gets its own 10-lookup budget.SPF flattening (use with caution). Flattening replaces include: mechanisms with hardcoded IP addresses. The risk: when the service provider changes their IPs, your SPF record breaks silently. If you flatten, you need automated monitoring to detect IP changes.A frequent question from administrators: “Is SPF flattening safe?” The pragmatic answer is no — it trades one problem (lookup limit) for another (maintenance burden). Subdomain splitting is more durable and does not require ongoing monitoring.For a deeper dive into SPF PermError — all five root causes, diagnostic steps, and platform-specific fixes — see our dedicated SPF PermError troubleshooting guide.Cause #6 — DMARC Record Syntax ErrorsA DMARC record is a DNS TXT record published at _dmarc.example.com. It uses a tag-value format defined in RFC 7489 Section 6.3. Syntax errors prevent receiving servers from parsing your policy, which means the DMARC policy is effectively not enabled — even though a record technically exists.Common syntax errors:Missing v=DMARC1 tag. This must be the first tag in the record. Without it, receivers ignore the entire record.Invalid policy value. Only three values are valid: none, quarantine, reject. A typo like p=block or p=deny is treated as no policy.Multiple DMARC records. Only one TXT record is allowed at _dmarc.example.com. If two records exist, receivers treat it as ambiguous and apply no policy.Missing mailto: prefix in rua/ruf. The report address must use the mailto: URI scheme:Missing semicolons. Tags must be separated by semicolons. Some DNS providers strip trailing semicolons, which can break parsing.Spaces within tag values. Tags like pct = 50 (with spaces around =) may cause parsing failures depending on the receiver.Oracle once published an SPF record with a syntax error — missing whitespace between IP addresses — causing authentication failures for their customers. The fix was quick, but as DMARC Advisor noted, “it can occur over a much longer timeframe, increasing the damage.”A correct, complete DMARC record looks like this:Use our free DMARC checker to validate your record syntax, identify missing tags, and generate a corrected record if needed.Cause #7 — Subdomain Policy InheritanceBy default, subdomains inherit the parent domain’s DMARC policy unless they have their own record published at _dmarc.subdomain.example.com. This catches many organizations off guard when they move to enforcement.The sp= tag in the parent record controls subdomain policy separately:Without sp=, subdomains inherit the p= value. If your root domain has p=reject and marketing.example.com sends bulk email through Mailchimp, those messages hit the reject policy. Your marketing team’s email deliverability tanks and they may not realize why — the DMARC quarantine or reject policy is not enabled at the subdomain level, but it is inherited from the parent.How to diagnose subdomain failures: Check your aggregate reports for the <header_from> field. If it shows a subdomain (e.g., newsletter.example.com) and the disposition is reject, that subdomain is inheriting the parent’s strict policy.Fixes:Publish an explicit subdomain DMARC record. Create _dmarc.marketing.example.com with its own policy. This overrides inheritance.Use sp=none or sp=quarantine in the parent record. This gives subdomains a softer policy while the root domain enforces p=reject.Audit all subdomains that send email before enforcing p=reject at the root. Check DNS for any subdomain with MX records or SPF records. If it sends mail, it needs its own DMARC configuration or you need to verify its authentication chain.A common question from administrators: “Why does my DMARC report show failures from subdomains I do not use?” Two possibilities: either spoofers are targeting unused subdomains (common for phishing), or forgotten internal systems are still sending from those subdomains. Either way, subdomain-specific DMARC records at p=reject protect unused subdomains from abuse.How to Read DMARC Aggregate Reports to Diagnose Failure

※ 著作権に配慮し、引用は冒頭3段落までです。続きは元記事をご覧ください。