Check your SPF, DKIM & DMARC records in one go
Enter a domain and a single run tests all three authentication records for presence, syntax, DNS lookup limits, policy strength and reporting - the checks Gmail and Yahoo expect you to pass.
How the combined check runs
One submission triggers a fixed sequence of DNS queries and evaluations. Nothing is skipped, so the grades you see cover the full authentication setup of the domain.
SPF Discovery
The domain's TXT records are fetched and scanned for one starting with v=spf1.
SPF Evaluation
Mechanisms are parsed and the DNS-lookup cost is counted against the limit of 10.
DKIM Probing
Common selectors are queried under selector._domainkey until a public key answers.
DKIM Key Review
The p= tag is checked for presence and strength, so revoked or weak keys stand out.
DMARC Retrieval
The _dmarc record is fetched and its policy tags are parsed one by one.
Grading & Fixes
Each record receives pass, warn or fail together with a fix list for anything missing.
Three records, graded together
A single run inspects each record on its own terms and then weighs them as a set, because that is how receiving mail servers judge your domain.
Presence and syntax per record
SPF, DKIM and DMARC are each graded on existence and valid formatting, so typos and missing records surface immediately.
SPF lookup budget
The 10-lookup ceiling from RFC 7208 is enforced during evaluation, and PermError risks are flagged before receivers void your record.
DKIM selector probing
When you do not know your selector, well-known candidates such as google, selector1 and selector2 are tried automatically.
DMARC tag breakdown
The p=, sp=, rua= and pct= tags are pulled out of the record and explained in plain language.
An issue list you can act on
Every warning names its fix, so you know which record to edit and what the corrected version should contain.
Receiver requirements built in
The checks cover what Gmail, Yahoo and Microsoft expect from bulk senders, which goes beyond what the base specifications alone ask for.
What pass and fail look like
Two illustrative runs on made-up domains, side by side. Enter a real domain above for live results.
acme-corp.example
- SPF8 of 10 lookups
- DKIMSelector google found
- DMARCp=reject, rua set
legacy-shop.example
- SPF12 lookups, PermError risk
- DKIMNone found
- DMARCMissing
Why receivers care about all three
Since February 2024, Google and Yahoo have required bulk senders to publish SPF and DKIM plus a DMARC record, and Microsoft announced matching rules for Outlook.com high-volume senders in May 2025. A partial setup still leaks: SPF alone cannot survive forwarding, DKIM without DMARC gives receivers no policy to enforce, and DMARC over broken SPF and DKIM fails everything it watches.
Meet bulk-sender mandates
Inbox placement now depends on passing these checks. Records in shape keep your campaigns in front of customers instead of spam filters.
Stop direct spoofing
With all three records enforced, unauthenticated mail cannot pose as your domain in a customer's inbox.
Survive forwarding
Forwarding breaks SPF, but DMARC over aligned DKIM still passes, so redirected mail stays authenticated on the way to its final destination.
See abuse attempts
With rua= configured, aggregate reports show you who is sending as your domain and whether their mail passes authentication.
Who runs this check, and when
Pick a role to see where the combined check fits into the working week.
Migration readiness
- List every domain your infrastructure sends from
- Run the combined check on each domain above
- Publish the missing SPF, DKIM or DMARC records
- Re-run the checker until every grade reads pass
Client domain audit
- Collect the client domains you send for
- Grade all three records per domain in one run
- Hand over a per-domain issue list with fixes
- Re-check after changes land in their DNS
Transactional sender setup
- Get the DKIM selector your mail provider publishes
- Enter the sending domain and selector above
- Fix whatever the check flags before launch
- Confirm a clean pass, then switch on transactional sends
Mandate evidence
- Enumerate the domains covered by receiver mandates
- Capture the pass, warn or fail grade for each record
- Attach the results to your compliance evidence pack
- Schedule a re-check after every DNS change
Verify it yourself, then fix it
The checker reads public DNS, so nothing hides from you. Prefer the command line? These three queries read exactly what our checker reads:
dig TXT example.com +short
dig TXT selector._domainkey.example.com +short
dig TXT _dmarc.example.com +short
The first returns your SPF record (v=spf1 ...), the second your DKIM public key
for a given selector, and the third your DMARC policy. An empty answer means the record is
missing.
Common failures and fixes
| Symptom | What it means and the fix |
|---|---|
| No SPF record | Publish one TXT record starting with v=spf1, ending in an all mechanism such as -all. |
| More than 10 SPF lookups | Receivers return PermError because RFC 7208 caps the record at 10 lookups. Remove unused includes or flatten the record. |
| No DKIM key found | No selector is published yet, or the wrong one was queried. Ask your email provider for the exact selector name. |
Empty DKIM p= | The key was revoked. Publish a fresh key pair before sending signed mail again. |
DMARC p=none | Monitoring only. Once aggregate reports show every legitimate source passing, step up to quarantine, then reject. |
DMARC without rua | Nobody sees who sends as your domain. Add rua=mailto:[email protected]. |
Authenticate here, verify the mailboxes next
This page proves your domain is allowed to send. Emails Checker then confirms the individual mailboxes you are about to send to.
| Capability | Record CheckerThis page | Emails CheckerFull platform |
|---|---|---|
| Record checks | All three in one run | Not part of verification plans |
| Recipient verification | Not on this tool | Full SMTP mailbox checks |
| Bulk list screening | Not on this tool | CSV files of any size |
| Disposable detection | Not on this tool | Included |
| API access | Browser-based | Real-Time API |
| Account required | No | 100 free credits on signup |
Questions about the checker
selector._domainkey.yourdomain.com. Your email provider chooses it -
Google Workspace commonly uses google, Microsoft uses
selector1 and selector2. If you don't know yours, our
checker probes the most common selectors automatically.
p=none only asks for reports while spoofed mail still reaches
inboxes. It is the correct starting point for monitoring, but once aggregate
reports confirm every legitimate source passes, move to p=quarantine
and then p=reject.
include, a, mx,
exists and redirect term costs a DNS lookup, and RFC 7208
caps a record at 10. Exceeding it returns PermError and voids the record. Remove
unused includes or apply SPF flattening to stay under the limit.