What is SPF and why does it matter?

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which IP addresses are authorised to send mail using your domain. Without a valid SPF record, any server on the internet can send email appearing to come from your domain — and many receivers will junk or reject your legitimate mail because they can't verify it.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message, proving the email hasn't been tampered with and was authorised by your domain. Each mail provider publishes a public key in DNS under a 'selector' — we probe around 20 common selectors including Google, Microsoft 365, Mailchimp, SendGrid and others.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells receivers what to do when a message fails both — nothing (p=none), send it to junk (p=quarantine), or reject it (p=reject). It also sends aggregate reports showing who is sending mail using your domain so you can spot abuse.

My DMARC policy is p=none. Is that a problem?

p=none is monitoring mode — it doesn't block any mail. It's fine as a starting point because it lets you collect reports and identify all your legitimate senders before enforcing anything. The problem is that most organisations stay on p=none indefinitely, giving attackers a free pass to impersonate them. Once you've reviewed your reports and confirmed your senders, tighten to p=quarantine then p=reject.

Why weren't any DKIM selectors found for my domain?

DKIM selectors are arbitrary strings chosen by your mail provider. If yours uses a non-standard selector (like your domain name, or a custom string), it won't appear in our list of common selectors. Check your mail provider's setup documentation for the selector name, then look up ._domainkey.yourdomain.com using our DNS lookup tool.

What is the SPF 10-lookup limit?

RFC 7208 limits SPF evaluation to 10 DNS lookups. Each include:, a:, mx: and redirect= mechanism triggers at least one lookup. Exceeding 10 causes a 'permerror' — receivers may treat your mail as failing SPF entirely, even though it's legitimate. Complex records with many includes (Microsoft 365 + Google + Mailchimp + SendGrid) commonly hit this limit.

How do I check my SPF, DKIM and DMARC records?

Type your domain into the box above and click "Check domain". This free SPF, DKIM and DMARC checker queries live public DNS in your browser and returns your SPF record (with its policy and DNS-lookup count), any DKIM keys it finds across ~20 common selectors, and your DMARC policy and reporting setup — no command line, account or signup required. SPF lives in a TXT record at your domain's apex, DKIM under ._domainkey.yourdomain.com, and DMARC under _dmarc.yourdomain.com.

All free tools SPF/DKIM/DMARC checker

FREE TOOL

SPF, DKIM & DMARC checker.

Run a full email authentication check on any domain in five seconds. This free SPF, DKIM and DMARC checker reads your SPF record and its DNS-lookup count, probes ~20 common DKIM selectors, and grades your DMARC policy and reporting — straight from public DNS. No signup. No account. Just answers.

No signup · runs in your browser · also try our MX lookup, DNS lookup and blacklist checker.

How to check your email authentication in 3 steps

1
Enter the domain in the box above (e.g. example.com.au) and click Check domain.
2
Read the SPF, DKIM & DMARC results. Each is marked pass, warn or fail, with the live record and what it means.
3
Fix what's flagged. Tighten a loose SPF record, publish a DKIM key under the right selector, and move DMARC from p=none toward enforcement.

SPF, DKIM & DMARC at a glance

The three email-authentication standards do different jobs and live in different DNS records. Here's how they fit together.

Mechanism	What it proves	Where it lives (DNS)
SPF	Which IP addresses are authorised to send mail using your domain.	TXT at the domain apex (v=spf1 …)
DKIM	A cryptographic signature proving the message wasn't altered and was authorised by your domain.	TXT at <selector>._domainkey.yourdomain.com
DMARC	The policy + reporting that ties SPF and DKIM together and tells receivers what to do on failure.	TXT at _dmarc.yourdomain.com (v=DMARC1 …)

What this checks

SPF (Sender Policy Framework)

Tells receiving mail servers which IPs are allowed to send mail using your domain in the From address. Get it wrong and your legitimate mail gets junked, or worse — attackers can pass SPF while spoofing you. We check whether you have a record, whether it ends in -all (strict) or ~all (soft fail), and whether you're close to the 10-DNS-lookup limit that breaks SPF silently.

DKIM (DomainKeys Identified Mail)

