SPF, DKIM and DMARC in plain words

The three records that prove you are who you say you are. Authentication is the foundation of deliverability — without it, every other fix is built on sand. Here is what each record does, how they fit together, and the order to deploy them.

Why authentication exists

Email was designed in the 1970s without any mechanism to verify who was sending it. Anyone could put any address in the "From" field. SPF, DKIM, and DMARC are the three records that fix this problem — they let receiving mail servers verify that a message genuinely came from where it claims to come from.

SPF: who is allowed to send as your domain

SPF (Sender Policy Framework) is a DNS record that lists every IP address and sending service authorised to send mail as your domain. When a receiving server gets a message claiming to be from your domain, it checks your SPF record to see if the sending IP is on the list.

The ~all at the end means "softfail" — mail from unlisted sources is accepted but flagged. -all means "hardfail" — it is rejected. Use -all once you are confident you have listed every sending source.

SPF limitation: SPF only checks the "envelope from" (the technical Return-Path address), not the "From" header that the recipient sees. This is why SPF alone is not enough — you also need DKIM.

DKIM: a cryptographic signature on every message

DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing message. The signature is created using a private key that only your mail server holds. Your DNS record publishes the corresponding public key. Receivers use that public key to verify the signature — if it matches, the message has not been tampered with in transit and genuinely came from a server that holds your private key.

DKIM survives email forwarding in a way that SPF does not. When a message is forwarded, the sending IP changes (breaking SPF), but the DKIM signature is preserved in the message headers and can still be verified.

DMARC: the policy that ties SPF and DKIM together

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receivers what to do when SPF or DKIM fails, and sends you reports about what is happening to your mail.

A DMARC record has three key components:

• Policy (p=): none (monitor only), quarantine (move to spam), or reject (block the message)
• Reporting (rua=): an email address where receivers send aggregate reports about your mail
• Alignment: DMARC requires that either SPF or DKIM "aligns" — meaning the domain in the From header matches the domain in the SPF or DKIM check

The right order to deploy

1. Set up SPF first. List every system that sends email as your domain. Start with ~all (softfail).
2. Set up DKIM on every sending source. Each ESP, CRM, and transactional service has instructions for generating DKIM keys and adding the DNS records.
3. Add DMARC at p=none. This starts monitoring without affecting mail flow. Set up a reporting address to receive aggregate reports.
4. Read the DMARC reports for 4–6 weeks. Find any sending sources that are failing authentication and add them to your SPF and DKIM setup.
5. Move to p=quarantine, then p=reject. Once you are confident that 100% of your legitimate mail is passing authentication, enforce the policy.