DMARC in Plain English: SPF, DKIM and DMARC Explained
SPF, DKIM, DMARC. Three DNS records, one goal: stop other people from sending email as you. Here is what each one actually does — and how to turn them on without losing legitimate mail.
The problem: anyone can forge From:
Email was designed in a more trusting era. By default, nothing stops a stranger from putting your domain in the From: address of a message. That is why phishing works: a scammer sends invoices, password resets or CEO-fraud requests that appear to come from your company, and the recipient's mail server has no built-in way to know they didn't. Beyond the direct fraud, spoofing damages your domain's reputation. When spammers blast messages as you, mailbox providers start distrusting your domain, and your genuine mail lands in spam folders. Three DNS records fix this by letting you publish, in public, exactly who is allowed to send mail for your domain and what should happen to anything that fails the check. They are SPF, DKIM and DMARC. None of them is complicated on its own; the confusion comes from the acronyms and from turning them on in the wrong order. Handled carefully, they stop spoofing without disrupting a single legitimate message.
SPF: who may send
Sender Policy Framework (SPF) is a single TXT record that lists the servers allowed to send email for your domain. A simple one looks like v=spf1 include:_spf.google.com include:servers.mcsv.net -all. Each include: pulls in the sending infrastructure of a provider — your email host, your marketing platform, your ticketing system — and the -all at the end means anything not listed should be rejected. When a receiving server gets a message claiming to be from you, it looks up this record and checks whether the connecting server's IP is authorized. If not, SPF fails. SPF has two well-known limitations. First, it authenticates the hidden envelope sender, not the visible From: address a human reads — which is why it needs DMARC to be meaningful. Second, the standard caps the record at ten DNS lookups; chain too many include: entries and receivers return a permanent error that can hurt delivery. Keep the record lean and remove providers you no longer use.
DKIM: a tamper-proof signature
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every message you send. Your mail server signs each outgoing message with a private key; you publish the matching public key as a DNS record at a named selector, like selector1._domainkey.example.com. The receiver fetches that public key and verifies the signature. Two things follow. First, the message provably came from a system that holds your private key — a spoofer without that key cannot produce a valid signature. Second, the signed parts of the message were not altered in transit; if a header or the body is tampered with, the signature breaks. Unlike SPF, DKIM survives forwarding, because the signature travels with the message rather than depending on the connecting IP. Most email providers set DKIM up for you — you enable it in their console and paste the DNS records they give you. Increasingly it is mandatory: major mailbox providers now require DKIM for bulk senders, so treat it as table stakes, not optional.
DMARC: tie it together
SPF and DKIM each answer a narrow technical question. DMARC (Domain-based Message Authentication, Reporting and Conformance) is what makes them useful to a human. It does three things. First, it requires alignment: the domain that passes SPF or DKIM must match the visible From: domain the recipient actually sees. This closes the gap that lets an attacker pass SPF for their own domain while displaying yours. Second, it tells receivers what to do when a message fails — p=none (just monitor), p=quarantine (send to spam), or p=reject (refuse outright). Third, it asks receivers to send you aggregate reports about who is sending mail as your domain. A record looks like v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100, published at _dmarc.example.com. The goal is p=reject, which means forged mail is refused before it reaches an inbox — but you arrive there gradually, using the reports to make sure no legitimate stream is caught first.
A safe rollout plan
The danger with DMARC is moving to enforcement before all your legitimate senders are aligned — that quarantines or rejects your own newsletters, invoices and transactional mail. So roll out in stages and let the data lead. Step one: publish SPF and DKIM for every service that sends as your domain — your mail host, marketing platform, CRM, help desk, billing system. Step two: publish DMARC at p=none. This enforces nothing but turns on reporting, so you see every source of mail claiming to be you without any risk to delivery. Step three: read the reports until you can account for every legitimate sender and confirm each one passes SPF or DKIM with alignment. Fix the stragglers. Step four: move to p=quarantine, optionally with pct=25 and up so only a fraction is affected at first, and watch for fallout. Step five: once quarantine is clean, move to p=reject. Rushing straight to reject is the single most common way teams break their own email.
Reading DMARC reports
DMARC aggregate reports arrive as XML from each mailbox provider, summarizing how much mail passed and failed authentication, grouped by sending IP. Raw XML is hard to read, so most teams pipe it into a DMARC reporting dashboard that turns it into a readable table of senders. What you are looking for is simple: is every source a system you recognize and authorized? A legitimate sender that fails alignment needs its SPF or DKIM fixed. A source you don't recognize sending large volumes that fail is exactly the spoofing DMARC is meant to stop — and at p=reject, it will be. DMARC is not set-and-forget. Every time you add a new tool that sends email — a new CRM, a survey tool, a payment processor — you must authorize it in SPF and DKIM, or its mail will start failing once you are at enforcement. Re-check your records whenever your stack changes, and run your domain through Website Auditor to confirm SPF, DKIM hints and a DMARC policy are all present and healthy. Think of the three records as a sequence, not a pile: SPF and DKIM prove a message is authorized and untampered, and DMARC turns those proofs into an enforceable, reported policy tied to the address your recipients actually see. Publish all three, start DMARC in monitoring, let the reports show you every real sender, and only then tighten to reject. Do it in that order and you stop spoofers cold without ever bouncing a legitimate invoice — which is exactly the outcome email authentication was designed to give you.
Frequently asked questions
- SPF and DMARC are the minimum, and DKIM is now effectively required — major mailbox providers demand it for bulk senders. In practice, publish all three: SPF and DKIM do the authentication, and DMARC makes them meaningful by requiring alignment and telling receivers what to do on failure.
- Only if you move to p=quarantine or p=reject before all your legitimate senders are authorized and aligned. Start at p=none to monitor with zero delivery impact, fix every real sender using the reports, then tighten gradually.
- They are the DMARC policy levels. p=none only monitors and reports; p=quarantine sends failing mail to spam; p=reject refuses failing mail outright. The end goal is p=reject, reached gradually once reports confirm no legitimate mail is affected.
- The SPF standard caps evaluation at ten DNS lookups to prevent abuse. Chaining too many include: entries exceeds it and returns a permanent error that can hurt delivery. Keep the record lean and remove senders you no longer use.