DMARC Checker

A DMARC record (Domain-based Message Authentication, Reporting, and Conformance) is a DNS TXT entry that instructs receiving mail servers how to handle email that fails SPF or DKIM authentication. Defined in RFC 7489, DMARC builds on top of both standards to give domain owners policy control and daily reporting. This checker performs a live DNS lookup at _dmarc.yourdomain.com and validates the record against published best practices. Grading the policy strength, confirming report URIs are configured, and flagging every issue with a plain-language explanation and a specific fix.

The most critical tag is p=. A p=none record collects data but provides zero protection. Spoofed emails still reach inboxes. A p=quarantine record routes failures to spam. A p=reject record refuses unauthenticated messages outright and is the gold standard for domain protection. Most deployments start at p=none with rua= configured, review aggregate reports for two to four weeks to identify all legitimate sending sources, then step through pct= rollout increments until full p=reject enforcement is achieved.

Aggregate reports (rua=) are a non-negotiable part of safe DMARC deployment. They are XML summaries sent daily by major mailbox providers, including Gmail, Outlook, and Yahoo, showing every source sending email from your domain and whether each is passing or failing authentication. Without rua= in place, enforcing quarantine or reject risks blocking legitimate email from services you have not yet identified, such as marketing platforms, helpdesk tools, or CRMs.

Since February 2024, both Google and Yahoo have enforced mandatory DMARC for bulk senders delivering more than 5,000 messages per day to Gmail. Even below that threshold, DMARC is increasingly a baseline deliverability signal. A domain without it is scored lower by spam filters regardless of content quality. And for domains 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 is a hard prerequisite.

Email spoofing remains one of the most common vectors in phishing attacks. When a domain has no DMARC record, or a weak p=none policy, anyone can send email that appears to come from that domain. Customers, partners, and employees receive convincing fakes with no technical indicator that anything is wrong. DMARC enforcement at p=reject closes this gap completely by instructing every major receiving mail server to discard unauthenticated messages before they reach the inbox.

Most domain owners set up a DMARC record once and assume the job is done. In reality, email infrastructure changes constantly. New marketing platforms, transactional email services, CRMs, and helpdesk tools are added over time. Each requiring its own SPF authorization and DKIM signing configuration. A sending source that was not present when DMARC was first deployed can silently fail authentication for months without anyone noticing. Until a support ticket arrives asking why emails are going to spam.

Running this checker takes under ten seconds. It surfaces problems immediately: a missing rua= address that means you have been flying blind on authentication failures, a pct= value below 100 left over from a rollout that was never completed, or a subdomain policy (sp=) that is weaker than the main domain policy. Catching these issues early prevents deliverability problems, protects your sender reputation, and keeps your domain out of phishing campaigns that damage customer trust.

For teams managing multiple domains, including legacy, parked, or acquired domains, regular DMARC checks across the entire portfolio are essential. Each unprotected domain is an attack surface. A quick check with this tool confirms every domain has at minimum a p=reject record even if it sends no email, eliminating entire categories of brand impersonation risk.

Using the tool is straightforward. Here is the full process from start to finish:

1. Enter your domain. Type your domain name (e.g. example.com) or paste a full email address from that domain. The tool strips the local part and protocol automatically, so email@example.com and https://example.com both resolve to example.com.

2. Click Check DMARC. The tool performs a live DNS-over-HTTPS lookup at _dmarc.yourdomain.com via Cloudflare, with Google DoH as a fallback. Nothing is sent to Best-TempMail servers. The query goes directly from your browser to the DNS resolver.

3. Review your overall grade. The result header shows Valid, Warnings, Invalid, or Missing alongside the raw record string. This tells you at a glance whether your domain has DMARC protection in place.

4. Read each check. Expand each pass/warn/fail card to understand what is correct, what needs attention, and what the recommended fix is. Pay particular attention to any fail badges. These represent gaps that actively weaken or invalidate your DMARC posture.

5. Act on the recommendations. Each failed or warned check includes a specific remediation step. Log into your DNS provider, update the record, and re-run the checker after a few minutes to confirm the change has propagated.

Most DMARC issues fall into a small number of patterns. Here are the most common failures, why they happen, and what to do about each one.

DMARC does not work in isolation. It is the policy layer that sits on top of two older authentication standards, SPF and DKIM, and uses them as evidence to make enforcement decisions. Understanding how all three interact is essential for diagnosing failures.

SPF (Sender Policy Framework) is a DNS TXT record that lists every IP address and mail server authorized to send email for your domain. When a receiving server gets a message, it checks whether the sending IP is in the SPF record for the Return-Path (envelope) domain. If it is, SPF passes. The limitation: SPF only checks the envelope, the hidden Return-Path used for bounces, not the From: address visible to recipients. Forwarded email and shared-infrastructure ESPs commonly break SPF alignment. You can check and flatten your SPF record using the dedicated tool.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages. The sending server signs the message with a private key, and the receiving server verifies the signature using a public key published in DNS. Because the signature is embedded in the email header, it survives forwarding. Which is why DKIM alignment is often more reliable than SPF alignment for third-party sending platforms. Verify your DKIM configuration with the DKIM Analyzer.

DMARC alignment is the bridge. DMARC passes only when at least one of the following is true: the SPF-authenticated domain aligns with the From: header domain, or the DKIM signing domain (d=) aligns with the From: header domain. 'Align' means either an exact match (strict mode, adkim=s / aspf=s) or a domain-parent match (relaxed mode, the default). A message that passes SPF on its own but has a mismatched Return-Path domain, which is the norm for SendGrid, Mailchimp, and similar platforms, will fail DMARC alignment unless DKIM is also correctly configured.

Beyond the core three, MTA-STS (Mail Transfer Agent Strict Transport Security) and BIMI build on DMARC to add transport security and brand display respectively. MTA-STS prevents SMTP downgrade attacks. BIMI displays your verified logo in supporting email clients. Both require DMARC to be in place at p=quarantine or p=reject before they can function.