DMARC Analyzer

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS-based email authentication protocol defined in RFC 7489 that lets domain owners specify what receiving mail servers should do when an email fails SPF or DKIM checks. Published as a TXT record at _dmarc.yourdomain.com, a DMARC record defines the policy (none, quarantine, or reject), where to send authentication failure reports, how strictly the sending domain must match the authenticated domain, and how aggressively the policy should be applied during a phased rollout.

DMARC is the capstone of the email authentication stack. SPF authorizes which servers are allowed to send on behalf of your domain. DKIM cryptographically signs messages so recipients can verify they were not altered in transit. DMARC ties these together with alignment requirements, the domain in the From: header must match the domain authenticated by SPF or DKIM, and adds a reporting mechanism that gives you daily visibility into what is happening to email sent from your domain across the internet.

This analyzer queries your domain's DMARC record in real time using Cloudflare DNS-over-HTTPS and decodes every tag. It assesses your policy strength, checks whether aggregate reports are configured (essential for visibility into authentication failures), identifies partial rollout configurations (pct= below 100%), evaluates alignment modes (adkim= and aspf=), and surfaces less-visible tags like fo= failure options and ri= report interval that most tools ignore. Each finding includes plain-English guidance so you know exactly what needs to change and why.

Since February 2024, Google and Yahoo require DMARC for bulk senders delivering more than 5,000 messages per day to Gmail. Even below that threshold, DMARC is a baseline deliverability signal. Domains without it are scored lower by spam filters. For organizations targeting BIMI (Brand Indicators for Message Identification), which displays your logo next to emails in Gmail and Apple Mail, a policy of p=quarantine or p=reject with pct=100 is a hard prerequisite. This analyzer identifies exactly where your current configuration stands and what steps remain.

Publishing a DMARC record once and never revisiting it is one of the most common email security gaps. Email infrastructure is not static. Marketing platforms, CRM tools, helpdesk systems, and transactional email services are added and changed regularly. Each new sending source needs to be authorized in SPF and signed with DKIM before the DMARC policy can safely be enforced. A quarterly DMARC analysis confirms that nothing has broken and that the policy is still covering all failure scenarios correctly.

The most dangerous gap is a domain stuck at p=none. This is the monitoring-only policy that most deployments start with. And many never leave. A p=none record collects data but provides zero protection. Anyone can forge the From: address for that domain and the message will reach the inbox without any authentication enforcement stopping it. Running this analyzer surfaces whether a domain is genuinely protected or merely has the appearance of DMARC coverage.

Beyond enforcement, the analyzer highlights missing rua= addresses. A surprisingly common omission. Without aggregate reports, you have no window into what is happening to email from your domain. You cannot tell which sending sources are passing, which are failing, or whether a legitimate service has started failing authentication after a configuration change. Setting rua= costs nothing and takes thirty seconds; the daily XML reports it generates are the foundation of any DMARC improvement program.

For domain portfolios, including acquired, legacy, or parked domains, this analyzer gives you a quick read on each domain's posture without requiring access to the DNS panel. Security teams, email deliverability specialists, and IT administrators regularly use it to audit domains they did not originally configure and to confirm that partner or vendor domains meet baseline authentication standards before an email integration goes live.

Most DMARC issues fall into a small number of patterns. The analyzer flags them. Here is what each one means and what to do about it.

The DMARC record this analyzer parses does not operate in isolation. It is the policy and reporting layer built on top of two underlying standards. Understanding all three together is essential for diagnosing failures and knowing which tags to fix first.

SPF (Sender Policy Framework) is a DNS TXT record published at your root domain that lists which IP addresses and mail servers are authorized to send email on behalf of your domain. When a receiving server gets a message, it checks the sending IP against the SPF record for the Return-Path (envelope) domain. The limitation: SPF only validates the envelope sender, the hidden address used for bounces, not the visible From: header. This is why ESP-generated Return-Path addresses create alignment failures even when SPF technically passes. You can inspect and flatten your SPF record using the dedicated tool.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages using a private key held by the sending server. The receiving server retrieves the corresponding public key from DNS and verifies the signature. Because the DKIM signature is embedded in the email header and is based on the d= domain you control, it survives forwarding and is unaffected by the ESP's Return-Path infrastructure. Making it the more reliable alignment mechanism for third-party senders. Verify your DKIM configuration with the DKIM Analyzer.

DMARC alignment is the bridge. A message passes DMARC when at least one authentication mechanism passes with alignment to the From: header domain. In relaxed mode (adkim=r / aspf=r, both defaults), a subdomain match is sufficient. In strict mode (adkim=s / aspf=s), an exact match is required. The analyzer highlights your current alignment settings and flags if strict mode could be causing unexpected failures.

Two additional standards build on a working DMARC deployment: MTA-STS (Mail Transfer Agent Strict Transport Security) prevents SMTP downgrade attacks by requiring TLS on inbound connections, and BIMI (Brand Indicators for Message Identification) displays your verified brand logo next to emails in supporting clients including Gmail and Apple Mail. Both require DMARC at p=quarantine or p=reject before they can be configured. The DMARC Checker gives you a fast pass/warn/fail health summary if you need a quicker read on policy enforcement before doing a full tag-level analysis here.