SPF, DKIM & DMARC: How Email Authentication Works
✦ Key takeaways
- SPF lists which servers are allowed to send mail for your domain.
- DKIM adds a digital signature proving a message wasn't altered and came from your domain.
- DMARC ties the two together, tells receivers what to do with fakes, and sends reports.
- Together they cut down domain phishing and improve inbox deliverability.
The original email protocol was designed in an era when trust was the norm, so it had no way to verify that a sender was really who they claimed to be. The result is that address spoofing is easy: an attacker can send a message that looks like it comes from your domain to trick your customers. To close this gap, three complementary standards emerged, configured through DNS records: SPF, DKIM and DMARC.
SPF (Sender Policy Framework) is a list you publish in DNS specifying which servers and services are allowed to send mail for your domain. When a receiving server gets a message, it checks: did it come from an IP address listed in this domain's SPF record? If not, that's a sign of forgery. SPF's weakness is that it can break when messages are forwarded, so it isn't enough on its own.
Invoice & Quotation Maker
Professional invoices that auto-calc & print/PDF in a minute.
DKIM (DomainKeys Identified Mail) addresses a different angle: integrity and authenticity. Your sending server adds an encrypted digital signature to the message header using a private key, while the public key is published in DNS. The receiver can verify the signature to confirm the message genuinely came from your domain and wasn't altered in transit. DKIM usually survives forwarding.
But a question remains: what should the receiving server do if verification fails? This is where DMARC (Domain-based Message Authentication, Reporting & Conformance) comes in. It's a policy you publish in DNS telling receivers: "if a message doesn't pass SPF or DKIM aligned with my domain, do this" — either nothing (none) for monitoring, put it in spam (quarantine), or reject it outright (reject). Crucially, DMARC also sends you periodic reports showing who is trying to send as your domain.
The table shows each standard's role:
| Standard | What it checks | Published in | Answers |
|---|---|---|---|
| SPF | Authorized servers | DNS TXT record | "Is this server allowed?" |
| DKIM | Signature & integrity | DNS TXT (public key) | "Is the message genuine and intact?" |
| DMARC | Policy & reports | DNS TXT (_dmarc) | "What do I do with a fake?" |
The practical rollout is gradual: publish SPF and DKIM first, then add DMARC with a p=none policy to gather reports and monitor who sends as you without affecting delivery. Once you've confirmed all your legitimate services (your marketing provider, invoicing system, etc.) pass, raise the policy step by step to quarantine and then reject. Jumping straight to reject too early can block your own legitimate mail.
The benefit is twofold: protecting your domain's reputation from being used in phishing campaigns against your customers, and improving your deliverability because major mailbox providers trust authenticated domains more. For any small business sending invoices or newsletters, these settings are essential, not a luxury.