What are SPF, DKIM, and DMARC?

Definition

SPF, DKIM, and DMARC are complementary email-authentication mechanisms published as DNS records: SPF lists which servers may send mail for a domain, DKIM cryptographically signs outgoing messages, and DMARC tells receivers what to do with mail that fails those checks and where to send reports.

Background

Email was designed without a way to verify the sender, so anyone can put your domain in the From line. The three records close that gap from different angles. SPF (RFC 7208) is a TXT record listing the servers and services authorized to send as your domain. DKIM (RFC 6376) attaches a signature to each outgoing message that a receiver verifies against a public key in your DNS, proving the message was not altered in transit and did come from an authorized sender. DMARC (RFC 7489) ties the two together: it requires that a passing SPF or DKIM result also aligns with the domain in the visible From address, states a policy for handling failures, and asks receivers to send aggregate reports back to an address you nominate.

Why it matters

Domain spoofing is the mechanism behind a large share of phishing and business email compromise, and the target is often your customers and suppliers rather than your own staff. These records are also public, which cuts both ways: a prospect, an auditor, or an attacker can check your DMARC policy in seconds and see whether you enforce it or merely watch. Because they are cheap to publish and externally visible, they are a common early signal of how seriously an organization takes security — and several frameworks expect email protections of this kind as part of communications security.

Step by step

1. Inventory every service that sends mail as your domain, including marketing, invoicing, ticketing, and product notifications.
2. Publish an SPF record covering exactly those senders, and keep it within the lookup limits the specification sets.
3. Enable DKIM signing at each sending service and publish the corresponding public keys.
4. Publish DMARC starting at p=none with a reporting address, so you can see who is sending as you before you enforce anything.
5. Read the aggregate reports, fix the legitimate senders that fail alignment, then move the policy to quarantine and finally to reject.
6. Re-check whenever you add a mail-sending vendor, because a new sender that nobody added to SPF starts failing silently.

Examples

• A company at p=none discovers from its reports that an invoicing tool has been sending unaligned mail for a year, fixes it, and then moves to p=reject.
• An attacker sends invoice fraud from a lookalike sender; because the real domain publishes p=reject, the spoofed variant is refused rather than delivered.

Common mistakes

• Publishing DMARC at p=none and treating that as done. Monitoring is not enforcement, and a policy of none instructs receivers to do nothing.
• Going straight to p=reject without reading reports first, which silently blocks legitimate mail from a sender nobody remembered.
• Letting SPF drift as vendors are added and removed, until it exceeds its lookup limit or authorizes services no longer in use.
• Assuming DKIM alone is enough; without DMARC, a receiver has no instruction about what to do when a check fails.

FAQ