SPF, DKIM, and DMARC Explained: What Each One Actually Does

SPF, DKIM, and DMARC get mentioned constantly in deliverability conversations, often as if they were interchangeable. They are not. Each one verifies something different, and understanding what each actually does makes it much easier to diagnose authentication problems instead of guessing.

SPF: Who Is Allowed to Send

Sender Policy Framework is a DNS record that lists which mail servers are authorized to send email on behalf of your domain. When a receiving server gets a message, it checks whether the sending IP appears in that domain’s published SPF record. If it doesn’t, the message looks like it could be spoofed. SPF is domain-wide and doesn’t verify anything about the message content itself, only where it came from.

DKIM: Proof the Message Wasn’t Altered

DomainKeys Identified Mail attaches a cryptographic signature to outgoing messages, generated with a private key that matches a public key published in your DNS. The receiving server verifies the signature against that public key. If it matches, the receiver knows the message genuinely came from your domain and wasn’t modified in transit. Unlike SPF, DKIM travels with the message itself, which is why it still works even when mail is forwarded.

DMARC: The Enforcement Layer

DMARC doesn’t replace SPF or DKIM, it sits on top of them. A DMARC record tells receiving servers what to do when a message fails SPF or DKIM alignment: monitor only, quarantine to spam, or reject outright. DMARC also generates aggregate reports showing who is sending mail using your domain, which is often how senders discover spoofing or misconfigured third-party tools they forgot were still authenticated.

Why All Three Matter Together

A domain with SPF but no DKIM is vulnerable to forwarding-related failures. A domain with DKIM but no DMARC has no enforcement policy, so spoofed mail using look-alike alignment can still get through. A domain with all three, correctly aligned, gives mailbox providers the clearest possible signal that a message is legitimate, which directly affects inbox placement. This is precisely the technical foundation covered in our DNS authentication setup service and part of the broader email delivery practice.

For the full technical specifications, see the IETF SPF specification (RFC 7208) the IETF DKIM specification (RFC 6376) and the IETF DMARC specification (RFC 9989).

Checking Your Own Records

Our free deliverability tools page links to DNS checkers that will show you exactly what’s currently published for your domain. If something looks misconfigured or you’re not sure how to interpret the results, that’s a good time to talk to a specialist rather than guess your way through DNS changes on a production sending domain.