Best free tools to check DMARC, SPF, and email setup.
Updated on 12 Oct 2026: We clarified free email authentication checks, added a practical header test, and corrected DMARC policy guidance.
The best free starting point is a broad domain health check, followed by a real-message test. A DNS lookup checks published authentication records, including DKIM keys at known selectors. A sent-message test tells you whether your actual mail passes DMARC with the visible From domain. Neither result guarantees inbox placement.
Start with Suped's free Domain Health Checker because it checks the records that cause the most immediate setup problems. Then send a real email to a mailbox you control and inspect the original authentication results. If the domain sends production mail, move into ongoing DMARC monitoring so aggregate reports show which source is passing, failing, or using a domain that does not match.
Free tools are enough to catch broken syntax, missing records, weak policies, excessive SPF DNS lookups, missing known DKIM selectors, and obvious DMARC reporting mistakes. One-off checks do not track a changing sender list or authentication failures over time. Free DMARC monitoring plans add that history within their operating limits.
Which free checks should you run?
A useful free workflow is simple: run a domain-wide DNS check, run a focused DMARC record check, then send a real message to a test mailbox and inspect the authentication result. No single free check sees every part of the setup because DNS records and live message headers answer different questions.
- Use a domain health checker to review SPF and DMARC records, plus DKIM keys at known selectors. Check MX and transport settings separately.
- Use a focused DMARC checker to parse policy, reporting tags, subdomain handling, testing mode, and syntax.
- Send a real email to a mailbox you control and compare SPF, DKIM, and DMARC results with the visible From domain.
- Use Suped's reporting workflow to review reported sending sources over time, including on low-volume domains.
The key caveat
A green DNS result does not prove that a specific email will pass DMARC. SPF checks the bounce domain, DKIM checks a cryptographic signature, and DMARC checks whether at least one passing result uses a domain that matches the visible From domain.
DNS record checks and live message tests for SPF, DKIM and DMARC.
Free checks worth running
Choose each free check for the job it can verify. A public DNS check is fast, but it cannot see a broken DKIM signature on a message. A live-message check is realistic, but it only sees the sender used for that test. Check whether a tool is general-purpose or limited to your sender's documented DNS records.
|
|
|
|---|---|---|
Domain health scan | Published authentication records | Cannot verify a sent message; DKIM coverage depends on selectors |
DMARC record parser | Policy and tag syntax | Cannot identify every sender |
SPF evaluator | Lookup path and limits | Uses current DNS only |
DKIM selector lookup | Public key discovery | Needs the exact selector |
Live-message test | Actual authentication result | Covers one message path |
Aggregate report monitor | Ongoing source history | Needs time to collect reports; covers participating receivers |
Comparison of free DMARC, SPF, and email setup checks.
Suped's free domain health scan reviews SPF and DMARC, with DKIM lookups at common selectors. Its focused checkers help isolate record problems. A missing key in a common-selector scan does not prove DKIM is absent: get the exact selector from your sender or message headers. For message-level verification, send one email through each important source and inspect the receiving mailbox's authentication results.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The check depends on the failure you are trying to prove. If SPF has too many DNS lookups, an evaluator sees it. If DKIM is missing for one sender, a selector lookup sees it only when you know the selector. If a platform signs with DKIM but the signing domain does not match the From domain, a sent-message test exposes that faster than a raw DNS lookup.
A free DMARC checker and a free DMARC monitor are different. A checker returns a snapshot. A monitor receives aggregate XML reports over time and turns them into source history. Before routing reports to any plan, check the operating limits rather than relying on the word 'free'. Confirm whether access is an ongoing free plan or a time-limited trial, and whether it requires an account.
- Traffic limit: Confirm whether the plan caps evaluated messages, reports, domains, or active sending sources.
- Retention and export: Check how long history remains available and whether raw XML or summarized data can be exported.
- Coverage: Verify support for subdomains, inactive domains, multiple report destinations, and external rua authorization.
- Alerts and access: Decide whether email digests are enough or whether your team needs alerts and shared access.
Also check whether adding a reporting address will preserve your existing DMARC record. Publishing two DMARC records makes the policy invalid, so a setup flow should merge a new rua destination into the existing record rather than create a second record.
Aggregate reports typically arrive daily, rather than as an immediate response to a DNS change. They cover traffic observed by reporting receivers, so an empty report view does not prove that nobody is sending. RFC 9990 defines aggregate reporting.
What DNS and message checks can verify
Free checkers are best at proving the current public state. They query DNS, parse record syntax, and sometimes receive a real message. That is enough for setup checks, onboarding a new sender, and finding obvious delivery blockers before a campaign goes out.
A DNS checker can verify
- Published records: Expected SPF and DMARC records, DKIM keys at specified selectors, and any MX or reporting records included in the check exist in public DNS.
- Valid syntax: Tags parse correctly, quoted TXT strings join cleanly, and policy values are allowed.
- Evaluate SPF paths against the ten DNS-causing-term limit and the recommended two-void-lookup limit in RFC 7208. A domain-only scan cannot reproduce every IP-dependent evaluation.
A message test can verify
- Real pass result: The message passes SPF or DKIM in the path used for that exact email.
- Domain match: The passing domain matches the visible From domain closely enough for DMARC.
- Header reality: Whether forwarding, rewriting, or platform changes affected authentication on this tested path.
This is why one-off tools are good for diagnosis, but they do not replace report-based monitoring. A domain with perfect DNS can still have an old CRM, support desk, billing system, or regional sender failing DMARC every day.
Gmail Show original view with SPF, DKIM and DMARC PASS results.
Gmail's original message view is a useful manual sanity check because it shows the receiver's interpretation of a real message. Raw headers are especially helpful when a sending service says a message is fine and the receiving mailbox disagrees.
Read a real email authentication test
Send a message through the actual service being checked. In Gmail on a computer, open the received message, select the More menu next to Reply, then choose "Show original". Google's header instructions describe the same steps. Read the Authentication-Results header added by the receiving mailbox.
Illustrative headers: SPF and DKIM pass, DMARC failstext
From: Billing <billing@example.com> Return-Path: <bounce@example.net> Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=example.net; dkim=pass header.d=example.net header.s=selector1; dmarc=fail header.from=example.com
- Compare smtp.mailfrom and header.d with header.from. In this example, both passing identities use example.net, so neither matches example.com for DMARC.
- Find d= and s= in the full DKIM-Signature header. They identify the signing domain and selector; this example needs a lookup at selector1._domainkey.example.net.
- If the provider uses its own authentication domains, configure its custom DKIM signing domain or custom envelope-sender domain, then send another test.
- Repeat the test for each sending source and important delivery path. A direct delivery test does not verify a forwarding or mailing-list path.
DMARC alignment uses the same organizational domain in relaxed mode and an exact domain match in strict mode, as defined in RFC 9989. Check aspf and adkim before interpreting related subdomains as a match.
A practical checking workflow
The cleanest workflow is sequential. Do not start by changing DNS. First prove the current state, then decide whether the fix belongs with your DNS host, your mail provider, or a third-party sender.
What each check establishes
These are evidence stages, not measured confidence scores or inbox-placement predictions.
DNS issues found
Fix the records
Expected records are missing or invalid.
Test message passes
Test other sources
Authentication is verified for one tested path.
Reports reviewed
Monitor sender changes
Approved sources are checked against reported traffic.
- Check public DNS: Confirm one SPF TXT record at each envelope-sender domain, one DMARC record at each checked policy hostname, and the expected DKIM selector records.
- Check SPF limits: Evaluate nested includes and redirects for each sending source, remove stale includes, and avoid broad ranges that authorize senders you do not use.
- Check DMARC policy: Confirm the policy, subdomain handling, aspf/adkim domain-matching modes, test mode, and report destinations are intentional.
- Send real email: Test every major source, including marketing, support, billing, product mail, and employee mail.
- Compare reports: Compare reported traffic with your approved sender list over a period that includes less frequent mail, such as monthly billing.
After changing DNS, recheck the authoritative record and the public resolver used by the checker after cached values expire according to their TTL. Send a new message after enabling DKIM; an old message will not gain a signature retroactively.
Email authentication workflow: check DNS, send a test, read headers, fix issues and monitor DMARC reports.
For blocklist and blacklist issues, run that check after authentication. Blocklist status can explain poor delivery when authentication passes, but it should not distract from a missing DMARC record or SPF failure. Fix identity first, then reputation.
What the records should look like
A clean setup has one SPF TXT record at each envelope-sender domain, a DMARC TXT record at _dmarc.example.com, and one or more DKIM public keys at selector hostnames supplied by each sender. The exact values depend on your mail provider, but the shape is consistent.
SPF exampledns
example.com. TXT "v=spf1 include:_spf.example.net -all"
SPF authorizes sending servers for the domain used in the envelope sender. For DMARC, SPF only helps when that domain matches the visible From domain, or when the sender uses a permitted related domain under DMARC's domain-matching rules.
DKIM selector example (key abbreviated)dns
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."
A valid DKIM signature verifies a signing domain and the integrity of the signed message data; it does not prove the identity of an individual sender. A checker needs the selector and domain to find the public key, following a CNAME if the provider delegates the key. If you do not know the selector, send a real message and inspect the DKIM-Signature header.
DMARC monitoring starter exampledns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
Do not copy blindly
Example records are useful for shape, not for production values. Your SPF includes, DKIM selectors, report addresses, and DMARC policy need to match your actual senders and risk tolerance.
Adding stale vendor includes can produce a permerror when an SPF evaluation exceeds ten DNS-causing terms. A common DMARC mistake is publishing p=reject before every legitimate source passes through SPF or DKIM with the right domain. RFC 9989 advises general-purpose email domains against p=reject because mailing-list traffic can fail authentication.
Current DMARC standards for checkers
- Historic tags: The pct, ri, and rf tags are historic and absent from the current format. Their presence alone does not invalidate a record; unsupported tags are ignored.
- Current policy tags: The t tag requests test handling, np covers non-existent subdomains, and psd indicates whether the record is published by a public suffix domain.
- External report addresses: A rua destination with a different organizational domain needs DNS authorization published by the report receiver.
- Failure-report privacy: Failure reports can expose message headers or content, so many receivers limit or omit them.
RFC 9989 also uses a DNS tree walk for policy discovery and organizational-domain determination. A basic parser that checks only _dmarc at the entered domain does not verify inherited subdomain policy.
DMARC test-mode exampledns
_dmarc.test.example.com. TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com"
Check receiver support
A receiver that implements t=y applies handling one policy level below the published policy: quarantine becomes none, and reject becomes quarantine. Older receivers can ignore t and apply the published policy, so it is not a safe percentage-rollout replacement. Receiver local policy still affects delivery.
Where Suped fits
Free one-off tools answer the setup question. Suped, our DMARC and email authentication platform, answers the operating question: what is sending as this domain today, which source is failing, what changed, and what action fixes it?
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped processes aggregate reports, groups sending sources, tracks SPF and DKIM results, and provides issue-level fix steps. Hosted SPF manages SPF authorization, while hosted MTA-STS manages the policy for encrypted inbound mail delivery. Blocklist (blacklist) monitoring adds reputation context when delivery problems remain after authentication checks.
Free checker
- Snapshot result: Shows the state at the moment you run the check.
- Manual review: Needs a person to interpret each failure and assign the fix.
- Limited context: Usually sees one domain or one sent message at a time.
Suped platform
- Report history: Processes the DMARC aggregate reports received for your domains.
- Actionable fixes: Detects issues and shows steps to fix them.
- Scaled domains: Supports MSP and multi-tenant workflows for many domains.
Use free tools for quick checks and learning. Use Suped to review source history, assign authentication fixes, and assess policy changes against reported traffic. Continue testing indirect delivery paths before enforcement.
Views from the trenches
Best practices
Check DNS records first, then send a real test message to verify authentication results.
Review DMARC aggregate reports before enforcement so legitimate senders stay visible.
Keep a sender inventory with each owner, envelope-sender domain, SPF include and DKIM selector.
Common pitfalls
Treating one green DNS check as proof that every marketing and billing sender works.
Publishing strict DMARC before each approved sending source passes authentication.
Leaving stale SPF includes until an evaluation exceeds ten terms that cause DNS lookups.
Expert tips
Use separate selectors for major senders so DKIM rotation and failures are easier to trace.
Check blocklist and blacklist status after authentication when delivery still looks poor.
Review reports and mailing-list use before choosing a stricter DMARC enforcement policy.
Marketer view
A marketer in Email Geeks says a single-message test makes one authentication path easier to understand.
2025-04-23 - Email Geeks
Marketer view
A marketer in Email Geeks says testing the message actually sent catches failures that DNS alone cannot show.
2025-04-23 - Email Geeks
Frequently asked questions
One free tool can check a lot, but it cannot prove everything. Use a DNS checker for records, then send a real message to confirm SPF, DKIM, and DMARC results in headers.
SPF can pass for the bounce domain while the visible From domain is different. DMARC needs SPF or DKIM to pass with a domain that matches the visible From domain under its matching rules.
DMARC can pass through SPF alone when its domain matches the From domain, but configure DKIM as well. Forwarding often breaks SPF while an intact DKIM signature can survive. Gmail's sender requirements require both SPF and DKIM, plus DMARC, for senders reaching its 5,000-message daily bulk threshold.
A p=none record requests no DMARC enforcement. Add a working rua destination to collect aggregate reports, then fix legitimate senders before considering quarantine or reject. Review mailing-list traffic before selecting reject for a general-purpose email domain.
RFC 9989 removed pct because receivers applied percentage values inconsistently. The t tag now requests test handling, but it does not provide a percentage rollout and receivers can apply local policy.
Move when you have multiple senders, more than one domain, a compliance requirement, or a plan to enforce DMARC. Suped turns aggregate reports into source visibility, alerts, and clear fix steps.
