SPF, DKIM and DMARC Explained

If your email lands in spam, or scammers are forging your domain, the fix almost always involves three DNS records: SPF, DKIM and DMARC. They work as a team, and each answers a different question about whether a message is really from you.

The problem they solve

Plain email has no built-in proof of sender. Anyone can put your address in the "From" field, which is exactly how phishing works. SPF, DKIM and DMARC are the layers that let a receiving server check whether a message claiming to be from your domain is genuine — and tell it what to do if not.

SPF: which servers may send

SPF (Sender Policy Framework) is a DNS record listing the servers allowed to send mail for your domain. When a message arrives, the receiver checks whether the sending server's IP is on your list.

• If yes, SPF passes.
• If no, it is suspicious — possibly a forgery, possibly a service you forgot to authorise.

The common mistake is forgetting a legitimate sender: your marketing platform, your helpdesk, your accounting software. Each one that sends as your domain must be in the record. SPF also has a hard limit of ten DNS lookups, which large setups blow past, silently breaking the check.

DKIM: a tamper-proof signature

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. Your mail server signs outgoing mail with a private key; you publish the matching public key in DNS. The receiver verifies the signature.

This proves two things: the message really came from your domain, and it was not altered in transit. DKIM survives forwarding better than SPF does, because the signature travels with the message rather than depending on the sending IP.

DMARC: the policy that ties it together

SPF and DKIM each pass or fail, but on their own they do not tell the receiver what to do about a failure. That is DMARC's job.

DMARC (Domain-based Message Authentication, Reporting and Conformance) does three things:

• Alignment. It requires that the domain SPF or DKIM checked actually matches the visible "From" domain, closing a loophole where a message passes SPF for some unrelated domain.
• Policy. You tell receivers how to treat failures: none (just monitor), quarantine (send to spam), or reject (refuse outright).
• Reporting. Receivers send you aggregate reports showing who is sending as your domain and whether they pass — invaluable for spotting both forgers and your own misconfigured services.

A message passes DMARC if it aligns and passes either SPF or DKIM. So the two underlying checks give you redundancy; DMARC enforces and reports on them.

The order to roll them out

Rushing to reject can block your own legitimate mail. The safe sequence:

1. Publish SPF listing every service that sends for you.
2. Enable DKIM signing on each of those services and publish the keys.
3. Publish DMARC at p=none first — monitoring only. Read the reports.
4. Once the reports show your real mail passing and you have fixed any gaps, tighten to quarantine, then reject.

Moving straight to enforcement without the monitoring phase is how people accidentally send their own invoices to spam.

Checking your setup

Each record is easy to get subtly wrong — an SPF record over the lookup limit, a DKIM key published at the wrong selector, a DMARC policy that never actually aligns. Looking up and explaining your current SPF, DKIM and DMARC records, and generating a correct DMARC record tag by tag, all run from your browser. Verify each of the three in turn, start DMARC in monitoring mode, and only harden the policy once the evidence says your real mail is passing.