SPF, DKIM and DMARC: what's the difference?

When you send email from your own domain, the recipient's server does not look only at the visible From address. It also checks whether the sending server is allowed, whether the message was signed and whether the domains used align with the sender domain's policy. This is where SPF, DKIM and DMARC come in.

To check your domain's current configuration first, use the SPF, DMARC and DKIM checker. It reads and explains public DNS records without changing your settings.

SPF: which servers may send for a domain?

SPF is a TXT record published at a domain. It lists servers or providers allowed to send email using the domain's SMTP envelope identity. A typical record begins with v=spf1, followed by IP addresses, include mechanisms for external providers and an ending such as ~all or -all.

SPF permits no more than 10 terms that cause DNS lookups during evaluation. These include include, a, mx, ptr, exists and redirect. Because an include can refer to further SPF records, counting only terms in the main record is not a complete evaluation.

DKIM: is the message signed with a valid key?

DKIM attaches a cryptographic signature to email. The recipient reads the domain and selector from the header and looks up the public key at a DNS name such as selector._domainkey.example.com. When the signature matches the key, the recipient can verify that the signed parts of the message were not altered after signing.

Selectors are not universal names. Google Workspace, Microsoft 365, newsletters and self-hosted mail servers can all use different selectors. A DKIM record cannot reliably be found from the domain name alone, so the selector is optional input in our checker.

DMARC: what should recipients do and do domains align?

DMARC is a TXT record at _dmarc.example.com. It publishes a policy for messages failing DMARC and enables reporting. The main policies are p=none, p=quarantine and p=reject.

• p=none is mainly monitoring mode: the policy itself does not request quarantine or rejection solely due to DMARC.
• p=quarantine requests suspicious treatment for messages that fail.
• p=reject requests rejection of messages that fail DMARC checks and alignment.

DMARC is not just “SPF or DKIM exists”. At least one successful authentication mechanism must also align with the domain visible to the recipient in From.

What should you configure first?

1. List every legitimate service sending mail for your domain: business inboxes, websites, CRMs, newsletters, invoices and more.
2. Set SPF to cover legitimate senders without creating multiple independent SPF policy records.
3. Enable DKIM with each supporting provider and publish its public key under the correct selector.
4. Add DMARC. For an established domain, monitoring reports and confirming legitimate senders before enforcing a stricter policy often makes sense.
5. After DNS changes, examine both the public records and actual headers from a sent message. Public records alone do not prove that an email used the correct identity and signature.

Common mistakes

• Two or more v=spf1 policy records at the same DNS name.
• Too many SPF DNS lookups through a long chain of include directives.
• Using SPF +all, which effectively authorizes any IP.
• Publishing a DKIM selector that differs from the selector used by the sender.
• Publishing malformed DMARC or placing it somewhere other than _dmarc.
• SPF and DKIM succeed technically but do not align with the visible From domain, so DMARC fails.

What does Gmail require today?

Google requires authentication for sending to personal Gmail accounts: SPF or DKIM for all senders, and SPF, DKIM and DMARC for bulk senders. Google defines a bulk sender as roughly 5,000 or more messages within 24 hours to personal Gmail accounts. Additional rules include aligning the From domain with SPF or DKIM, maintaining spam rates below 0.3%, and one-click unsubscribe for marketing/subscription messages. Google's FAQ notes stronger enforcement of non-compliant traffic since November 2025. As these requirements can change, check the current Email sender guidelines before a large campaign.

What can our checker verify?

It checks the public SPF record, DMARC record and optionally the DKIM record for a selector you supply. It also highlights some common warnings. It does not send test email, read a provider's private configuration, or guarantee that every sent message will pass SPF, DKIM or DMARC just because its public records exist.

Back to top ↑