Email deliverability: SPF, DKIM, and DMARC, actually explained
Networking Fundamentals' own DNS lesson mentioned TXT records being used for "SPF/DKIM email authentication," as an aside, without ever opening up what either actually does. This lesson is that aside, finally unpacked — three real, separate mechanisms that, together, are the actual reason a domain's emails land in an inbox instead of a spam folder, or get rejected outright.
Advanced
3 min read
The underlying problem: email's sending address is trivially fakeable
Nothing in the base email protocol (SMTP) verifies that a message claiming to be From: billing@example.com actually came from anyone authorized to send as example.com — this is exactly why email spoofing and phishing have historically been so easy, and exactly the gap all three mechanisms below exist to close, each addressing a different, specific part of the problem.
SPF: "which servers are allowed to send email claiming to be from this domain"
SPF (Sender Policy Framework) is a TXT record listing every mail server/service authorized to send email on a domain's behalf — a receiving mail server checks the sending server's IP against this list; if it's not on it, the message fails SPF. ~all (soft fail) flags unlisted senders as suspicious without outright rejecting; -all (hard fail) tells receivers to reject unlisted senders outright — a real, deliberate policy choice with real consequences if a legitimate sending service gets added to your stack later and is forgotten in this record.
DKIM: "this specific message's content hasn't been tampered with, and really came from an authorized sender"
DKIM (DomainKeys Identified Mail) uses real cryptographic signing (Cryptography Fundamentals' own domain covers the underlying digital-signature mechanism directly) — the sending server signs each outgoing message with a private key, and publishes the corresponding public key in a TXT record; a receiving server verifies the signature against that public key, confirming both that the message genuinely came from a server holding the matching private key, and that the message's actual content wasn't altered in transit. Unlike SPF (which checks the sending server, independent of message content), DKIM verifies the specific message itself.
DMARC: "what should receivers actually DO when SPF or DKIM fails, and tell me about it"
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer sitting on top of both SPF and DKIM — it tells receiving mail servers what to actually do when a message fails either check (p=none just monitors, p=quarantine sends it to spam, p=reject refuses it outright), and separately, where to send aggregate reports (rua=) showing who's actually sending email claiming to be from your domain, pass or fail — genuinely useful for discovering unauthorized or forgotten senders you'd otherwise have no visibility into at all.
Why getting all three right matters even if you never send email manually
A transactional-email service (SendGrid, Postmark, Resend — services every real product eventually uses for password resets, receipts, notifications) sends on your domain's behalf, meaning your domain's own SPF/DKIM/DMARC records have to correctly authorize that specific service — misconfiguring this is a real, common reason legitimate transactional email silently lands in spam, with nothing about the application code itself being wrong at all. Setting this up correctly once, when first adding a transactional-email provider, avoids a category of "why isn't this email arriving" debugging that has nothing to do with the application and everything to do with these three TXT records.