DMARC Checker Verify the existence, syntax, and deployment policy of a domain's DMARC record.

Guide FAQ

live DNS · read-only · no signup

Our DMARC Checker queries the DNS TXT record at _dmarc.yourdomain.com and parses every tag — policy (p=), subdomain policy (sp=), reporting addresses (rua=, ruf=), alignment modes, and percentage (pct=). Results are returned in seconds with actionable recommendations.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol published as RFC 7489. It builds on SPF and DKIM to give domain owners control over how receiving mail servers handle unauthenticated email claiming to come from their domain.

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. It tells receiving servers: "If an email fails SPF and DKIM alignment checks, do this — monitor it (p=none), send it to spam (p=quarantine), or reject it outright (p=reject)."

DMARC also enables reporting. Domain owners receive daily aggregate reports (rua=) and forensic failure reports (ruf=) from participating mail servers, giving full visibility into who is sending email using their domain.

Prevents domain spoofing and business email compromise (BEC)
Required by Google and Yahoo for bulk senders since February 2024
Provides visibility via aggregate and forensic reports
Works alongside SPF and DKIM — does not replace them
Protects brand reputation and email deliverability

Why DMARC Matters for Email Security

Email spoofing is one of the most common attack vectors used in phishing, business email compromise, and brand impersonation attacks. Without DMARC, any attacker can send emails that appear to come from your domain with no technical barrier.

Since February 2024, Google and Yahoo now require domains sending more than 5,000 emails per day to have a DMARC record. Failure to comply results in email delivery failures — directly impacting revenue, customer communication, and trust.

Stops attackers from spoofing your domain in phishing emails
Required by Google & Yahoo for bulk senders (2024 mandate)
Protects customers from receiving fake invoices, password resets, and login links in your name
Provides daily reports showing all sources sending mail as your domain
Improves email deliverability by proving domain legitimacy

How This DMARC Checker Works

The tool performs a real-time DNS TXT lookup at _dmarc.yourdomain.com and parses the full record.

Validates the domain input against SSRF and format checks
Queries the authoritative DNS resolver for TXT records at _dmarc.{domain}
Parses every DMARC tag: p=, sp=, rua=, ruf=, adkim=, aspf=, pct=, fo=
Evaluates policy strength and generates pass/warning/fail status
Returns actionable recommendations based on discovered issues

How to Use the DMARC Checker

Enter your domain name (e.g., example.com) in the input field
Click "Check DMARC" to run the lookup
Review the parsed record — policy, alignment, and reporting addresses
Check the recommendations section for any issues flagged
Use the raw record view to see the exact DNS TXT value

Understanding Your DMARC Results

Each tag in a DMARC record controls a specific behavior. Here is what every field means:

Field / Value	Meaning
`p=none`	Monitor-only mode. Emails that fail DMARC are delivered normally but reports are still sent. Use this first to understand your email ecosystem before enforcing.
`p=quarantine`	Failing emails are sent to the spam/junk folder. An intermediate enforcement step before full rejection.
`p=reject`	Failing emails are rejected outright at the SMTP level. Maximum protection — recommended once you are confident all legitimate email passes.
`sp=`	Subdomain policy. Controls how failing mail from subdomains is handled. Defaults to the main p= policy if not specified.
`rua=`	Aggregate report URI. The email address where daily XML aggregate reports are sent by receiving servers.
`ruf=`	Forensic report URI. The address for per-message failure reports. Note: many providers no longer send these due to privacy concerns.
`adkim=`	DKIM alignment mode. "r" (relaxed) allows org domain matches; "s" (strict) requires an exact domain match.
`aspf=`	SPF alignment mode. "r" (relaxed) or "s" (strict). Controls how the From domain must match the SPF envelope sender.
`pct=`	Percentage of messages the policy applies to. pct=100 means full enforcement. Use pct=10 to gradually roll out enforcement.
`fo=`	Failure options for forensic reports. fo=1 sends a report if any auth mechanism fails (most common).

Common Problems & How to Fix Them

Your domain has no DMARC policy. This means anyone can spoof your domain in email without any enforcement.

To fix this, add a TXT record to your DNS:
Name: _dmarc.yourdomain.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Start with p=none to monitor without affecting delivery, then move to p=quarantine and finally p=reject once you have reviewed reports.

Your DMARC record exists but is in monitor-only mode (p=none). This gives you visibility but does not protect your domain from spoofing.

