DMARC, SPF & DKIM Checker & Fixer
Email authentication is fiddly and the error messages are cryptic, so most domains stall at “monitor only” and never reach real protection. Type your domain below and we resolve its live DNS. This tool reads each record the way a receiving mail server does, names every problem in plain language, hands you corrected records to publish, and walks you step by step to p=reject — the full enforcement Google and Yahoo now expect from bulk senders.
SPF, DKIM and DMARC together prove an email genuinely came from your domain. SPF lists who may send for you; DKIM cryptographically signs your mail; DMARC tells receivers what to do when a message fails both and aligns neither — and sends you reports. The goal is p=reject, where spoofed mail is refused outright. Enter a domain and this tool queries its live DNS — SPF at the root, DMARC at _dmarc, and DKIM at your selector — audits exactly what is published, generates corrected records, and gives you the safe, staged path to full enforcement.
DMARC, SPF & DKIM Checker inputs and result
How to use this calculator
- Enter your domainType a bare domain or a full URL — the tool resolves it to the registrable host, then queries SPF at the root, DMARC at _dmarc, and DKIM at your selector.
- Add your DKIM selector (or leave it blank)Enter the selector your platform signs with, for example google or selector1. Leave it blank and the tool probes a short list of common selectors and reports which resolve.
- Pick your enforcement targetChoose the end state you are building toward. Reject is the recommended goal and what bulk-sender rules reward; quarantine is solid protection; audit publishes p=none so you can start collecting reports safely.
- Click Check recordsThe tool resolves the live DNS and audits each record, giving every one a pass, warn or fail with the exact reason in plain language — the lookup count, the all-qualifier, the key size, the policy, the reporting address and alignment.
- Copy the generated records and follow the planCopy the corrected SPF and DMARC records into DNS, then work down the staged rollout: monitor at p=none, authenticate every sender, ramp quarantine, and finish at p=reject.
RGM Expert Says
The single biggest deliverability mistake we see is a DMARC record stuck at p=none for years. The domain owner published it, saw reports arrive, felt protected, and stopped. But p=none blocks nothing — a spoofer can still send invoices and password resets that look exactly like yours. The whole point of DMARC is to reach p=reject, and the only thing standing between most teams and that goal is a clear, staged path. That is what this tool exists to give you.
The order of operations matters more than people expect. DMARC enforces only when a message passes SPF or DKIM and the passing identifier aligns with the visible From domain, so authentication has to be solid first. We always fix SPF and DKIM, confirm alignment in the aggregate reports, and only then start tightening the policy. Rushing to p=reject before your legitimate senders are authenticated is how a team ends up blocking its own payroll provider on a Friday afternoon.
Since Google and Yahoo’s 2024 bulk-sender rules, this stopped being optional housekeeping. If you send more than about 5,000 messages a day to their users, you need SPF and DKIM with alignment, a published DMARC record, one-click unsubscribe, and a spam-complaint rate under 0.3 percent. We treat the rules as a floor, not a ceiling: get to p=reject, keep complaints under 0.1 percent, and your inbox placement and your brand both benefit.
How it works
The tool looks up your domain’s live DNS through the RGM Tools resolver (Cloudflare DNS-over-HTTPS with a Google fallback), then parses each record with the same rules a receiving mail server applies, scores readiness, and builds corrected records. The lookups are read-only; nothing about your domain is stored.
It reads three names: your SPF record at the root domain, your DMARC record at _dmarc.<domain>, and your DKIM key at <selector>._domainkey.<domain>. What it cannot see is whether your live mail is actually aligning in the wild — only your DMARC aggregate reports show that — so treat those reports as the source of truth before you tighten the policy.
- SPF — a TXT record listing the servers allowed to send mail for your domain, ending in an
allmechanism (-allmeans hard-fail everything else). - DKIM — a cryptographic signature on each message, verified against a public key you publish at
selector._domainkey. 2048-bit RSA is the current recommendation. - DMARC — the policy (
p=none,quarantineorreject) telling receivers what to do with mail that fails SPF and DKIM, plus therua=address that sends you reports. - Alignment — the requirement that the SPF or DKIM domain match your visible From domain. Without alignment, a technically-passing message still fails DMARC.
- Readiness score — RGM’s rollup of the three records into one number, weighted toward the DMARC policy because that is what actually stops spoofing.
Syntax follows RFC 7208 (SPF), RFC 7489 (DMARC) and RFC 8301/6376 (DKIM). The readiness score is RGM’s own weighting, not a standard. The DKIM key-size figure is estimated from the public-key length and is directional, not a cryptographic parse.
Why p=none is not protection
A DMARC record at p=none tells receivers to take no action when mail fails authentication — it only asks for reports. That is the correct way to begin, because it lets you discover every legitimate sender before you risk blocking one. But a domain that lives at p=none for months is publishing a policy that protects nobody. Attackers can still spoof your domain in phishing and invoice fraud, and the receiver will deliver it.
The reason teams stall is fear, and the fear is reasonable: tightening the policy before your real senders are authenticated will quarantine or reject your own mail. The cure is not to avoid enforcement; it is to advance in stages you can watch. Monitor at p=none, read the aggregate reports until every legitimate source passes SPF or DKIM with alignment, then ramp p=quarantine by percentage, and only then move to p=reject. Each step is reversible and visible in the reports.
Since February 2024, Google and Yahoo require bulk senders — roughly anyone sending over 5,000 messages a day to their users — to authenticate with SPF and DKIM, publish a DMARC record, offer one-click unsubscribe, and keep spam complaints under 0.3 percent. From late 2025 the enforcement tightened to outright rejection of non-compliant mail. Reaching p=reject is no longer a nice-to-have; it is the cost of landing in the inbox at scale.
What good looks like for each record
Directional targets for a healthy, enforceable setup. Your own DMARC aggregate reports are the source of truth for whether real mail is aligning.
| Record | Healthy setting | Common failure |
|---|---|---|
| SPF all-qualifier | <code>-all</code> (hard fail) | <code>+all</code> authorizes the world; <code>?all</code>/<code>~all</code> left in place |
| SPF DNS lookups | 10 or fewer | 11+ → PermError, SPF fails for everyone |
| DKIM key length | 2048-bit RSA (or Ed25519) | 1024-bit, or an empty / revoked <code>p=</code> |
| DMARC policy | <code>p=reject</code> | Stuck at <code>p=none</code> for months |
| DMARC reporting | <code>rua=</code> address set | No <code>rua</code> — advancing blind |
| Alignment | Relaxed, From matches signer | Mail passes SPF/DKIM but does not align |
| Bulk-sender bar | DMARC + SPF/DKIM + 1-click unsub | Spam complaints over 0.3% |
What deliverability practitioners say
DMARC at p=none is a smoke detector with the battery taken out. It tells you there is smoke; it does nothing about the fire. The job is to get to reject.
Starting February 2024, bulk senders must authenticate their email with SPF and DKIM, publish a DMARC policy, and keep reported spam rates below a clear threshold.
Go deeper on deliverability
Keep learning
Common questions
Does this tool look up my live DNS records?
_dmarc.<domain>, and DKIM at <selector>._domainkey.<domain> — and audits exactly what is published right now. The one thing live DNS cannot show is whether your real mail is aligning in the wild; for that, read your DMARC aggregate reports.What is the difference between SPF, DKIM and DMARC?
What does p=reject actually do?
p=reject, a receiving mail server refuses any message claiming to be from your domain that fails SPF and DKIM and aligns neither. It is the strongest DMARC policy and the one that genuinely stops domain spoofing. p=quarantine sends such mail to spam instead, and p=none only monitors.Why does my SPF record fail with too many DNS lookups?
include, a, mx, ptr, exists and redirect, counting nested includes. Past 10, receivers return a PermError and SPF fails for everyone. Fix it by consolidating or flattening includes and removing vendors you no longer use.Should I use a 1024-bit or 2048-bit DKIM key?
How long does it take to safely reach p=reject?
p=none while you authenticate every legitimate sender, then ramp p=quarantine at 25, 50 and 100 percent over a few weeks, watching aggregate reports at each step, before switching to p=reject. Complex senders with many third-party tools take longer.