SPF, DKIM and DMARC: Email Authentication Explained
Anyone can put your domain in the From line of an email. SMTP, the protocol that carries mail, was designed in an era of trust and never checks it. Email authentication is the set of DNS records that lets receiving servers check it for you: SPF says which servers may send for your domain, DKIM adds a cryptographic signature to every message, and DMARC ties both to the address the recipient actually sees and tells receivers what to do when the check fails.
Without these records your legitimate mail is more likely to land in spam, and scammers can impersonate your domain with little effort. This guide explains what each record does, how they work together and what to check first.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a single TXT record on your domain that lists the servers allowed to send mail on its behalf. A typical record looks like this:
example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"v=spf1— marks the record as SPF. It must come first.ip4:/ip6:— individual addresses or ranges.include:— "also trust whoever this other domain lists". This is how you authorize Google Workspace, Microsoft 365 or a newsletter service.aandmx— the servers your A or MX records point to.~allor-all— what to do with everyone else: soft fail (accept but treat as suspicious) or fail.
One detail is easy to miss: SPF checks the envelope sender (the Return-Path address used during delivery), not the From address shown in the mail client. Newsletter platforms often use their own Return-Path domain, so SPF can pass while proving nothing about your From domain. That gap is exactly what DMARC closes.
Check what your domain publishes with the SPF checker: it shows the parsed mechanisms, the final qualifier and how many DNS lookups the record needs.
DKIM: a signature on every message
DKIM (DomainKeys Identified Mail) works like a seal. The sending server signs selected headers and the body with a private key and adds a DKIM-Signature header. The receiver fetches the matching public key from DNS and verifies that nothing was changed in transit. Two tags in the signature matter most:
d=— the signing domain;s=— the selector, the name under which the public key is published:selector._domainkey.example.com.
Because the key is found by selector, a domain can have several DKIM keys at once — one for your mailbox provider, one for your newsletter tool, one for your CRM. Selectors, key length and rotation are covered in detail in What is DKIM. To see whether a key exists and how long it is, use the DKIM checker.
DMARC: alignment and policy
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.example.com:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"It does three things:
- Requires alignment. A message passes DMARC only if SPF or DKIM passes and the domain it passed for matches the domain in the visible From address. For SPF that is the Return-Path domain, for DKIM the
d=domain. By default the match is "relaxed":mail.example.comaligns withexample.combecause they share the organizational domain. - Sets a policy for messages that fail:
none(only report),quarantine(spam folder) orreject(refuse delivery). - Turns on reports. Receivers send daily aggregate reports to the
ruaaddress, so you can see every server that sends mail as your domain — including ones you forgot about.
Every tag, the rollout from p=none to p=reject and how to read the reports are explained in DMARC record: how to set up DMARC step by step.
How the three work together
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Where it lives | TXT on the domain | TXT (or CNAME) at selector._domainkey | TXT at _dmarc |
| What it checks | The sending IP against the list | The signature against the public key | That SPF or DKIM passed for the From domain |
| Survives forwarding | Usually not | Usually yes, if the message is not modified | Passes if at least one aligned check survives |
| Can block spoofing alone | No | No | Yes, with quarantine or reject |
The practical takeaway: DKIM is the more robust half because it survives forwarding. Aim for every legitimate stream of mail to pass aligned DKIM, and treat SPF as a second line.
What Gmail and Yahoo require from senders
Since February 2024 Google and Yahoo have enforced published sender requirements, and other large mailbox providers have moved in the same direction. In short:
- Everyone sending to personal Gmail or Yahoo addresses needs SPF or DKIM, valid forward and reverse DNS for sending IPs, TLS, and a low spam complaint rate.
- Bulk senders (Google names a threshold of around 5,000 messages a day to its users) need SPF and DKIM, a DMARC record with at least
p=none, a From domain aligned with SPF or DKIM, and one-click unsubscribe for marketing mail.
Setup checklist
- List every service that sends as your domain: mailbox provider, website contact form, newsletter tool, CRM, helpdesk, billing system. Forgotten senders are the main reason DMARC rollouts break mail.
- Publish one SPF record that covers the services which use your domain in the Return-Path. Keep it under 10 DNS lookups.
- Turn on DKIM in each service with your own domain, not the provider's default. Each service gives you a TXT or CNAME record to publish.
- Publish DMARC with
p=noneand aruaaddress you actually read or a report-processing service. - Read the reports for 2–4 weeks and fix every legitimate source that fails alignment.
- Tighten the policy step by step: quarantine, then reject.
- Check the basics around it: the MX lookup confirms where your mail is received, and the IP blacklist check shows whether your sending IP is listed. For the rest of the DNS picture see checking domain DNS records.
Common mistakes
Two SPF records
Adding a new service often ends with a second v=spf1 record next to the old one. The SPF standard treats this as a permanent error, and many receivers then ignore SPF entirely. There must be exactly one SPF record; merge the mechanisms into it.
More than 10 DNS lookups
Each include, a, mx, ptr, exists and redirect costs a lookup, and includes inside includes count too. Above 10 the result is a permanent error. Remove services you no longer use, replace a/mx with explicit IPs where they are stable, and avoid ptr.
Third-party senders without DKIM
Google Workspace, Microsoft 365, Mailchimp and similar services can all sign with your domain, but usually only after you publish their DKIM records and enable signing. Until then they sign with their own domain or not at all, and the mail fails DMARC alignment.
p=reject on day one
Jumping straight to reject without reading reports blocks every sender you forgot: the invoice system, the website form, a partner sending on your behalf. Start with p=none, collect data, then tighten.
Forgetting domains that never send mail
Parked and secondary domains are popular for spoofing exactly because nobody watches them. For a domain that sends nothing, publish v=spf1 -all and v=DMARC1; p=reject.
A real example
Our own domain publishes v=DMARC1; p=none; rua=mailto:[email protected] and signs mail with DKIM selector mail using a 2048-bit key (checked in October 2026). That is a normal monitoring stage: reports are collected, and the policy is tightened once every source is confirmed. Run the DMARC checker on your own domain to see where you stand.