Email Authentication Checker

SPF, DKIM and DMARC - what they are and why yours is probably wrong

Most people find out their email authentication is broken when something goes wrong. Emails start hitting spam, a customer asks why your messages keep missing, or someone forwards you a phishing email using your domain. The damage is usually already running by then.

Three DNS records. Three questions receiving mail servers ask about every email they get. SPF - is this server allowed to send from this domain? DKIM - has this message been touched since it left the sender? DMARC - what should we do if either of those checks fail?

SPF is a TXT record in your DNS. You list the servers and services that legitimately send email for you, and the policy suffix says what to do with anything outside that list. The catch that bites people: one SPF record, full stop. Two records is a permanent error per the RFC. Lots of mail servers try anyway, but plenty just fail. We see this constantly on domains that have quietly added new sending tools over the years without touching the old record.

DKIM is a cryptographic signature on every outgoing email. Private key on your server, public key in DNS. When a receiving server gets your message, it pulls the public key, checks the signature, and decides whether it trusts the content. No match means something changed in transit - or the email is a forgery. Google and Yahoo turned this into a firm requirement for bulk senders in January 2024. Others are heading the same way.

DMARC is where most domains stop short. The record is easy to add - p=none means monitor and report, don't act yet. The rua tag gives you an address for aggregate reports: who's sending email claiming to be from your domain, and whether it passes. Useful. What's not useful is sitting on p=none permanently. You get the data but no protection. Anyone can still drop your domain into a From header and send phishing.

What the checker actually does

Four lookups the moment you hit submit - SPF, DKIM across seven common selectors, DMARC, MX. No cache, always live. Green means clean, amber means worth looking at, red means broken or missing. Any failure comes with the actual fix text, not a vague pointer.

• SPF - finds the TXT record, checks the policy, flags +all (dangerous), multiple records (broken), or a missing record
• DKIM - tries selectors default, google, k1, mail, selector1, selector2, dkim - shows which resolve and the raw public key
• DMARC - reads the policy, reporting address and coverage percentage, flags if missing or stuck at p=none
• MX - lists mail exchange hosts with priority; flags if none exist

Fixes for what you're most likely to find

Two SPF records. Merge them into one. Take every include: and ip4: value and combine: v=spf1 include:one.com include:two.com ~all. Delete the duplicate.

SPF with +all. That tells the world any server can send as your domain. Change it to ~all first, then -all once your sender list is confirmed.

No DMARC. Start with v=DMARC1; p=none; rua=mailto:[email protected] - visibility without enforcement risk. Tighten it once SPF and DKIM are passing cleanly.

DKIM not found. Your provider might use a non-standard selector. Check their DNS settings page for the exact name, then verify it resolves.