SPF, DKIM and DMARC: A Complete Guide to Email Authentication

Email was designed in an era when nobody expected the sender address to be a lie. Nothing in the original protocol stops a machine on the internet from connecting to a mail server and claiming to be you. That gap is why phishing works, and it is why three DNS-based standards, SPF, DKIM and DMARC, now decide whether your mail lands in the inbox or the spam folder.

All three live in your domain's DNS records, which means you can inspect any domain's email authentication setup, including your own, with nothing more than a DNS lookup. This guide explains what each record does, how to read one, and how to roll out a strict DMARC policy without accidentally blocking your own invoices.

To check all three records at once, including the SPF lookup count and your DKIM key size, use our SPF, DKIM and DMARC checker.

Why Email Authentication Matters

Two things changed in the last few years. Attackers got better at impersonating trusted brands, and the major mailbox providers responded by making authentication effectively mandatory. Gmail and Yahoo now require bulk senders to publish SPF, DKIM and DMARC records, and Microsoft has followed. If your records are missing or broken, the consequences are immediate and practical:

• Your mail gets filtered. Unauthenticated messages are far more likely to be quarantined, and sometimes rejected outright before they ever reach a mailbox.
• Anyone can spoof your domain. Without a DMARC policy, a receiving server has no instruction to reject forged mail that uses your name.
• You are blind to abuse. DMARC reporting is the only way to find out that someone is sending phishing mail in your name.
• Deals stall. Security questionnaires and vendor reviews routinely ask for a DMARC policy, and "none" is increasingly treated as a finding.

The Three Records at a Glance

They are layers, not alternatives. SPF checks the sending server, DKIM checks the message, and DMARC ties both back to the domain a human actually sees in the From header and says what to do on failure. You need all three.

SPF: Who May Send for Your Domain

Sender Policy Framework is a published list of the servers permitted to send mail for your domain. A receiving server takes the IP address that connected to it, looks up your SPF record, and checks whether that address is on the list.

Reading an SPF Record

A typical record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

Read it left to right. v=spf1 is the version and must come first. Each include: pulls in another domain's SPF record, which is how you authorise a provider such as Google Workspace or a transactional mail service. ip4: and ip6: authorise specific addresses or ranges, typically your own mail server. The final mechanism is the catch-all, and it is the one people get wrong:

• -all is a hard fail. Anything not listed is unauthorised, and receivers are expected to reject it.
• ~all is a soft fail. Unlisted senders are suspicious but still accepted, usually with a spam penalty.
• ?all is neutral and tells the receiver nothing, which defeats the point of publishing a record at all.

Start with ~all while you are confirming that every legitimate sender is listed, then tighten to -all once your DMARC reports are clean.

The Ten Lookup Limit

SPF allows a maximum of ten DNS lookups while evaluating a record. Every include:, a, mx and redirect counts, and nested includes count too. Exceed the limit and the result is a permanent error, which most receivers treat as no SPF at all. Three or four mail providers is usually enough to breach it, so audit the record whenever you add a new sending service, and remove providers you have stopped using.

One more rule that surprises people: a domain may publish only one SPF record. Two v=spf1 TXT records on the same name is a permanent error, not a merge.

DKIM: Signing Your Mail

DomainKeys Identified Mail adds a cryptographic signature to every outgoing message. Your mail server holds a private key and signs selected headers plus the body; the matching public key is published in DNS. A receiver fetches the public key, verifies the signature, and learns two things: the message really was signed by your domain, and nothing it covered has been modified in transit.

The public key lives at a name built from a selector, for example google._domainkey.example.com or s1._domainkey.example.com. Selectors exist so you can run several keys at once, which is what makes key rotation painless: publish a new selector, switch your signing to it, and retire the old one later.

Because the signature travels with the message, DKIM survives forwarding in cases where SPF does not. If a mailing list relays your mail, the connecting IP changes and SPF fails, but the DKIM signature still verifies as long as the list did not rewrite the signed headers or body. That resilience is the main reason DKIM matters even when SPF is already in place.

