What is DMARC and why does it matter?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a policy published in a DNS TXT record at _dmarc that tells receiving mail systems how to treat email that fails SPF and/or DKIM checks when those results are not aligned with your From domain. It also requests aggregate and optional forensic reports so you can see who is sending on your behalf. Without DMARC, you have limited signal and enforcement against spoofing and phishing that use your domain in the message—bad for both security and deliverability.

How do SPF, DKIM, and DMARC work together?

SPF lists which hosts are allowed to send mail for your domain (in a TXT record at the domain apex). DKIM signs messages with a private key; recipients verify the signature using a public key published in DNS (under a selector like default._domainkey). DMARC requires domain alignment: the SPF and/or DKIM "d" that pass must be in a consistent relationship to the From: header domain (strict or relaxed per adkim/aspf). DMARC is the policy layer: it decides what to do with mail that is not authentic or not aligned, and it can request reporting. Use this tool to read the three in one pass, and a [DNS lookup](/dns-lookup) when you need full TXT or other record types in context.

What does a DMARC policy of "none" vs "quarantine" vs "reject" mean?

The p= tag is the org-wide policy, and sp= can override for subdomains. **none** means receivers should not change delivery based on DMARC (monitoring only—useful for rollout). **quarantine** typically sends failing mail to spam or with a strong junk indicator. **reject** means failing mail should not be delivered to the inbox. Stricter policies reduce abuse of your brand but can block legitimate senders if your SPF, DKIM, and alignment are not correct—validate before tightening beyond none.

How do I set up DKIM for my domain?

DKIM is almost always provided by your email or transactional provider: they give you a selector name, a public key, and sometimes CNAMEs instead of flat TXT. You publish a TXT at selector._domainkey (for example, default._domainkey.example.com) with tags like v=, k=, p=. After publishing, wait for DNS propagation, then re-check the selector in this tool. If you are unsure which selector your mail uses, check your provider’s documentation or the raw message headers of a test email (DKIM-Signature includes s= and d=).

What happens if SPF, DKIM, or DMARC are misconfigured?

You may see bounces, spam folder placement, or delayed delivery because receivers cannot verify your domain or apply your DMARC policy as intended. Common problems: multiple conflicting SPF records, overlong or overly permissive SPF, missing DKIM signing on some paths, or DMARC p=reject while legitimate mail is not aligned. DMARC aggregate (rua) reports help, but a quick pass with this checker plus an [email validator](/email-validator) for address syntax on signup flows, and a [SSL certificate checker](/ssl-certificate) for the mail/HTTPS hostnames you reference, often surfaces fixable issues early.

DMARC Checker

DMARC, SPF, and DKIM checker: query public DNS, parse v=DMARC1 and SPF records, and debug email authentication issues affecting deliverability and trust.

DKIM selector (optional)

Results will appear here

Query DNS for DMARC, SPF, and DKIM in one run: read v=DMARC1 policy, scan SPF for dangerous includes, and look up a DKIM selector. Built for webmasters and ops teams who need to verify email authentication and troubleshoot deliverability before tightening enforcement.

Read the full guide →

Frequently Asked Questions

What is DMARC and why does it matter?: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a policy published in a DNS TXT record at _dmarc that tells receiving mail systems how to treat email that fails SPF and/or DKIM checks when those results are not aligned with your From domain. It also requests aggregate and optional forensic reports so you can see who is sending on your behalf. Without DMARC, you have limited signal and enforcement against spoofing and phishing that use your domain in the message—bad for both security and deliverability.
How do SPF, DKIM, and DMARC work together?: SPF lists which hosts are allowed to send mail for your domain (in a TXT record at the domain apex). DKIM signs messages with a private key; recipients verify the signature using a public key published in DNS (under a selector like default._domainkey). DMARC requires domain alignment: the SPF and/or DKIM "d" that pass must be in a consistent relationship to the From: header domain (strict or relaxed per adkim/aspf). DMARC is the policy layer: it decides what to do with mail that is not authentic or not aligned, and it can request reporting. Use this tool to read the three in one pass, and a [DNS lookup](/dns-lookup) when you need full TXT or other record types in context.
What does a DMARC policy of "none" vs "quarantine" vs "reject" mean?: The p= tag is the org-wide policy, and sp= can override for subdomains. **none** means receivers should not change delivery based on DMARC (monitoring only—useful for rollout). **quarantine** typically sends failing mail to spam or with a strong junk indicator. **reject** means failing mail should not be delivered to the inbox. Stricter policies reduce abuse of your brand but can block legitimate senders if your SPF, DKIM, and alignment are not correct—validate before tightening beyond none.
How do I set up DKIM for my domain?: DKIM is almost always provided by your email or transactional provider: they give you a selector name, a public key, and sometimes CNAMEs instead of flat TXT. You publish a TXT at selector._domainkey (for example, default._domainkey.example.com) with tags like v=, k=, p=. After publishing, wait for DNS propagation, then re-check the selector in this tool. If you are unsure which selector your mail uses, check your provider’s documentation or the raw message headers of a test email (DKIM-Signature includes s= and d=).
What happens if SPF, DKIM, or DMARC are misconfigured?: You may see bounces, spam folder placement, or delayed delivery because receivers cannot verify your domain or apply your DMARC policy as intended. Common problems: multiple conflicting SPF records, overlong or overly permissive SPF, missing DKIM signing on some paths, or DMARC p=reject while legitimate mail is not aligned. DMARC aggregate (rua) reports help, but a quick pass with this checker plus an [email validator](/email-validator) for address syntax on signup flows, and a [SSL certificate checker](/ssl-certificate) for the mail/HTTPS hostnames you reference, often surfaces fixable issues early.