Is my email going to spam? SPF, DKIM, and DMARC explained

The three records, in plain language

• SPF is a guest list. It is a DNS record that names the servers allowed to send mail for your domain. If a message arrives from a server that isn't on the list, the receiver knows it is suspicious.
• DKIM is a wax seal. Your server stamps each outgoing message with a cryptographic signature; the receiver verifies it against a public key in your DNS. If the message was altered or didn't come from you, the seal doesn't match.
• DMARC is the instruction sheet. It tells receivers what to do when SPF or DKIM fail — watch quietly (p=none), send it to spam (p=quarantine), or reject it outright (p=reject) — and where to send reports about it.

You need all three. SPF without DMARC is a guest list nobody enforces, and Gmail and Yahoo have required proper authentication for bulk senders since 2024 — missing records now mean spam folders or outright rejection, not a slap on the wrist.

Check your records in two minutes

On Mac or Linux, use dig. On Windows, swap in nslookup -type=TXT with the same names.

SPF — look for a TXT record starting with v=spf1:

dig +short TXT yourdomain.com
"v=spf1 include:_spf.google.com -all"

The ending matters: -all means "reject anything not on the list" (good), while ~all means "probably spam, but deliver anyway" — a softfail that many domains leave in place forever and spammers love. Also count theinclude: entries and any a, mx, orredirect terms: SPF allows at most 10 DNS lookups total, and going over makes the whole record fail with a permanent error.

DKIM — keys live under a "selector" name your mail provider chose:

dig +short TXT google._domainkey.yourdomain.com

Common selectors are google for Google Workspace andselector1 / selector2 for Microsoft 365; every other sender you use (your newsletter tool, your helpdesk, your invoicing app) has its own. A long v=DKIM1; k=rsa; p=... value means the key exists. No answer means that selector has no key published.

DMARC — one record, at a fixed name:

dig +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=quarantine; rua=mailto:[email protected]"

No answer here is the single most common finding: the domain has no DMARC at all, so anyone can send mail pretending to be it and receivers get no instructions to stop them.

The failures that actually send you to spam

• No DMARC record. Spoofing is wide open, and big receivers treat unauthenticated mail as guilty until proven innocent.
• A new sender was never added. You started using a newsletter or invoicing service, but its servers aren't in your SPF and it has no DKIM key in your DNS — so its mail "from you" fails authentication.
• SPF over the 10-lookup limit. Years of added services push the count over, SPF returns a permanent error, and every message fails.
• DMARC stuck at p=none. That setting is for monitoring only. It is the right place to start and a bad place to live — it enforces nothing.
• Your server is on a blacklist. If your sending IP got listed (a compromised form or a neighbor on shared hosting is enough), even perfectly authenticated mail gets filtered.

The fix order that works

1. List every sender. Mailbox provider, website forms, newsletter tool, invoicing, helpdesk — anything that sends as your domain.
2. SPF: include each sender, keep the total under 10 lookups, and end with -all.
3. DKIM: enable signing at each sender and publish every selector's key in your DNS.
4. DMARC: start at p=none with reports coming to you, read a week or two of reports to catch senders you missed, then step up to p=quarantine and finally p=reject.

Change one thing at a time and re-check after each step — DNS edits are small, but a typo in an SPF record can break mail for the whole domain.

The automated way

The PapaCasper MCP Toolbelt's email_deliverability_check tool runs this whole inspection in one call for $0.05: MX records and their reverse DNS, DKIM selector probing, the SPF lookup count against the 10-lookup limit, DMARC policy strength, and blacklist checks on your mail servers' IPs — returned as JSON an agent or script can act on, no signup or API key needed.

And if you'd rather not live in DNS records at all, this check is part of the done-for-you website audit I run — the details are onpapacasper.com.