Cryptographically signs each outgoing mail so receivers can verify it really came from you. Each provider uses a "selector" (a label) to name their key — Google uses google, Microsoft 365 uses selector1 / selector2, others use their own. We probe ~20 common selectors and tell you which ones are publishing keys.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Tells receivers what to do when mail fails SPF or DKIM, and where to send reports. Without DMARC, attackers can impersonate your domain freely. We check the policy (none = monitoring, quarantine = junk, reject = block), enforcement percentage, and whether you're collecting reports.

MX (Mail Exchange)

Just for context — tells you where mail to this domain actually lands. We identify common providers (Google Workspace, Microsoft 365, ProtonMail, etc.) so you know what stack you're working with.

Common email-auth problems we fix

An email authentication check often surfaces issues that quietly hurt deliverability or leave you open to spoofing. The ones we see most:

SPF 10-lookup limit exceeded

Too many include: mechanisms (M365 + Google + Mailchimp + SendGrid) push you past the RFC 7208 limit and SPF permerrors silently. Read the fix →

DMARC stuck at p=none

Monitoring mode blocks nothing. Stay here for years and attackers can impersonate you freely. Why p=none isn't enough →

DKIM not aligned

Mail is signed, but with a domain that doesn't match the From header — so DKIM passes yet DMARC still fails. A classic relay/forwarding trap.

Missing DMARC entirely

No _dmarc record means no policy and no reports — you can't see who's sending as you, let alone stop them.

Want spoofing shut down for good?

Edos Solutions designs, deploys and monitors SPF, DKIM and DMARC for Australian organisations — taking you from p=none to enforced p=reject without breaking a single legitimate sender.

Explore Mail Shield Talk to us

Privacy

Lookups happen in your browser via Cloudflare's public DNS-over-HTTPS endpoint. Edos Solutions doesn't log the domains you check, doesn't run any analytics on this page, and doesn't capture your IP. The only record of your queries is in your own browser's network tab.

References

RFC 7208, SPF.
RFC 6376, DKIM.
RFC 7489, DMARC.

Frequently asked questions

What is SPF and why does it matter?: SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which IP addresses are authorised to send mail using your domain. Without a valid SPF record, any server on the internet can send email appearing to come from your domain — and many receivers will junk or reject your legitimate mail because they can't verify it.
What is DKIM?: DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message, proving the email hasn't been tampered with and was authorised by your domain. Each mail provider publishes a public key in DNS under a 'selector' — we probe around 20 common selectors including Google, Microsoft 365, Mailchimp, SendGrid and others.
What is DMARC?: DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells receivers what to do when a message fails both — nothing (p=none), send it to junk (p=quarantine), or reject it (p=reject). It also sends aggregate reports showing who is sending mail using your domain so you can spot abuse.
My DMARC policy is p=none. Is that a problem?: p=none is monitoring mode — it doesn't block any mail. It's fine as a starting point because it lets you collect reports and identify all your legitimate senders before enforcing anything. The problem is that most organisations stay on p=none indefinitely, giving attackers a free pass to impersonate them. Once you've reviewed your reports and confirmed your senders, tighten to p=quarantine then p=reject.
Why weren't any DKIM selectors found for my domain?: DKIM selectors are arbitrary strings chosen by your mail provider. If yours uses a non-standard selector (like your domain name, or a custom string), it won't appear in our list of common selectors. Check your mail provider's setup documentation for the selector name, then look up <selector>._domainkey.yourdomain.com using our DNS lookup tool.
What is the SPF 10-lookup limit?: RFC 7208 limits SPF evaluation to 10 DNS lookups. Each include:, a:, mx: and redirect= mechanism triggers at least one lookup. Exceeding 10 causes a 'permerror' — receivers may treat your mail as failing SPF entirely, even though it's legitimate. Complex records with many includes (Microsoft 365 + Google + Mailchimp + SendGrid) commonly hit this limit.
How do I check my SPF, DKIM and DMARC records?: Type your domain into the box above and click "Check domain". This free SPF, DKIM and DMARC checker queries live public DNS in your browser and returns your SPF record (with its policy and DNS-lookup count), any DKIM keys it finds across ~20 common selectors, and your DMARC policy and reporting setup — no command line, account or signup required. SPF lives in a TXT record at your domain's apex, DKIM under <selector>._domainkey.yourdomain.com, and DMARC under _dmarc.yourdomain.com.

All free tools MX lookup tool Blacklist checker Domain security checker