SPF, DKIM and DMARC in plain English

SPF, DKIM and DMARC are three DNS records that together tell the world's mail servers, "this message really came from my domain, and here is what to do if it did not." They are not spam filters and they are not encryption. They are authentication and reputation records. If you run one website with one mailbox, they matter. If you run twenty, fifty or a hundred sites across a range of IPs, as most SEO hosting and agency operators do, they matter a great deal more, because every unauthenticated domain is a small hole in your sending reputation and a footprint someone else can abuse.

This guide explains what each record does in plain English, how they fit together, and the specific gotchas that hit multi-site and multi-IP operators. It sits inside our wider Email and Deliverability knowledge base if you want the surrounding context.

The one-line version of each

• SPF (Sender Policy Framework) is a public list of which mail servers are allowed to send mail using your domain in the envelope. A receiving server checks the sending IP against that list.
• DKIM (DomainKeys Identified Mail) is a cryptographic signature added to each message. It proves the message was authorised by the domain owner and was not tampered with in transit.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the first two together. It tells receivers what to do when a message fails, and it asks them to send you reports so you can see who is sending as you.

How they work together

The three records are layered, not interchangeable. SPF checks the connection. DKIM checks the content. DMARC checks that at least one of them passed and that the passing domain lines up with the visible From address. That last part, called alignment, is the piece people miss. A message can pass raw SPF or DKIM and still fail DMARC if the authenticated domain does not match the From domain your recipient actually sees.

SPF in a bit more detail

SPF is a single TXT record on your domain. A basic one looks like this:

v=spf1 include:_spf.yourprovider.com ip4:203.0.113.10 -all

It says: mail is allowed from the servers listed by your provider and from that one IP address, and anything else should be treated as a hard fail. Two rules trip people up constantly:

• You may only have one SPF record per domain. If you add a second TXT starting with v=spf1, some receivers treat the whole thing as invalid. Merge everything into one record instead.
• SPF has a hard limit of ten DNS lookups. Every include: counts. Stack a mail host, a newsletter tool, a ticketing system and a CRM and you can silently blow past ten, at which point SPF fails for everyone. Flatten unused includes and drop services you no longer send from.

DKIM in a bit more detail

DKIM adds a private-key signature to your outgoing headers and body. You publish the matching public key as a TXT record at a selector, for example selector1._domainkey.yourdomain.com. The receiver fetches that key, verifies the signature, and knows the message was not altered and was authorised by whoever holds the private key. Because it survives forwarding better than SPF, DKIM is usually the stronger of the two signals. Rotate keys periodically and use a selector name that lets you roll to a new key without downtime.

DMARC in a bit more detail

DMARC is where you set policy and finally get visibility. A sensible starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

Start at p=none. This changes nothing about delivery but turns on the aggregate reports (the rua address), which show you every source sending as your domain and whether each passes. Read those reports for a couple of weeks, fix the legitimate senders that are failing, then tighten the policy in stages: p=none, then p=quarantine, then p=reject. Jumping straight to reject before you have read the reports is the fastest way to send your own invoices to spam.

Why this matters more for SEO hosting and multi-site operators

If you run a single site, misconfigured email authentication mostly hurts you. If you run a network, it works differently, and in three specific ways:

• Reputation is per-domain and per-IP. An unauthenticated domain that gets spoofed, or that sends through a shared pool, can pick up a poor sending reputation. On genuinely separated infrastructure, one domain's trouble does not automatically taint the others. This is the same defensive logic behind giving each site its own Class C IP: you are not buying a ranking boost, you are containing blast radius so a problem on one property stays on one property.
• Spoofing is a footprint and a security risk. A domain with no DMARC policy is trivial to send mail as. For a network of sites, that is both a phishing exposure and an unnecessary signal that the properties are neglected or loosely managed. Publishing SPF, DKIM and DMARC on every domain, even the ones that "do not send email", is basic hygiene. A parked or non-sending domain should carry an SPF of v=spf1 -all and a DMARC of p=reject so nobody can send as it at all.
• Consistency is a management problem at scale. Hand-editing DNS on a hundred domains guarantees drift. Standardise the records, template them, and audit them on a schedule. Our notes on DNS and IP management cover how to keep records consistent across a large estate.

To be clear and honest about it: none of these records are a ranking signal. Search engines do not reward you for having DMARC. The value is entirely defensive. You are protecting deliverability, protecting your domains from being impersonated, and removing an avoidable footprint across a network. That is worth doing precisely because it is invisible when it works and expensive when it fails.

A practical order of operations

1. Publish one clean SPF record per domain, staying under the ten-lookup limit.
2. Enable DKIM signing on every sending service and publish the public keys.
3. Add DMARC at p=none with an rua reporting address.
4. Read the aggregate reports, fix legitimate senders that fail, then move to quarantine and finally reject.
5. Lock down non-sending and parked domains with -all SPF and p=reject DMARC.
6. Re-audit the whole estate on a recurring schedule so records do not drift.

If you want the exact wording and edge cases behind these records, the DMARC specification is worth a read: RFC 7489. And if you are setting up authentication across a fresh network of sites, template it correctly from day one so you never have to unpick drift later.