DMARC: Telling Receivers What to Do

SPF and DKIM each produce a pass or a fail, but neither says what the receiver should do about it, and neither looks at the From address your recipient actually reads. DMARC fills both gaps. A record looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=r

p= is the policy: none (monitor only), quarantine (treat failures as spam), or reject (refuse them at the gate). rua= is the address that receives daily aggregate reports, and it is the single most valuable part of the record. pct= lets you apply the policy to a percentage of mail during a rollout.

Alignment, the Part Everyone Misses

DMARC does not just require that SPF or DKIM passes. It requires that the passing domain aligns with the domain in the visible From header. A message can pass SPF for mailer.vendor.com and still fail DMARC for example.com, because the two do not match. This is the single most common reason a correct-looking setup still fails.

adkim and aspf control how strict the match must be. Relaxed (r, the default) accepts a subdomain such as mail.example.com; strict (s) demands an exact match. Start relaxed. DMARC passes if either SPF or DKIM passes and aligns, so a single aligned DKIM signature is enough.

Rolling Out a Policy Safely

1. Publish p=none with a reporting address. Nothing changes for your mail flow, but reports start arriving.
2. Read the reports for two to four weeks. They will reveal sending services you had forgotten: the CRM, the helpdesk, the invoicing tool, the old marketing platform.
3. Fix the gaps. Add each legitimate sender to SPF, enable DKIM signing with an aligned domain, and confirm the change in the next report.
4. Move to p=quarantine. Use pct= to ramp gradually if you send at volume.
5. Finish at p=reject. Only once reports show no legitimate mail failing. This is the policy that actually stops spoofing.

How to Check Your Own Records

All three records are public TXT records, so checking them takes seconds:

1. SPF. Run a TXT lookup on your bare domain with the DNS Lookup tool and find the string starting v=spf1. Confirm there is exactly one, and count the lookups.
2. DMARC. Run a TXT lookup on _dmarc. plus your domain. If nothing comes back, you have no policy and no reporting.
3. DKIM. Run a TXT lookup on selector._domainkey. plus your domain. Your mail provider's documentation names the selector it uses.
4. Verify end to end. Send a message to an account at a major provider and inspect the received headers. Gmail's "Show original" view reports SPF, DKIM and DMARC results for the message you just sent, which is the only test that covers the whole chain.

While you are in DNS, it is worth confirming the rest of your mail setup: check that your MX records point where you expect, and that the hostname in your server's certificate matches, which you can verify with the SSL Certificate Checker.

Common Mistakes to Avoid

• Two SPF records. Merge them into one. Two is a permanent error.
• Leaving DMARC at p=none forever. Monitoring is a starting point, not a destination. Only quarantine or reject prevents spoofing.
• No reporting address. A DMARC record without rua= throws away the information you need to tighten the policy safely.
• Forgetting parked domains. Domains that send no mail should publish v=spf1 -all and p=reject, precisely because attackers prefer unused domains.
• Jumping straight to strict alignment. adkim=s and aspf=s before your reports are clean will break legitimate mail from subdomains.
• Ignoring TTL. A long TTL on a TXT record means a fix takes hours to spread. Lower it before a migration and raise it afterwards.

Get Your Email Authenticated

Email authentication is one of the few security tasks with an unambiguous payoff: better deliverability, visibility into abuse, and a domain that cannot be casually spoofed. It is also entirely readable from the outside, so there is no reason to guess at your own configuration. Start with a TXT lookup on your domain using the free DNS Lookup tool, read what is actually published, and work through the rollout above one step at a time.

Related tools and guides:

• DNS Lookup - query TXT, MX, SPF and every other record for any domain.
• DNS Lookup: A Complete Guide - every record type explained.
• SSL Certificate Checker - inspect the certificate on your mail or web server.
• HTTP Status Codes - a quick reference for every response code.
• Why Your SPF Record Keeps Failing (and How to Fix It) - the ten-lookup limit, broken includes and other reasons SPF fails.

Frequently Asked Questions