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: SPF, DKIM & Email Authentication

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.

Try it now: Open the free DMARC Checker: SPF, DKIM & Email Authentication tool — no sign-up required.

What are SPF, DKIM, and DMARC?

SPF (Sender Policy Framework) is a single TXT at your domain (often starting with v=spf1) that authorizes which mail sources may use your domain in the SMTP envelope. DKIM (DomainKeys Identified Mail) uses asymmetric cryptography: the sending MTA signs the message, and the receiver validates using the public key in DNS. DMARC sits on top: it says what receivers should do when authentication fails or is not aligned with the visible From domain, and it can request reports to rua/ruf mailboxes. Together they form the default stack for domain-level email security that inbox providers and filters expect, beyond simple block/allow rules.

Why email authentication matters for deliverability

Major providers score incoming mail on whether it passes SPF and DKIM, whether those results align with your brand domain, and whether your DMARC policy is coherent with your actual sending. Weak or missing authentication increases the chance of spam folder placement, throttling, or bounces, especially for bulk, transactional, and cold outreach. A consistent stack also protects your domain’s reputation: mail that passes but spoofs your display name is harder when DMARC is deployed with reporting and, eventually, quarantine or reject. When debugging routing or MX issues alongside authentication, a DNS lookup helps confirm the full picture, and an email validator is useful for forms and CRM hygiene at the collection layer.

How to read and fix common issues

Start with the raw TXT and the parsed view: a missing v=DMARC1 record is a full gap; p=none with no move toward enforcement means you are in monitoring mode only. For SPF, watch for more than one SPF TXT (invalid), +all or accidental broad include chains, and DNS lookup limits that make some receivers treat the record as a soft fail. For DKIM, ensure the selector you query matches what your provider signs with, that the public key is present and not truncated, and that key length matches current practice (many providers use 2048-bit keys today). If legitimate mail still fails under stricter DMARC, trace each sending path: marketing platform, helpdesk, forwarding, and internal relays each need their own signing or allowed SPF. After DNS changes, respect TTL before drawing conclusions, and re-check here.

Best practices for email domain security

Roll out in phases: publish DMARC with p=none and rua to collect aggregate data, correct SPF and DKIM until passes are high and aligned, then move to quarantine and finally reject where the business can absorb edge cases. Keep pct in mind if you use staged enforcement. Do not “fix” deliverability by loosening authentication—instead, add missing signers, fix includes, and separate brands or subdomains with their own sp when needed. Suppress bounces and invalid addresses, use double opt-in for marketing where appropriate, and document which vendors send as which domains. For surface area beyond email—e.g. ensuring your marketing site presents strong TLS and headers—SSL certificate and security headers harden the trust story that also supports safe links in messages.

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.

Ready to try it yourself?

Use DMARC Checker: SPF, DKIM & Email Authentication for Free