DMARC Checker

Q: What is the recommended DMARC rollout strategy?

Start with p=none and set up aggregate reporting ( rua= ) to collect 2-4 weeks of data. Analyze reports to identify all legitimate sending sources — third-party services, internal servers, marketing tools. Ensure each source has proper SPF and DKIM configured. Once you confirm all legitimate senders pass authentication, move to p=quarantine with pct=10 (apply to 10% of mail), gradually increase to 100%, then upgrade to p=reject . Rushing to p=reject without this process often blocks legitimate email.

Q: What DMARC reports should I expect and how do I read them?

Aggregate reports ( rua= ) arrive as XML files in a zip attachment, typically once per day per sending source. They contain: source IP, volume of messages, SPF/DKIM pass/fail results, and disposition (none/quarantine/reject). Tools like Google Postmaster Tools, Dmarcian, or Valimail parse these reports into readable dashboards. Forensic reports ( ruf= ) contain redacted email samples for failed messages — useful for debugging but not all receivers send them. Start with aggregate reports to understand your sending landscape before enabling forensic reporting.

Check DMARC DNS records for any domain online. Inspect policy, reporting addresses, and alignment settings to diagnose email authentication and phishing protection configuration using live DNS queries.

Why Check DMARC Records

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS policy record that tells receiving mail servers how to handle messages that fail SPF or DKIM checks — and where to send reports about failed authentication. It is the final layer of the email authentication stack, preventing domain spoofing and phishing. Major email providers (Gmail, Outlook) use DMARC to determine inbox placement. Checking your DMARC record confirms your policy is published, correctly formatted, and set to the appropriate enforcement level.

Live DMARC lookup: Queries _dmarc.yourdomain.com TXT record via DNS-over-HTTPS
Policy inspection: Shows p= (none, quarantine, or reject) and sp= subdomain policy
Reporting addresses: Displays rua= (aggregate) and ruf= (forensic) report destinations
Alignment modes: Shows adkim= and aspf= alignment settings
No install needed: Works in any browser without dig or nslookup

Check DMARC Record →

Choose the Right Variant

This page: DMARC policy and reporting configuration
SPF Record Checker: Verify sender authorization records
TXT Record Lookup: All TXT records including DKIM selectors
MX Record Lookup: Inbound mail routing records
DNS Propagation Checker: Verify global propagation of changes

Step-by-Step Tutorial

Enter the domain to check — e.g. example.com
Select TXT as the record type and look up _dmarc.example.com, or use the DNS lookup tool which auto-checks the DMARC subdomain
Look for a record starting with v=DMARC1
Check the p= tag: none (monitor only), quarantine (spam folder), or reject (block)
Verify reporting addresses in rua= (aggregate reports) are correct email addresses
If no DMARC record is found, your domain has no DMARC policy — it is vulnerable to spoofing

DMARC Tags Reference

v=DMARC1: Required — identifies the record as DMARC
p=none/quarantine/reject: Policy for messages that fail DMARC — none=monitor, quarantine=spam, reject=block
sp=: Subdomain policy — overrides p= for subdomains like mail.example.com
rua=mailto:: Address to receive aggregate XML reports (daily summaries of authentication results)
ruf=mailto:: Address to receive forensic reports (individual failure samples)
pct=: Percentage of messages to apply policy to — default 100, useful for gradual rollout
adkim=r/s: DKIM alignment — relaxed (default) or strict
aspf=r/s: SPF alignment — relaxed (default) or strict

Privacy and Data Handling

DNS lookups run directly in your browser via DNS-over-HTTPS. Domain names you look up are not logged or stored. The tool displays live DNS results without retaining any query data after your session.

Frequently Asked Questions

What is the recommended DMARC rollout strategy?

Start with p=none and set up aggregate reporting (rua=) to collect 2-4 weeks of data. Analyze reports to identify all legitimate sending sources — third-party services, internal servers, marketing tools. Ensure each source has proper SPF and DKIM configured. Once you confirm all legitimate senders pass authentication, move to p=quarantine with pct=10 (apply to 10% of mail), gradually increase to 100%, then upgrade to p=reject. Rushing to p=reject without this process often blocks legitimate email.

Why does DMARC fail even when SPF and DKIM pass?

DMARC requires SPF or DKIM to pass AND align with the From: header domain. Alignment means the authenticated domain (SPF envelope sender or DKIM d= tag) must match the domain in the From: header. With relaxed alignment (default), mail.example.com aligns with example.com. With strict alignment, they must match exactly. Email forwarding commonly causes DMARC failure: when a server forwards your email, the SPF envelope sender changes to the forwarder's domain, breaking SPF alignment — even if SPF passes for the forwarder.

What DMARC reports should I expect and how do I read them?

Aggregate reports (rua=) arrive as XML files in a zip attachment, typically once per day per sending source. They contain: source IP, volume of messages, SPF/DKIM pass/fail results, and disposition (none/quarantine/reject). Tools like Google Postmaster Tools, Dmarcian, or Valimail parse these reports into readable dashboards. Forensic reports (ruf=) contain redacted email samples for failed messages — useful for debugging but not all receivers send them. Start with aggregate reports to understand your sending landscape before enabling forensic reporting.