What this email deliverability checker actually tests
Every check above is a public DNS lookup. Four records decide whether a receiving provider can prove your mail is really yours: SPF, DKIM, DMARC, and MX. Get them wrong and even perfectly written email lands in spam. Here is what each one does, how it fails in practice, and the exact fix.
SPF: which servers are allowed to send as you
An SPF (Sender Policy Framework) record is a single TXT record on your root domain that lists every service permitted to send mail using your domain in the envelope sender. When Gmail receives a message claiming to be from you, it fetches this record and checks whether the connecting IP is on the list.
Type: TXT
Name: @ (your root domain)
Value: v=spf1 include:_spf.google.com include:sendgrid.net ~all
How SPF usually breaks
- Two SPF records. The single most common failure. Publishing a second
v=spf1TXT record is a permanent error — receivers stop evaluating and the check fails outright. Merge everyinclude:into one record. - More than 10 DNS lookups. Each
include:,a,mx, andredirectcosts a lookup, and nested includes count too. Exceed ten and you get apermerror. Drop services you no longer use, or flatten the record. - Ending in
+all. This authorises the entire internet to send as your domain. Use~all(softfail) while you roll out, then-all(hardfail) once you are confident the list is complete. - A new sending tool that was never added. If you started using a cold email platform last week and never touched DNS, its IPs are unauthorised.
DKIM: a cryptographic signature on every message
DKIM (DomainKeys Identified Mail) signs outgoing mail with a private key held by your sending provider. The matching public key lives in DNS at <selector>._domainkey.yourdomain.com. Receivers fetch it and verify the signature, which proves the message was not altered in transit and really came from an authorised sender.
Type: TXT
Name: google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhki...
The selector is chosen by your provider — Google Workspace uses google, Microsoft 365 uses selector1 and selector2, Mailchimp uses k1, Cloudflare Email Routing uses cf2024-1. The checker above probes the common ones, so a blank result does not always mean DKIM is missing: it may simply mean your provider uses a custom selector name.
How DKIM usually breaks
- The record was never published. Providers generate the key but you have to add it to DNS yourself. This step gets skipped constantly.
- The key was rotated and DNS was not updated. Microsoft 365 rotates selectors; if the CNAMEs were pasted as TXT records, rotation silently breaks signing.
- The value got truncated. Long public keys exceed the 255-character limit of a single TXT string. Most DNS hosts split it automatically; some do not, and a truncated key fails every verification.
- Only one of several senders is signing. Each platform you send from needs its own selector.
DMARC: your instructions for failed mail
SPF and DKIM prove identity. DMARC tells receivers what to do when that proof fails, and asks them to report back. It also enforces alignment — the domain in the visible From: header must match the domain that passed SPF or DKIM, which is what stops an attacker from passing SPF on their own domain while displaying yours.
Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected]; pct=100
Rolling DMARC out without losing mail
p=none— monitor only. Nothing is blocked; you just collect aggregate reports at theruaaddress. Stay here for two to four weeks.p=quarantine— failing mail goes to spam. Move here once reports show all your legitimate senders passing.p=reject— failing mail is refused. This is the end state, and since 2024 it is effectively expected of bulk senders by Google and Yahoo.
Publishing p=none and never moving on is the most common DMARC mistake. It satisfies a checkbox but provides no protection, and a policy of none with no rua address gives you neither enforcement nor visibility.
MX: can your domain receive replies?
MX records point at the servers that accept mail for your domain. They matter for sending too: a domain that cannot receive mail looks disposable, bounces are undeliverable, and cold outreach replies vanish. If you send from a domain with no MX record, providers notice.
Type: MX Priority: 1 Value: aspmx.l.google.com
Type: MX Priority: 5 Value: alt1.aspmx.l.google.com
Lower priority numbers are tried first. Common failures: no MX at all on a freshly registered outreach domain, records still pointing at a decommissioned host, or a registrar parking-page MX left in place after migration.
What DNS records cannot tell you
Passing all four checks is table stakes, not a guarantee. Authentication proves who you are; it says nothing about whether providers want your mail. Inbox placement is also driven by:
- Sending volume and ramp. A brand-new domain that sends 500 emails on day one looks exactly like a spammer, fully authenticated or not.
- Engagement. Opens, replies, and messages moved out of spam are the strongest positive signals a mailbox provider has.
- Complaints and bounces. A spam-complaint rate above roughly 0.3%, or a high bounce rate from stale lists, will sink an otherwise perfect setup.
- Domain and IP age. Reputation accrues slowly and is lost quickly.
That last set is what warmup addresses. EmailWarmup gradually raises volume from a new mailbox, exchanges AI-generated conversations with a community network so replies and opens are real, and rescues warmup mail that lands in spam — building the engagement history DNS records cannot create. You can start free with one mailbox, or read how it compares to Lemwarm and Mailwarm.
Email deliverability FAQ
Is this SPF and DMARC checker really free?
Yes, with no signup and no limits. The lookups run in your browser against Cloudflare's DNS-over-HTTPS resolver, so nothing about your domain is sent to or stored on our servers.
Why does the checker say my DKIM record is missing when I know it is set up?
DKIM keys are published under a provider-specific selector, and there is no way to discover an arbitrary selector from DNS. The tool probes the common ones — google, selector1, selector2, k1, default, cf2024-1 for Cloudflare Email Routing, plus the Fastmail, Proton Mail and Zoho selectors. If your provider uses a custom selector, look the record up directly at yourselector._domainkey.yourdomain.com.
How long do DNS changes take to apply?
Usually minutes to a few hours, bounded by the TTL of the record you replaced. Lowering the TTL before a planned change shortens the wait. Re-run the check after an hour; if it still shows the old value, the change probably was not saved at your DNS host.
Do I need SPF, DKIM and DMARC to send cold email?
Yes. Since February 2024, Google and Yahoo require SPF, DKIM, and a DMARC record for bulk senders, along with one-click unsubscribe and a spam-complaint rate under 0.3%. Without all three, volume sending to those providers is unreliable at best.
My DNS is perfect but I still land in spam. What now?
That points at reputation rather than authentication — usually a domain that is too new, volume that ramped too fast, poor list quality, or spam-triggering content. Warm the domain up gradually, clean the list, and build genuine engagement before scaling volume.