Free SPF, DKIM and DMARC Check Online: No Signup

SPF, DKIM and DMARC are the three records that decide whether your mail is even allowed in the door at Gmail, Outlook and Yahoo. They are also the three records nearly every free checker makes you sign up to view. This article is about the mechanic — what each record does, how to read one, and how to check yours without handing over an address.

TL;DR

SPF says which IPs can send for your domain. DKIM signs each message cryptographically. DMARC tells receivers what to do when either fails, and enforces alignment. All three are DNS TXT records, all three are free to check, and you should not need an account to see them.

What each record does

SPF — Sender Policy Framework

SPF is a single TXT record at the root of your domain that lists every IP or ESP allowed to send mail on your behalf. When a receiver sees a message from you@yourdomain.com, it looks up your SPF record and checks whether the sending IP is in the allow list.

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

The qualifier at the end (~all, -all, ?all) controls what happens to mail from IPs that are not listed. ~all is soft-fail (still delivered, flagged). -all is hard-fail (usually rejected or moved to Spam).

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to every outgoing message. The public key lives in DNS at a per-ESP "selector" location. Gmail signs with selectors like 20230601._domainkey; SendGrid uses s1._domainkey and s2._domainkey; Microsoft 365 uses selector1 and selector2.

There is no universal selector name. To check DKIM you need to know which ESP you sign with, and look up the specific selector for that ESP.

DMARC — Domain-based Message Authentication

DMARC glues SPF and DKIM together. It lives at _dmarc.yourdomain.com and says: "when SPF or DKIM fails, here is what I want you to do — and here is where to send the reports."

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; adkim=s; aspf=s"

The p= tag is the policy: none (monitor only), quarantine (send failures to Spam), or reject (bounce outright). The adkim and aspf tags control alignment strictness.

How to read an SPF record

An SPF record is a single TXT string with space-separated mechanisms. Evaluated left to right:

v=spf1 — version identifier, always first.
include:_spf.google.com — delegate lookup to Google's record; any pass there passes here.
ip4:203.0.113.5 — literal IPv4 address allowed to send.
a / mx — the A or MX record of the domain is allowed.
~all / -all — the catch-all qualifier that closes the record.

The single most common mistake is blowing the 10-DNS-lookup limit. Every include:, a, mx, ptr and exists costs a lookup, and includes are evaluated recursively. One include:secureserver.net alone can consume six. Past ten, SPF returns permerror and every message fails.

DKIM selector lookup by name

Because DKIM selectors are ESP-specific, the check is "does TXT exist at <selector>._domainkey.yourdomain.com". A good free check accepts multiple common selectors at once and reports every match.

Selectors to test by default:

Google Workspace: google, 20230601
Microsoft 365: selector1, selector2
SendGrid: s1, s2, em
Mailgun: k1, mx
Postmark: 20180917184632pm (random per account)
Amazon SES: amazonses, random 20-char selectors

DMARC policy and alignment

A DMARC check answers three questions: does the record exist, what is the policy, and does it enforce alignment? Alignment means the From-header domain matches the SPF/DKIM domain. A message that passes SPF for sendgrid.net but has From: ceo@yourdomain.com is SPF-valid but DMARC-unaligned — the kind of gap phishers exploit.

adkim=s and aspf=s (strict alignment) require an exact domain match. adkim=r / aspf=r(relaxed, the default) accept any subdomain match. Strict closes more gaps but will break mail forwarded through mailing-list software. Start relaxed.

The three most common auth errors

SPF too many lookups — any record that chains through a reseller like GoDaddy's secureserver.net, plus Google Workspace and a third ESP, will blow the 10-lookup limit silently. Fix: flatten with a macro service or drop redundant includes.
DKIM selector wrong or missing — you enabled DKIM in your ESP but never copied the TXT record to DNS, or you copied it to the wrong selector name. Check by sending a test message and reading the Authentication-Results header.
DMARC stuck at p=none — publishing p=none and forgetting about it is the single most common state we see. You get no protection from p=none; it is a monitor-only policy meant for the first two weeks.

GlockApps' version of the same check

GlockApps runs SPF, DKIM and DMARC checks as part of its paid placement report. The underlying mechanic is identical to any free tool: DNS TXT lookups plus live alignment computation against a test message. There is no proprietary logic on the authentication side — what you pay for is the wrapper around it (dashboard, history, support).

GlockApps vs Inbox Check

Inbox placement test — GlockApps: $59/mo (3 free/mo) — Inbox Check: Free, 3/day
Providers — GlockApps: ~15 (no CIS, no EU) — Inbox Check: 20+ (Gmail, Outlook, Yahoo, Mail.ru, Yandex, Rambler, GMX, Orange, ProtonMail…)
Inbox screenshots — GlockApps: No — Inbox Check: Yes
SPF/DKIM/DMARC — GlockApps: In paid report — Inbox Check: Every test, free
SpamAssassin + Rspamd — GlockApps: SpamAssassin (paid) — Inbox Check: Both (free)
DNSBL check — GlockApps: Paid — Inbox Check: Free
MCP for AI agents — GlockApps: No — Inbox Check: Yes
Signup — GlockApps: Required — Inbox Check: Not required

Where paid still has an edge

For ongoing DMARC aggregate-report parsing — the XML files that land at your rua= address every day — a paid tool like GlockApps, DMARCian or Valimail has a real advantage. Parsing DMARC reports by hand is painful. A free one-off check does not replace that.

Using a free check in a daily workflow

A sensible loop for a solo sender or small team:

Paste the domain. Confirm SPF exists, passes syntax and is under 10 lookups.
Confirm DKIM is published at every selector your ESP uses, not just one.
Confirm DMARC exists, policy is at least quarantine, and rua= points to a monitored address.
Send a test message through the placement checker and read the Authentication-Results header. You want spf=pass, dkim=pass, dmarc=pass.
Re-run after any ESP change, domain move, or DNS edit. Two minutes.

Frequently asked questions

Why do most free SPF/DKIM checkers require signup?

To build an email list. The DNS lookups themselves are free and public. Anyone can query SPF with a one-line dig command. The "signup" requirement is marketing, not technical.

How can I check DKIM without knowing my selector?

Send a test message to a mailbox you control and read the Authentication-Results or DKIM-Signature header. The d= and s= tags in that header give you the domain and selector. Then query that selector in DNS.

Is p=reject safe to publish?

Only after 4–6 weeks of clean aggregate reports at p=quarantine. Going straight to p=reject on a domain with any third-party senders is how you break receipts, password resets and customer emails overnight.

Does DMARC alignment apply to replies and forwarded mail?

Forwarded mail often breaks SPF alignment because the forwarding server becomes the sender. DKIM survives forwarding if the message body is not modified. This is why relying on DKIM-only DMARC (ignoring SPF) is the industry default for transactional mail.

Free SPF, DKIM and DMARC check — no signup