SPF / DKIM / DMARC Validator

Validate email authentication records, detect spoofing risk, and find deliverability issues.

How SPF, DKIM, and DMARC work together

Email authentication is built from three layers that must all work together. SPF verifies the sending server. DKIM verifies the message content. DMARC tells receiving servers what to do when either check fails — and reports back to you.

SPF — Sender Policy Framework

A DNS TXT record at your domain root that lists the mail servers authorised to send email on your behalf. When a receiving server gets a message from your domain, it checks the sending server's IP against your SPF record.

The record ends with an "all" mechanism that defines the default action: -all (reject), ~all (softfail / mark as suspicious), ?all (neutral), or +all (pass everything — insecure).

DKIM — DomainKeys Identified Mail

Uses asymmetric cryptography to sign outgoing messages. Your mail server adds a digital signature to each email's headers using a private key. Receiving servers retrieve your public key from DNS and verify the signature.

A valid DKIM signature proves the message came from your domain and was not modified in transit. It also ties your sending reputation to your domain name, which improves inbox placement over time.

DMARC — Policy and Reporting

A DNS TXT record at _dmarc.yourdomain.com that tells receiving servers what to do with messages that fail SPF or DKIM, and how to report failures back to you. The three policies are:

  • p=none — monitor only; do not filter
  • p=quarantine — send failing mail to spam
  • p=reject — block failing mail entirely

DMARC alignment

For DMARC to pass, either SPF or DKIM must pass and the authenticated domain must align with the From: domain. Alignment can be relaxed (subdomain match is enough) or strict (exact domain match required).

This alignment requirement is what prevents attackers from using your domain in the visible From: header even if they can pass SPF from a different domain.

Deployment sequence: Start with SPF → add DKIM → add DMARC at p=none → review aggregate reports → move to p=quarantine → move to p=reject. Skipping any step risks breaking legitimate mail delivery.

Common email authentication mistakes

Critical mistakes

  • Using +all in SPF — allows any server on the internet to send email as your domain
  • No DMARC record — emails claiming to be from your domain can reach inboxes with no enforcement
  • Leaving DMARC at p=none indefinitely — provides visibility but no protection
  • Exceeding the SPF 10 DNS lookup limit — causes PermError and SPF failures
  • No DKIM signing — emails are unverifiable and may be treated as lower quality by spam filters

Configuration warnings

  • Using 1024-bit DKIM keys — considered weak; upgrade to 2048-bit
  • No DMARC rua reporting — you cannot see who is sending email as your domain
  • Adding mail providers without updating SPF — legitimate mail starts failing
  • Setting DMARC to p=reject without reviewing reports first — legitimate mail may be blocked
  • Publishing DMARC before DKIM is configured — DMARC without DKIM is weakened

The SPF 10 DNS lookup limit

RFC 7208 defines a hard limit of 10 DNS lookups per SPF evaluation. Every include:, a, mx, ptr, and exists mechanism counts as one lookup, including those inside included records. Organisations that use multiple email providers (newsletter platform, CRM, helpdesk, transactional email) frequently hit this limit.

When the limit is exceeded, receiving servers can return a PermError and treat the message as failing SPF, even if the sending server is legitimately authorised. To fix this, replace a: and mx: references with ip4: / ip6: ranges, or use an SPF flattening service to pre-resolve include chains into direct IP blocks.

Frequently asked questions

What is SPF?

SPF (Sender Policy Framework) is a DNS record that authorises which mail servers may send email on behalf of your domain. Receiving servers check the sending IP against your SPF record. If it is not listed, the message can be flagged or rejected depending on your policy.

What is DKIM?

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key. Receiving servers verify the signature using a public key published in your DNS. A valid signature confirms the message came from your domain and was not modified in transit.

What is DMARC?

DMARC builds on SPF and DKIM by publishing a policy that tells receiving servers what to do with messages that fail authentication — monitor, quarantine, or reject. It also enables aggregate and forensic reporting so you can see who is sending email as your domain.

Can my domain be spoofed if DMARC is set to p=none?

Yes. DMARC p=none is monitoring-only. It generates reports but instructs no filtering. Spoofed emails claiming to be from your domain will still be delivered to recipients' inboxes. Moving to p=quarantine then p=reject is required for active protection.

What DMARC policy should I use?

Start with p=none to collect reports and identify all legitimate senders. Once your SPF and DKIM are fully configured and reports show no false positives, move to p=quarantine. After confirming no legitimate mail is being filtered, advance to p=reject for full protection.

What does SPF's 10 DNS lookup limit mean?

SPF evaluation is limited to 10 DNS lookups. Each include:, a, mx, ptr, and exists mechanism counts as one. If your record triggers more than 10, receiving servers can return a PermError and fail SPF — even for legitimate senders. Flatten your SPF or use ip4:/ip6: to reduce lookups.

Should I use -all or ~all in SPF?

~all (softfail) is a safe starting point — unauthorized mail is accepted but tagged. Once you are confident all legitimate senders are in your SPF record, switch to -all (hard fail) to reject unauthorized senders. Never use +all, which permits every server on the internet.

Why are my emails going to spam?

Authentication failures are among the most common causes. Check that SPF is configured and uses -all or ~all, that DKIM is signing emails from all your sending services, and that DMARC is in place. Other factors include high complaint rates, sending from new IPs, low engagement, and content triggers.

How do I check DKIM when I don't know the selector?

This tool automatically checks 10 common selectors: google, selector1, selector2, default, dkim, k1, s1, s2, mail, and email. You can also enter a custom selector in the optional field. To find your selector, look in your email platform's DNS configuration page — it is usually shown alongside the DKIM public key.

What is a 1024-bit DKIM key and why is it a warning?

DKIM signs emails using RSA public-key cryptography. A 1024-bit RSA key was the standard 10 years ago but is now considered weak by modern security standards. NIST and most security guidelines recommend 2048-bit or larger. Most email providers support generating 2048-bit DKIM keys in their settings.