A DMARC check reads the public DNS records of your domain — _dmarc, SPF and DKIM — and shows what is published, what is missing, and what that means. It takes about a minute and needs no signup.
You get the records themselves, a plain-language read of each one, and a short list of what to fix first.
Free. 54 checks. No signup. Your site keeps working while the check runs.
Type a domain and the full free report opens — 54 checks in all. This page is about the Email and DNS group: the _dmarc record, your SPF record, the DKIM selectors we found, and a note on each of the 13 checks. No account, nothing to install, requests rate-limited per IP, and no access to your mailbox.
An SPF DKIM DMARC check reads three records answering three different questions, and most "my email goes to spam" cases come down to one of them.
| Record | What it sets up | What happens when it is missing |
|---|---|---|
| SPF | The servers allowed to send email for your domain | No list to check against, so a message claiming your domain is judged on nothing. |
| DKIM | A signature on every message, checked against a public key in your DNS | Nobody can confirm the message came from you or arrived unaltered. |
| DMARC | What a server should do when SPF or DKIM does not line up, and where to send reports | Nothing tells it how to treat a failing message, so it treats it as ordinary mail. |
With no record to check, a receiving server cannot tell a fake email from a real one, so the fake is delivered as ordinary mail — and people trust your name. A fraudster writes to your customers and partners in your name: fake invoices, "problem with your order", "the director asks you to transfer money urgently". The money ends up in the fraudster's account, while the complaints and disputes land on you, and your domain's reputation suffers: real messages increasingly end up in spam.
A DMARC record is one TXT line at _dmarc.yourdomain.com, and every tag does one job. If you came here to check a DMARC record for your own domain, the check above prints the same line, tag by tag.
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s — a working record: failing mail is refused and reports reach a mailbox you read.v=DMARC1; p=none; — asleep. Servers are told to deliver failing mail anyway, and with no rua you get no reports, so you learn nothing about what is sent in your name.The free check runs all 13 checks in this group and uses these exact names in the report.
We would rather say this than sell you a clean tick.
A passing DNS check is the first step, not proof that your email lands in the inbox.
This is the most common real-world breakage, and it looks impossible until you see why. DMARC does not just ask whether SPF and DKIM passed: it asks whether the domain they passed for is the one the recipient sees in the From: header.
The usual setup: you send a newsletter through a mailing platform, add its servers to your SPF record and switch on DKIM in its settings. The message goes out with your domain in From:, but the platform signs it with its own DKIM key. SPF passes, DKIM passes — neither for your domain. DMARC compares From: with the authenticated domain, finds no match, and the message fails.
The fix is not to loosen everything. Either the sending service signs with a DKIM key published under your domain — most platforms call this custom DKIM — or you accept relaxed alignment through a subdomain you control. Until then the reports keep showing failures.
Both providers now require authentication rather than recommend it, and the rules reach small senders.
Google: since 1 February 2024, every sender to Gmail addresses must use SPF or DKIM, publish a valid PTR record and send over TLS. Senders of 5,000 or more messages a day need SPF, DKIM and DMARC (policy may be p=none), a spam rate below 0.30%, one-click unsubscribe, From: alignment with an SPF or DKIM domain, and DKIM keys of at least 1024 bits.
Yahoo: since February 2024, bulk senders need SPF and DKIM, plus a published DMARC policy of at least p=none that passes. A working rua reporting address is strongly recommended rather than required, relaxed alignment is acceptable, and a functioning list-unsubscribe header is required.
Current specifications, if you want the primary documents: DMARC — RFC 9989 (Proposed Standard, May 2026), aggregate reporting — RFC 9990, failure reporting — RFC 9991; SPF — RFC 7208, DKIM — RFC 6376, ARC — RFC 8617.
Tighten the policy last, not first.
Skipping straight to reject is a familiar way to cut off order confirmations and password resets along with the fraudsters.
Email and DNS is 13 of the 54 checks in the free scan. The rest cover the certificate and HTTPS setup, response headers and cookies, exposed files and backups, third-party code, login panels and service paths, reputation and registration dates, and what public sources say about your business. If email authentication is today's question, this page is the entry point.
To be clear about the shape of the product: we inspect your external perimeter from public data. This is not a pentest and not an internal audit of your mail infrastructure — nothing is exploited, nothing is changed.
BlindspotScan team · Published 3 October 2026 · Last reviewed 3 October 2026
We read public DNS records only. We do not log in anywhere, do not test sending to your mailbox and do not attempt to exploit anything we find. Checks are rate-limited per IP, and this page runs under the same limit as the rest of the product.
A DMARC check reads the public DNS records of your domain and reports what is published, what is missing and what that means. It covers the _dmarc record and the SPF and DKIM records that go with it, and it does not send mail or read your inbox.
Enter your domain in the check on this page and the report shows the _dmarc TXT record as soon as it loads, under Email and DNS. If you prefer a terminal, dig TXT _dmarc.yourdomain.com prints the same record; on Windows, nslookup -type=TXT _dmarc.yourdomain.com. An empty answer means no DMARC record is published.
No. p=none asks receiving servers to take no action on mail that fails your policy: they deliver it anyway, and with rua set they also send you reports. It is the monitoring setting you start with while you learn who sends mail as your domain.
Work backwards from the sending side. Publish SPF and DKIM for every service that sends mail for you, then add DMARC as p=none with a rua address you read. Use the reports for a few weeks to find every legitimate sender, then tighten — quarantine first, reject last.
The record is the same; only the value of p changes. quarantine asks receivers to treat failing mail as suspicious, so it usually lands in spam; reject asks them to refuse it outright. Quarantine gives a legitimate sender a second chance, reject does not, so it comes last.
Yes. SPF, DKIM and DMARC are public DNS data, so a check works on any domain without proof of ownership. The check is passive — a few ordinary DNS queries reading what is already published — and rate-limited per IP. It is not a tool for probing other people's systems.
DMARC compares the domain in the From: header with the domain that passed SPF or DKIM. If they differ, alignment fails and the message fails DMARC even though both checks passed. The usual culprit is a third-party sender — a newsletter platform, a CRM, an invoicing app — signing with its own domain. The fix is a DKIM key published under your domain, or relaxed alignment through a subdomain you control.