NETCONFIG
SecurityEdge resolution

DMARC Lookup

Check a domain's DMARC policy to ensure proper email authentication.

Quick presets
🔐

DMARC Email Security Check

Enter a domain above to inspect published DMARC policies, enforcement levels, and reporting destinations.

Technical specification & engineering details

What this tool does

Reads the `_dmarc` TXT record for a domain and explains the policy in plain terms — none, quarantine, or reject — along with the reporting addresses configured to receive authentication failure reports.

Why DMARC matters

DMARC is what actually enforces the results of SPF and DKIM. Without a DMARC policy, a receiving mail server can see that SPF or DKIM failed but has no domain-published instruction on what to do about it — many will still deliver the mail. A DMARC record with a reject or quarantine policy tells receiving servers to actually act on authentication failures, closing the gap that lets spoofed mail through even when SPF and DKIM exist.

Understanding the policy levels

A `p=none` policy only requests reporting with no enforcement — a reasonable starting point while monitoring reports, but it doesn't stop spoofed mail from being delivered. `p=quarantine` sends failing mail to spam. `p=reject` blocks it outright and is the end goal for a domain that's confirmed its legitimate mail sources are all properly authenticated.

DMARC, SPF, and DKIM -- how they work together

These three standards solve different pieces of email authentication. SPF publishes which mail servers are allowed to send for your domain. DKIM cryptographically signs outgoing mail so receivers can verify it wasn't altered in transit. DMARC ties the two together: it tells receiving servers what to do when a message fails SPF or DKIM (or both), and where to send reports about those failures. Without DMARC, SPF and DKIM can each pass or fail independently with no consistent enforcement -- DMARC is what actually closes the loop.

Setting one up

A minimal starting record looks like `v=DMARC1; p=none; rua=mailto:reports@yourdomain.com` -- this only collects reports without blocking anything, which is the safe way to start. Once a few weeks of reports confirm all your legitimate mail sources (your email provider, any marketing or transactional email tools) are passing SPF or DKIM, you move the policy to `quarantine` and eventually `reject`.

Frequently asked questions

What's the difference between p=none, quarantine, and reject?

none only requests reporting with no enforcement; quarantine sends failing mail to spam; reject blocks it outright. Most domains start at none while monitoring reports, then move to stricter enforcement once confident.

Do I need SPF and DKIM set up before DMARC?

DMARC checks whether a message passed SPF or DKIM, so you need at least one of them correctly configured first -- otherwise every message will fail DMARC's checks regardless of policy.

What's the difference between rua and ruf reports?

rua (aggregate reports) are daily summaries of pass/fail counts by sending source -- most useful for ongoing monitoring. ruf (forensic reports) contain details of individual failed messages, but very few mail providers still send them due to privacy concerns.

Is p=none actually doing anything?

It enables reporting so you can see what's sending mail as your domain and whether it's passing authentication, but it doesn't block or quarantine anything on its own -- it's the monitoring phase before real enforcement.

Related Security tools

Blacklist Check

Check if an IP or domain is listed on major spam and malware DNSBLs.

Launch tool
Email Health

Comprehensive diagnostic of your SPF, DKIM, and DMARC configurations.

Launch tool