What are DMARC, DKIM, and SPF?

Email was designed without any way to verify who sent a message. Anyone can put your domain in the From: field, and nothing stops them by default. SPF, DKIM, and DMARC are the three DNS records that close that hole — SPF and DKIM each prove something narrow, and DMARC turns those proofs into a decision the receiving server acts on.

The three records at a glance

• SPF publishes the list of servers allowed to send mail for your domain.
• DKIM attaches a cryptographic signature to each message, proving it came from your domain and was not modified in transit.
• DMARC tells receiving servers what to do when a message fails both — and asks them to send you reports.

None is optional if you want the visible From: address protected. Here is why.

What is SPF?

SPF (Sender Policy Framework) is a TXT record listing the servers authorised to send email for your domain. When a message arrives, the receiving server checks whether the connecting server is on that list.

The critical detail — the one that trips up nearly everyone — is which address SPF checks. It validates the envelope sender (RFC5321.MailFrom, the return-path), not the From: header the recipient sees. A spoofed message can pass SPF using an envelope domain the attacker controls, while showing your domain in the From: field.

SPF also carries a hard limit: evaluation must not exceed 10 DNS-querying terms, counted recursively across every include:. Exceed it and the record returns permerror, which receivers treat as a failure. Our SPF guide covers the syntax.

What is DKIM?

DKIM (DomainKeys Identified Mail) adds a digital signature to the header of every outgoing message. The sending server signs selected headers and the body with a private key; the receiving server fetches the matching public key from your DNS and verifies the signature.

A valid signature proves the message originated from the signing domain and was not altered on the way. If it does not verify, the message is treated as unauthenticated.

DKIM's practical advantage over SPF is that it survives forwarding. A forwarded message keeps its signature and still authenticates at the final destination, while SPF fails because the forwarding server was never on your list. This is the main reason to run both.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the record that makes the other two useful. It does two jobs.

Alignment. DMARC requires that the domain authenticated by SPF or DKIM matches the domain in the visible From: header. A message passes DMARC if it passes SPF with an aligned envelope domain, or passes DKIM with an aligned signing domain. This is what protects the address your recipient reads — neither SPF nor DKIM does that alone.

Policy and reporting. Your DMARC record tells receivers what to do with messages that fail:

• p=none — take no action, but send reports. The monitoring stage.
• p=quarantine — deliver failing mail to spam.
• p=reject — refuse failing mail outright.

The rua tag names an address to receive aggregate reports — the only reliable way to discover every system sending as your domain before you turn on enforcement.

How they work together

A receiving server evaluating a message from your domain does roughly this:

1. Check SPF against the envelope sender.
2. Check the DKIM signature against your published public key.
3. Look up your DMARC record. Did either check pass and align with the visible From: domain?
4. If neither did, apply your DMARC policy — none, quarantine, or reject — and file a report.

Because step 3 accepts either an aligned SPF pass or an aligned DKIM pass, running both gives redundancy. Forwarded mail keeps DKIM; mail from a source that cannot sign keeps SPF.

Why this matters now

Authentication is now a delivery requirement, not a nice-to-have. Since February 2024, Google requires senders of more than 5,000 messages a day to Gmail accounts to publish SPF, DKIM, and DMARC. Lower-volume senders still need SPF or DKIM, and Yahoo introduced equivalent requirements. A domain with no DMARC record is not just spoofable — at volume, its mail is out of compliance with the largest mailbox providers.

Note that p=none satisfies Google's DMARC requirement, but stops nobody spoofing you.

Common misconceptions

• "SPF stops spoofing." It does not. SPF authenticates an address the recipient never sees. Only DMARC alignment protects the visible From:.
• "A DMARC record means we're protected." Only at p=quarantine or p=reject. At p=none you are collecting data, not blocking anything.
• "DKIM encrypts the message." It signs; it provides integrity and origin proof, not confidentiality. Protecting the contents is message encryption, a separate mechanism.
• "We can skip the monitoring stage." Going straight to p=reject is how companies discover their invoicing system was never authenticated — by having its mail rejected.

How to roll it out

1. Inventory your senders — mailbox provider, marketing tools, CRM, helpdesk, billing, alerts.
2. Publish SPF listing those sources, ending in ~all while you verify the list.
3. Enable DKIM signing on every platform that supports it, and publish each public key.
4. Publish DMARC at p=none with a rua address, and leave it there long enough to see a full sending cycle.
5. Read the reports and fix every legitimate source that fails alignment. Understanding DMARC reports walks through the XML.
6. Move to p=quarantine, then p=reject — only once reports show your legitimate mail passing.
7. Keep it current. Authentication drifts as vendors change. Re-check with Email Security Score.

Frequently asked questions

Can I publish DMARC before SPF and DKIM are working?

You can, at p=none, and it is often the smartest first move — the reports show what your sending landscape actually looks like before you commit to a policy. What you must not do is publish p=quarantine or p=reject before those reports show your legitimate sources passing.

Do subdomains inherit the DMARC policy?

Yes. Unlike SPF, DMARC falls back to the organisational domain's policy when a subdomain has no record of its own. Override this with the sp tag when a marketing subdomain needs a laxer policy while you fix it.

What happens to mail from a domain with no DMARC record at all?

Receivers fall back to their own heuristics, and some deliver spoofed mail straight to the inbox. Nothing requires them to reject it — the entire problem DMARC exists to solve.

Does DKIM need a new key for every sending platform?

Each platform signs with its own key, published under its own selector — google._domainkey and selector1._domainkey can coexist. Selectors are what allow several platforms to sign for one domain without collision. See managing multiple DKIM records.

How long should I stay at p=none?

Long enough to observe one complete sending cycle, including anything that runs monthly or quarterly. A month is the usual minimum. Rushing this step is the most common cause of a failed DMARC rollout.

Related reading

• How to create an SPF record
• How to understand DMARC reports
• How to stop email spoofing