Email authentication: SPF, DKIM and DMARC explained

SPF: who's allowed to send for your domain

SPF, Sender Policy Framework, is a TXT record published in your domain's DNS that lists which mail servers are authorised to send email on behalf of that domain. When a receiving mail server gets a message claiming to be from your domain, it can look up your SPF record and check whether the server that actually sent the message is on the list. If it isn't, that's a signal the message may not be legitimate, and the receiving server can act on that, typically rejecting or flagging it.

SPF only checks the sending server's identity against the list. It doesn't verify anything about the message content, and it doesn't survive certain kinds of forwarding well, which is one of the reasons it's meant to work alongside DKIM rather than alone.

DKIM: proving the message wasn't altered

DKIM, DomainKeys Identified Mail, works differently. Outgoing mail gets a cryptographic signature attached, generated using a private key the sending mail server holds. The corresponding public key is published as a TXT record in DNS. A receiving server can fetch that public key and use it to verify the signature, confirming two things at once: the message really was signed by something holding your domain's private key, and the signed parts of the message weren't altered in transit.

Where SPF checks the sending server, DKIM checks the message itself, and it survives most forwarding scenarios that break SPF, since the signature travels with the message rather than depending on which server relayed it.

DMARC: the policy that ties them together

SPF and DKIM each answer a narrow question, but neither tells a receiving server what to actually do when a check fails, or confirms the domain in the visible "From" address matches what was checked. DMARC is a DNS TXT record that adds that policy layer: it states what a receiving server should do when a message fails SPF, fails DKIM, or fails the alignment check between them, options are typically to do nothing but monitor, quarantine the message (usually meaning spam), or reject it outright. DMARC also specifies where receiving servers should send aggregate reports, which gives the domain owner visibility into who's sending mail using their domain, including any spoofing attempts.

Why all three matter together

These three mechanisms are complementary rather than redundant. SPF alone is easy for an attacker to work around by sending through a completely different mechanism DKIM would catch. DKIM alone doesn't tell a receiver what to do about a failure. DMARC without SPF or DKIM configured underneath it has nothing to actually enforce. Configured together, they give receiving mail servers a reliable way to distinguish genuine mail from your domain from mail that's merely claiming to be.

The practical payoff shows up in two places. First, deliverability: mail providers increasingly weigh SPF, DKIM and DMARC status when deciding whether a message is legitimate, and missing or misconfigured records are a common, avoidable reason legitimate mail ends up in spam. Second, anti-spoofing: a domain with all three correctly configured is significantly harder for someone else to impersonate convincingly in a phishing attempt, since spoofed mail is more likely to fail the checks and get quarantined or rejected before it reaches an inbox.