Email was designed in an era when nobody imagined a stranger would pretend to be your bank. The “From” line on a message is just text, and for decades anyone could type any address into it. So how does your inbox decide that a note from a company is real? Three DNS-based checks do most of the work: SPF, DKIM, and DMARC. Together they help receiving mail servers spot messages that claim to come from a domain they did not.
This guide explains what each one does, how they fit together, and how you can see the results for yourself in any email you receive.
The Spoofing Problem in Plain Terms
Think of a postal letter. Anyone can write a return address on the envelope, and the post office will still deliver it. Email works the same way by default. Without extra checks, a scammer can send a message that appears to come from your own domain or a well-known brand. That is the basis of many phishing attempts, which our guide on spotting phishing scams covers from the reader’s side.
SPF, DKIM, and DMARC are the sender’s side of the defense. As Cloudflare’s overview of SPF, DKIM, and DMARC puts it, they are authentication methods that help stop spammers and phishers from sending email as a domain they do not own.
SPF: The Approved Sender List
Sender Policy Framework works like a guest list. A domain owner publishes a record in DNS naming the servers allowed to send mail for that domain. When a message arrives, the receiving server checks the sending server against that list. If the server is not on it, the check fails.
SPF is simple and useful, but it has a limit: it checks the server that delivered the message, not the content of the message itself. If you want a refresher on how those DNS records are looked up, our explainer on how DNS works covers the basics.
DKIM: The Tamper-Evident Seal
DomainKeys Identified Mail adds a digital signature. The sending server signs each message using a private key. The matching public key sits in a DNS record, so any receiving server can fetch it and verify the signature. If the signature checks out, the message is confirmed to have come from that domain and to have arrived without being altered in transit.
Think of it as a wax seal on a letter. Anyone can see the seal, but only the sender holds the stamp that makes it.
DMARC: The Policy and the Reports
Domain-based Message Authentication, Reporting, and Conformance builds on the first two. SPF and DKIM verify the sender, and DMARC tells receiving servers what to do when those checks fail. According to Cloudflare, the choices are to quarantine the message, reject it, or deliver it anyway. The lenient “deliver anyway” setting is useful when a domain owner is still learning how their mail flows.
DMARC also adds reporting. A domain can ask receiving servers to send back summaries of which messages passed or failed. Administrators use these reports to find legitimate services that were left off their SPF list or are missing a signature, then fix them before tightening the policy. Rushing straight to a strict policy is a common mistake, because it can send real mail to spam folders.
How to See the Results in Your Own Inbox
You do not need to be an administrator to look at these checks. In most email apps you can open the full message header, often under an option such as “Show original.” Look for lines reading spf=pass, dkim=pass, and dmarc=pass. A pass on all three is a good sign, though not proof that a message is safe: criminals can register lookalike domains and set up authentication for those too.
Failures do not always mean fraud, either. Forwarded mail and misconfigured services can fail legitimate checks. Treat the results as one signal among several, along with the sender address, the link destinations, and whether the request makes sense.
What Domain Owners Should Do
- Publish all three records. These records live in DNS as TXT entries, and a web host does not always create them for you.
- Start DMARC in monitoring mode. Read the reports, fix gaps, then move toward quarantine or reject.
- Protect domains that never send mail. Cloudflare notes that even a domain that does not send email should publish a DMARC record to prevent spoofing.
- Remember the limits. The records do not enforce anything by themselves. Receiving mail servers have to check and apply them.
Authentication is one layer of account safety, not the whole of it. Strong sign-in protection, such as two-factor authentication, covers the part that email checks cannot.
FAQs
Do I need all three of SPF, DKIM, and DMARC?
Ideally yes. SPF and DKIM verify the sender in different ways, and DMARC ties them together with a policy and reporting. Using only one leaves gaps.
Where are these records stored?
All three are stored as TXT records in the domain’s DNS settings, so you manage them wherever you manage the domain’s DNS.
If an email passes all three checks, is it safe?
Not necessarily. Passing means the message really came from the domain it claims, but that domain could still belong to a scammer. Always judge the sender and the request too.
Why would a real email fail authentication?
Common reasons include forwarding, a third-party service sending on a company’s behalf without being listed in SPF, or a missing DKIM signature. DMARC reports help domain owners find and fix these cases.
Discussion about this post