SPF, DKIM, and DMARC Explained

Email was never designed with authentication in mind. The three protocols that retrofit trust onto SMTP — SPF, DKIM, and DMARC — are often deployed piecemeal, leaving gaps that spoofing campaigns exploit. This post walks through how they reinforce one another.

The Problem with Bare SMTP

By default, any server can claim to send mail on behalf of any domain. There is no built-in mechanism to verify that a message claiming to come from billing@example.com actually originated from infrastructure authorized by example.com. SPF, DKIM, and DMARC each close part of this gap.

SPF: Authorizing Senders

Sender Policy Framework publishes, via DNS, the list of hosts permitted to send mail for a domain. A receiving server checks the envelope sender against this record.

v=spf1 include:_spf.srrrs.com -all

The -all qualifier instructs receivers to reject any host not explicitly listed. A common misconfiguration is using ~all (soft fail), which weakens enforcement.

DKIM: Signing Messages

DomainKeys Identified Mail attaches a cryptographic signature to each outbound message. The receiver retrieves the public key from DNS and verifies the signature, confirming the message was not altered in transit.

DMARC: Tying It Together

DMARC builds on SPF and DKIM, adding alignment checks and a policy directive. It also enables aggregate reporting, giving domain owners visibility into who is sending mail in their name.

v=DMARC1; p=reject; rua=mailto:dmarc@srrrs.com; adkim=s; aspf=s

Rolling out p=reject directly is risky. Most teams start at p=none to gather reports, then progress to quarantine and finally reject.

Summary

SPF authorizes senders, DKIM guarantees integrity, and DMARC enforces policy while providing visibility. Deployed together with strict alignment, they make domain-level email spoofing substantially harder. At the edge, SRRRS evaluates all three before a message reaches internal routing.