Skip to main content
Home/Resources/Tools/DMARC Checker

Free tool

Free DMARC Checker

Enter a domain to look up and test its DMARC record. The checker reads the TXT record at _dmarc.yourdomain.com, validates every tag, explains the policy in plain language, and flags the alignment and reporting gaps that let spoofed mail through. Free, instant, no signup.

Automate everything

InboxKit automatically configures DMARC, SPF, DKIM, and BIMI for all your domains.

Get Started

Overview

What is DMARC?

Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication protocol that builds upon SPF and DKIM to give domain owners policy control over how receiving servers should handle emails that fail authentication checks. It is the most important email security protocol for preventing domain spoofing and phishing attacks.

DMARC works by publishing a DNS TXT record at _dmarc.yourdomain.com that specifies your authentication policy and reporting preferences. When a receiving server processes an email from your domain, it checks SPF and DKIM results, verifies alignment with the From header domain, and applies your DMARC policy if both authentication methods fail.

Record format

What is a DMARC record?

A DMARC record is a DNS TXT record that defines your email authentication policy. It consists of several key tags:

Version

v=DMARC1

Required version tag identifying the record as DMARC

Policy

p=reject

How to handle failures: none, quarantine, or reject

Reporting

rua=mailto:

Email address to receive aggregate authentication reports

Example DMARC Record

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r

Validation

What our DMARC checker validates

Our free DMARC checker performs a comprehensive analysis of your domain's DMARC configuration:

DNS Record Presence

Verifies that a DMARC TXT record exists at _dmarc.yourdomain.com

Record Syntax

Validates the DMARC record format including version and required tags

Policy Analysis

Evaluates your p= policy level (none, quarantine, reject)

Subdomain Policy

Checks sp= tag for subdomain-specific policy configuration

Alignment Settings

Reviews adkim= and aspf= alignment mode (relaxed vs strict)

Reporting Setup

Validates rua= and ruf= reporting email addresses

Implementation

DMARC implementation & policy levels

Implementation Steps

1. Setup SPF and DKIM

Ensure proper SPF and DKIM authentication before implementing DMARC.

2. Start with p=none

Monitor email flows for 2-4 weeks to understand your ecosystem.

3. Analyze reports

Review aggregate reports to identify legitimate vs. fraudulent sources.

4. Enforce gradually

Move to quarantine, then reject using percentage controls (pct=).

Policy Levels

None (p=none)

Monitor mode -- collect data without affecting email delivery.

Quarantine (p=quarantine)

Failed emails sent to spam folder for recipient review.

Reject (p=reject)

Maximum protection -- unauthorized emails are blocked completely.

Percentage (pct=)

Apply policy to a portion of messages for safe, gradual rollout.

80%

Phishing reduction

5M+

Domains with DMARC

3

Policy levels

Troubleshooting

Common DMARC configuration issues

Missing DMARC record -- No TXT record at _dmarc.yourdomain.com -- add one to enable protection
Policy stuck on p=none -- Monitoring only provides no protection; plan to move to quarantine/reject
No reporting configured -- Missing rua= tag means you cannot see who sends email as your domain
SPF/DKIM not aligned -- Authentication passes but domain alignment fails -- check From header matching
Third-party sender failures -- SaaS services sending as your domain may fail DMARC -- verify their SPF/DKIM setup
Subdomain policy missing -- Without sp= tag, subdomains inherit main policy which may not be appropriate

DMARC record tags explained

A DMARC record is a list of tag=value pairs. These are the nine you will meet, what each one controls, and the value most domains should use.

TagWhat it controlsTypical value
vVersion. Must be the first tag in the recordv=DMARC1
pPolicy for the domain when a message fails DMARC: none, quarantine or rejectp=quarantine
spPolicy for subdomains. Inherits p when absentsp=reject
ruaWhere aggregate reports (daily XML summaries) are sentrua=mailto:[email protected]
rufWhere forensic per-message reports are sent. Many receivers do not send themruf=mailto:[email protected]
pctPercentage of failing messages the policy applies to. Use it to ramp from none to rejectpct=100
adkimDKIM alignment mode: r (relaxed, subdomains match) or s (strict, exact match)adkim=r
aspfSPF alignment mode: r (relaxed) or s (strict)aspf=r
foWhen to generate forensic reports: 0 both fail, 1 either fails, d DKIM fails, s SPF failsfo=1

