SPF, DKIM and DMARC are DNS records that let a receiving mail server verify that a message claiming to be from a domain is genuine. SPF lists which servers may send as the domain, DKIM proves the message was not altered after it was signed, and DMARC tells a receiving server what to do when either check fails. A website audit reads all three from public DNS, because a domain that cannot authenticate its own mail is one that attackers can impersonate, and mailbox providers increasingly treat every message from that domain with more suspicion once trust is in doubt.
What do SPF, DKIM and DMARC each prove?
Each record answers a different question, and a domain needs all three to close the gap any one leaves open on its own.
| Record | Proves | If it's missing or broken |
|---|---|---|
| SPF | Which mail servers are authorized to send as this domain | A forged message can name this domain as the sender with nothing in DNS to contradict it |
| DKIM | That the message content was not altered after it was signed | A receiving server cannot verify the signature, so genuine mail is scored the same as the unverifiable kind |
| DMARC | What a receiving server should do with mail that fails SPF or DKIM, and where to send reports about it | There is no instruction at all, so every mailbox provider is left to guess on its own |
| BIMI | The verified logo a mailbox provider is allowed to show next to the message | No logo appears next to the brand's mail, even once SPF, DKIM and DMARC all pass |
| MTA-STS | That inbound mail to this domain must arrive over TLS, not a downgraded plain-text connection | A message in transit between mail servers can be intercepted or read |
Five DNS records cover most of what mailbox providers check before trusting a domain's mail. Each answers a different question, and a gap in any one leaves a receiving server guessing.
How strict should DMARC actually be?
DMARC's policy tag decides what happens to mail that fails, and most domains never move past the weakest setting.
DMARC enforcement is a ladder. Most domains start at none to collect reports safely, then climb once those reports show SPF and DKIM passing clean.
What does a broken setup look like in a real audit?
A record can exist in DNS and still fail every message it was meant to protect.
SPF record exceeds the ten-lookup limit
What goes wrong most often?
Most broken setups fail for one of five reasons, and each one is visible from the DNS record alone.
- SPF exceeds its ten-lookup limit. Every include and redirect mechanism SPF resolves counts against a hard limit of ten DNS lookups (RFC 7208). Past that limit, the whole SPF check returns a permanent error, which many receivers score as a fail.
- DKIM keys are never rotated. A signing key set up once and left for years is a key that, if it ever leaks, authenticates mail indefinitely. A 1024-bit key is also now considered too weak to trust.
- DMARC never leaves p=none. A domain can run DMARC in report-only mode for years, collecting aggregate reports that nobody reads, while every spoofed message in them is still delivered to the inbox.
- SPF and DMARC disagree on which domain sent the mail. DMARC checks alignment between the From address and the domain SPF or DKIM actually authorized. A marketing platform sending as the brand's domain without signing with its own DKIM key fails alignment even though SPF passes for the platform's own servers.
- BIMI is added before DMARC is enforced. Most mailbox providers only display a BIMI logo once DMARC is at quarantine or reject with a high enough percentage, so a BIMI record added on top of p=none shows no logo at all.
How do you check your own domain in two minutes?
- Query the domain's TXT records directly: the SPF record at the domain itself, the DMARC record at `_dmarc.yourdomain.com`, and, for each DKIM selector in use, the record at `selector._domainkey.yourdomain.com`.
- Count the DNS lookups the SPF record resolves. Each `include:` and `redirect=` mechanism costs a lookup, and a chain of forwarded includes from several vendors is the most common way a domain quietly crosses ten.
- Read the DMARC record's `p=` tag. `none` means the domain is only watching; `quarantine` or `reject` means it is actually enforcing.
- Send a message through the setup and read the Authentication-Results header the receiving server attaches, to confirm SPF, DKIM and DMARC all pass and align, not just that each record exists.
- Run a free Snapshot of the domain. Auditaar reads SPF with its real lookup cost, DKIM across 40 probed selectors, DMARC, BIMI and MTA-STS straight from public DNS.
Email authentication FAQ
Does SPF alone stop email spoofing?
No single record does. SPF confirms a message came from a server the domain authorized, but it says nothing about whether the message was altered in transit or what a receiving server should do if a check fails. DKIM and DMARC close those two gaps, and all three together are what a receiving server actually relies on.
Does fixing this improve search rankings?
Email authentication is not a search ranking signal. It sits in the Trust pillar of a website audit alongside security headers and Safe Browsing status, because a domain that cannot prove its own mail is genuine is a weaker brand to trust, not a weaker page to rank.
Is it safe to turn on DMARC if I've never checked it before?
Starting at p=none is safe, since it only collects aggregate reports without affecting delivery. Moving straight to reject without reading those reports first can block legitimate mail from a forwarder or a tool nobody remembered was sending as the domain. Read a few weeks of reports before enforcing.
Why would BIMI show no logo even though DMARC passes?
Most mailbox providers require DMARC enforcement at a high percentage, not just a passing policy, and major providers including Gmail also require a Verified Mark Certificate tied to a registered trademark. A BIMI record alone satisfies neither requirement.
Auditaar reads SPF with its real lookup cost, DKIM across 40 probed selectors, DMARC, BIMI and MTA-STS straight from public DNS on every audit, and scores each into the Trust pillar alongside security headers and Safe Browsing status. Run a free Snapshot, or read what security headers does a website need.