# SPF, DKIM and DMARC: What They Are and Why They Matter for Email
Table of Contents
There’s a little-known detail about email: the sender of a message is remarkably easy to forge. The name and address you see in the “From” field are a bit like a return address scribbled on the back of an envelope: on their own, nothing guarantees they’re real. Much of the world’s spam, phishing, and spoofing (emails that impersonate someone else) rests on this weakness. SPF, DKIM, and DMARC are the three tools built to fix it. They all serve one purpose: proving that a message really comes from who it claims to come from.
The problem: email was born without checks
When email was designed, the network was small and made of machines that trusted each other. Writing your own name in the sender field was enough, because there was no reason to lie. That model never included any identity verification, and it stuck: still today, technically, anyone can send an email showing a “From” address that isn’t theirs.
The consequences are twofold, and it helps to keep them separate, because the three tools exist to address them. The first is security: a scammer can write “on behalf of” your bank or your company and fool whoever receives the message. The second is deliverability, the ability of a legitimate email to actually land in the right inbox instead of the spam folder. The large providers filter enormous volumes of mail, and a sender they can’t verify is, by definition, suspicious.
SPF, DKIM, and DMARC aren’t alternatives to one another: they work together, each on a piece of the problem. Let’s take them one at a time.
SPF: who is allowed to send for a domain
SPF stands for Sender Policy Framework and is defined in RFC 7208. It answers one precise question: which servers are authorized to send mail for a given domain?
The idea is simple. The owner of a domain publishes, among the domain’s public settings (the so-called DNS records, the “address book” that translates internet names), a list of the authorized sending servers. When a message arrives, the receiving server reads that list and checks whether the server delivering it is on it. If it is, the check passes; if it isn’t, something’s off.
The analogy is a list at the post office: “for this company, only these offices may send.” A letter posted from an unauthorized office is treated with suspicion.
In practice it’s a single line of text, and a domain must have only one. It looks like this:
example.com. IN TXT "v=spf1 include:_spf.provider.tld -all"The final part, -all, tells the receiver how to treat anyone not on the list: reject them. A softer alternative, ~all, means “treat it as suspicious but don’t reject it outright,” which is handy in the early stages, when you aren’t yet sure you’ve listed all of your senders.
SPF has an important limitation to keep in mind: it checks the message’s “path” (the server that sends it), not its content. That’s the reason it isn’t enough on its own.
DKIM: the signature that proves integrity
DKIM stands for DomainKeys Identified Mail and is defined in RFC 6376. Where SPF verifies where a message comes from, DKIM verifies the message itself.
It works with key-based cryptography, the same principle behind digital signatures. The sending server applies to the message a signature computed with a private key that it keeps secret. The receiver retrieves the matching public key (again from the domain’s DNS records) and uses it to verify the signature. If it checks out, two things are proven: the message really comes from that domain, and it wasn’t altered in transit. If even a comma had changed along the way, the signature would no longer match.
The analogy here is a wax seal on a letter. It doesn’t just tell you who sent it: if the seal is intact, it also guarantees that no one opened and changed the envelope on the way.
The signature travels inside a technical header of the message, invisible to the average user, called DKIM-Signature. Two of its fields matter more than the rest: the signing domain (the d= tag) and the selector (the s= tag), a label that lets a single domain keep several keys active and rotate them without interruption.
DMARC: the rule for what to do when checks fail
Two gaps remain. First: neither SPF nor DKIM tells the receiver what to do when a check fails. Second, and more subtle: both verify a “technical” domain that the user never sees, and neither guarantees it matches the address shown in the “From” field. A message could pass the checks on some arbitrary domain and display a completely different one to the user.
DMARC closes both gaps. It stands for Domain-based Message Authentication, Reporting, and Conformance; as of 2026 the current reference is RFC 9989, which replaced the long-standing RFC 7489 and made DMARC a full standard.
Its first job is called alignment. DMARC requires the domain verified by SPF or DKIM to match the one the user reads in the “From” field. If a message passes SPF or DKIM but on a different domain from the visible one, DMARC considers it not aligned. It’s enough for one of the two checks to pass and be aligned for DMARC to be satisfied.
Its second job is to give the instruction. The domain owner publishes a rule, again as a DNS record, stating what to do with messages that fail alignment. The three options are:
p=none: do nothing special, just observe. This is the monitoring phase.p=quarantine: treat the message as suspicious, usually delivering it to the spam folder.p=reject: refuse the message, which isn’t delivered at all.
The record lives at a dedicated address and looks like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:report@example.com"That rua part introduces the third function, often the most useful: reports. Receiving providers periodically send the domain owner summaries (documents in XML format) listing who has sent mail in its name and with what outcome. This is how you discover both who is abusing your domain and your own legitimate services you’d forgotten about, say a back-office app or a newsletter platform. Without these reports, you’re flying blind.
How the three fit together
Lined up, the three tools cover different, complementary aspects:
- SPF verifies the path: which server the message comes from.
- DKIM verifies integrity: the content is authentic and hasn’t been tampered with.
- DMARC ties the first two to the address the user actually sees, decides what to do when something’s off, and provides the reports.
None of the three is enough on its own. SPF without DMARC doesn’t protect the visible address; DKIM without DMARC doesn’t say what to do on failure; DMARC without SPF or DKIM has nothing to check. It’s the combination that works.
Why they matter today
Until a few years ago, setting these up was seen as an optional good practice. Not anymore. Since 2024, Google and Yahoo explicitly require them from anyone sending large volumes of mail: according to Google’s official guidelines, anyone sending more than 5,000 messages a day to Gmail accounts must have SPF and DKIM configured and an active DMARC rule, even just the minimal p=none, with the visible address aligned to the SPF or DKIM domain. In practice, without these checks the email simply risks not arriving.
It matters for low-volume senders too. A domain without authentication is a domain anyone can use for scams in the owner’s name, and it’s also a domain that spam filters treat with more suspicion.
How it’s set up, in broad strokes
All three are configured in the same place, the domain’s DNS records, and they don’t require touching mail servers if you rely on a provider that supports them. The general pattern is this: publish the SPF record with the list of authorized senders, enable DKIM signing and publish its public key, then publish the DMARC record.
The trickiest step is DMARC itself, and the recommended order is gradual: start at p=none, read the reports to learn who really sends in your name, fix any legitimate senders left out, and only then tighten the rule toward quarantine and eventually reject. Doing it all at once risks blocking legitimate email you didn’t know you had. The logic is simple: look first, decide later.
In short
SPF, DKIM, and DMARC are three answers to a birth defect of email: anyone can pretend to be someone else. SPF says who is authorized to send, DKIM signs the message to prove its integrity, and DMARC ties both checks to the visible address and decides what to do when they fail. Together they cut down on spoofing and phishing and help legitimate messages reach their destination. They’re no longer an extra: they’re the minimum for a domain’s mail to be taken seriously.