Once you have reviewed aggregate reports and confirmed all legitimate senders pass SPF and DKIM, upgrade to p=quarantine, then eventually p=reject.

Without rua=, you receive no aggregate reports and cannot see who is sending email as your domain.

Add rua=mailto:dmarc@yourdomain.com to your record. Many free services (like DMARC Analyzer, Postmark, or Valimail) provide free report collection.

Without sp=, subdomains inherit the main p= policy. If p=none, all subdomains are also unprotected.

Add sp=reject to protect subdomains even if the main domain is still in p=none monitoring mode.

Only one DMARC TXT record is allowed at _dmarc.yourdomain.com. Multiple records cause a DMARC permerror and receiving servers will ignore your policy entirely.

Delete duplicate records and keep only one.

Best Practices

Start with p=none to monitor email sources before enforcing any policy
Set up rua= reporting immediately — you need visibility before enforcement
Review aggregate reports for at least 2–4 weeks before moving to p=quarantine
Use a dedicated DMARC report mailbox or a service like Postmark, Valimail, or DMARC Analyzer
Ensure all legitimate email sources (transactional, marketing, helpdesk) pass SPF and DKIM before enforcing
Set sp=reject to protect subdomains independently of the main domain policy
Use pct= to gradually roll out enforcement (start pct=10, increase weekly)
Set adkim=s and aspf=s (strict alignment) once all senders are confirmed and aligned
Move to p=reject as the final goal — it is the only mode that truly stops spoofing

Security Recommendations

Never stay on p=none permanently — it provides zero protection against spoofing
Audit all third-party email senders (CRMs, marketing tools, ticketing systems) before enforcing
Ensure every authorized sender passes both SPF and DKIM alignment, not just one
Do not use ruf= for forensic reports unless you have a privacy-compliant system to receive them
Check subdomain DMARC with sp=reject — subdomain spoofing is a common attack vector
Never set pct=0 — this disables enforcement entirely and creates a false sense of security

Frequently Asked Questions

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. It tells receiving mail servers what to do with emails that fail SPF and DKIM authentication — deliver, quarantine, or reject them. It also specifies where to send daily reports about email activity on your domain.

Yes. SPF and DKIM validate different aspects of email but they do not by themselves tell receiving servers what action to take when authentication fails. DMARC provides the policy layer (none/quarantine/reject) that ties SPF and DKIM together and enforces consequences for failures.

p=quarantine tells receiving servers to deliver emails that fail DMARC to the spam/junk folder. p=reject tells servers to refuse the email entirely at the SMTP level — it never reaches the inbox or spam folder. p=reject is the strongest protection and the recommended final goal.

Log in to your DNS provider (GoDaddy, Cloudflare, Namecheap, etc.) and add a TXT record with:
Name: _dmarc (or _dmarc.yourdomain.com)
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Start with p=none to monitor without impacting delivery. DNS changes can take up to 48 hours to propagate globally.

DNS changes typically propagate within 15 minutes to a few hours for most resolvers, but can take up to 48 hours to fully propagate worldwide. Use our DNS Propagation Checker to monitor the rollout.

The rua= tag specifies where aggregate reports are sent. These XML reports (sent daily by participating mail servers like Google, Microsoft, and Yahoo) show all sources that sent email using your domain, along with SPF and DKIM pass/fail status for each source. They are essential for understanding your email ecosystem before enforcing DMARC.

DMARC with p=reject stops emails that directly spoof your exact domain (From: you@yourdomain.com). It does not stop cousin domain attacks (yourd0main.com), lookalike domains, or display name spoofing. For full protection, combine DMARC enforcement with brand monitoring and anti-phishing tools.

DMARC is not required to use these services, but it is required if you send bulk email to Gmail or Yahoo accounts (5,000+ emails/day as of February 2024). Even for lower volumes, a DMARC record at p=reject is strongly recommended to protect your domain from spoofing.

DMARC alignment means the domain in the email's From: header must match the domain verified by SPF (envelope sender) or DKIM (d= tag). Relaxed alignment (aspf=r, adkim=r) allows subdomains to match. Strict alignment (aspf=s, adkim=s) requires an exact domain match.

This usually means: (1) The DNS record has not fully propagated yet — wait up to 48 hours. (2) The record is published at the wrong name — it must be _dmarc.yourdomain.com, not dmarc.yourdomain.com. (3) There are multiple DMARC records causing a permerror. Use this checker to verify the exact record being read.