The checker flags any tag that is missing, misspelled or set to a value receivers ignore. To check SPF, DKIM and DMARC on a domain in one pass, run the DNS checker. To build a record from scratch, use the DMARC generator and follow the DMARC setup guide to publish it.

FAQ

Frequently asked questions

A DMARC checker is a tool that looks up the DMARC DNS TXT record at _dmarc.yourdomain.com, validates its syntax, and analyzes the policy configuration. It verifies that your domain has proper protection against email spoofing and helps identify misconfigurations that could affect email deliverability or security.

DMARC has three main policies: 'p=none' (monitoring only -- emails are delivered normally but reports are generated), 'p=quarantine' (suspicious emails are sent to spam folder), and 'p=reject' (suspicious emails are blocked completely and never delivered). Most organizations start with p=none to monitor, then gradually move to quarantine and finally reject.

DMARC is crucial for email security because it allows domain owners to specify exactly how receivers should handle emails that fail SPF and DKIM authentication. Without DMARC, attackers can freely spoof your domain to send phishing emails. DMARC also enables aggregate reporting so you can see who is sending email as your domain, and it is required for BIMI logo display in Gmail and Apple Mail.

To fix this, you need to create a DMARC TXT record and add it to your domain's DNS settings with the hostname '_dmarc'. A simple starting record is: v=DMARC1; p=none; rua=mailto:[email protected]. You can use our DMARC Generator tool to create a properly formatted record. Allow 24-48 hours for DNS propagation after adding it.

The 'p=' tag sets the policy for your main domain (e.g., example.com), while 'sp=' sets a separate policy for subdomains (e.g., mail.example.com). If sp= is not specified, subdomains inherit the main domain policy. This allows you to enforce a strict policy on your main domain while being more lenient on subdomains, or vice versa.

Aggregate reports (rua) are XML reports sent by receiving mail servers that summarize DMARC authentication results for your domain. They include data on which IPs sent email as your domain, whether SPF/DKIM passed or failed, and the volume of messages. Configure them by adding rua=mailto:[email protected] to your DMARC record. Use a DMARC report analyzer to parse these XML files.

Forensic reports (ruf) provide detailed information about individual email messages that failed DMARC authentication. Unlike aggregate reports which are summaries, forensic reports contain message headers or even full email content. They are useful for investigating specific authentication failures, but many providers do not send them due to privacy concerns.

DMARC alignment verifies that the domain authenticated by SPF or DKIM matches the From header domain visible to the recipient. Relaxed alignment (the default) allows subdomain matching -- so mail.example.com passes for example.com. Strict alignment requires an exact domain match. Alignment is what makes DMARC more effective than SPF or DKIM alone.

Most security experts recommend monitoring with p=none for 2-4 weeks minimum while reviewing aggregate reports. During this time, identify all legitimate email sources and ensure they pass SPF and DKIM with proper alignment. Once you are confident all legitimate senders are authenticated, move to p=quarantine with pct=25, gradually increasing to pct=100, then finally p=reject.

Yes, if implemented incorrectly. Moving to p=quarantine or p=reject before ensuring all legitimate senders pass authentication will cause those emails to go to spam or be rejected. This is why the gradual approach matters: start with p=none, use the pct= tag to apply the policy to only a percentage of messages, and use aggregate reports to verify before full enforcement.

Enter the domain above, or query DNS yourself: run dig TXT _dmarc.yourdomain.com (nslookup -type=txt _dmarc.yourdomain.com on Windows). A valid record starts with v=DMARC1 and contains a p= tag. The checker goes further by validating every tag, reading the alignment settings and explaining what the policy will do to mail that fails.

A lookup only fetches the record. A test evaluates it: syntax, policy strength, alignment mode, reporting addresses and whether subdomains are covered. This tool does both. To test how a real message performs against the policy, send one to a Gmail address and read the dmarc= result in its Authentication-Results header.

Get started

Complete DMARC protection

InboxKit provides automated DMARC setup with monitoring, aggregate report analysis, and expert guidance for safe policy enforcement.