SPF, DKIM and DMARC Explained

The short answer. SMTP lets anyone claim to be sending from your domain. SPF says which servers may send, DKIM cryptographically signs the message, and DMARC tells receivers what to do when those checks fail and sends you reports. All three are DNS records. Without a DMARC policy, your domain is spoofable, and that includes domains that never send email at all.

---

The problem#

Email was designed in an era of mutual trust. Nothing in SMTP verifies that the From address is real. A server can claim to be sending as your bank, your CEO or your domain, and by default receiving servers have no way to know.

Every modern anti-spoofing mechanism is a retrofit onto that gap. There are three, they do different jobs, and they only work properly together.

---

SPF: who is allowed to send#

Sender Policy Framework is a DNS TXT record listing the servers authorised to send mail for your domain. A receiving server looks it up and checks whether the connecting server is on the list.

A minimal record looks like this:

v=spf1 include:_spf.google.com ~all

The mechanisms are read left to right. include pulls in another provider's list, ip4 and ip6 allow specific addresses, mx allows whatever your MX records point at, and all at the end catches everything else.

That final qualifier matters. ~all is a soft fail, meaning treat as suspicious. -all is a hard fail, meaning reject. Start with the first, move to the second once you are confident.

The trap: the 10 lookup limit. SPF permits a maximum of ten DNS lookups when evaluating a record, and each include counts, including nested ones inside your providers' records. Add a marketing platform, a helpdesk, a CRM and a transactional sender and you can quietly exceed it. Past ten lookups the record is a permanent error, and receivers treat it as though you have no SPF at all. Nothing warns you.

SPF's weakness: it validates the envelope sender, not the visible From address, and it breaks when mail is forwarded, because the forwarding server is not on your list.

---

DKIM: proof the message is intact#

DomainKeys Identified Mail signs outgoing messages with a private key. The matching public key is published in DNS at a selector, like this:

selector._domainkey.example.com

The receiver fetches the public key, verifies the signature and learns two things: the message genuinely came from someone holding your key, and the signed parts were not altered in transit.

DKIM survives forwarding, which is exactly where SPF fails. That is why you want both.

Your mail provider generates the key pair and gives you the record to publish. Rotate keys periodically, and make sure key rotation does not silently stop.

---

DMARC: the policy and the reporting#

SPF and DKIM produce results. On their own, nothing says what a receiver should do about a failure, and nothing tells you it happened.

DMARC is a TXT record at _dmarc.example.com that supplies both.

v=DMARC1; p=none; rua=mailto:[email protected]

The policy p takes three values:

Alignment is the part people miss. DMARC does not merely require SPF or DKIM to pass. It requires the passing domain to align with the domain in the visible From address. This is what closes the spoofing hole, because an attacker can trivially pass SPF for their own domain while displaying yours.

The rua address receives aggregate reports: daily XML summaries of who is sending as you and whether they passed. They are unreadable by hand and there are services that parse them, but even skimming one tells you things about your own mail you did not know.

---

The order to do this in#

1. Inventory your senders. Mail platform, marketing tool, helpdesk, invoicing system, CI notifications, anything that sends as your domain. Missing one is how you break legitimate mail later.

2. Publish SPF listing all of them, ending in ~all.

3. Enable DKIM at every sender that supports it and publish each key.

4. Publish DMARC with p=none and a reporting address. Change nothing else.

5. Read reports for a few weeks. Find the senders you forgot. Fix their alignment.

6. Move to p=quarantine, then after more reporting to p=reject.

Do not start at reject. You will discover your forgotten senders by having their mail disappear, usually the invoicing system, usually at month end.

---

Domains that never send email#

This is the part almost everyone skips, and it is the easiest win available.

A domain with no mail service still accepts spoofed From addresses unless you say otherwise. Attackers actively prefer these, because there is no legitimate traffic to blend with and no one watching.

For a parked or defensive domain, publish:

v=spf1 -all

and

v=DMARC1; p=reject;

That is two records saying nothing sends from here, reject anything that claims to. It takes two minutes per domain and closes the hole permanently. Include it in your portfolio audit for every name you own.

---

Why this is becoming mandatory#

DMARC adoption among the Global 2000 rose from 39% in 2020 to 80% in 2025 according to CSC's Domain Security Report 2026, pushed partly by the EU's NIS2 Directive.

Major mailbox providers have also tightened bulk-sender requirements, making authentication a deliverability issue rather than only a security one. Unauthenticated mail increasingly does not arrive, which turns this from a security project into an operational one.

---

Common questions#

Do I need all three of SPF, DKIM and DMARC?

Yes. SPF and DKIM are checks; DMARC decides what happens when they fail and reports it to you. SPF alone breaks on forwarding, and neither SPF nor DKIM protects the visible From address without DMARC alignment.

What is the difference between SPF and DKIM?

SPF checks whether the sending server is authorised. DKIM checks whether the message carries a valid cryptographic signature from your domain. SPF validates the route, DKIM validates the message.

What does p=none mean in DMARC?

Monitoring only. Receivers deliver mail normally and send you reports. It is the safe starting position while you find every legitimate sender, and it provides no protection on its own.

Why is my SPF record failing?

The most common cause is exceeding the ten DNS lookup limit, usually after adding another sending service. Past that limit the record is a permanent error and receivers behave as though you have no SPF at all.

Do parked domains need SPF and DMARC?

Especially parked domains. Publish v=spf1 -all and a DMARC record with p=reject. They send no legitimate mail, so there is nothing to break and nothing to monitor.

Will DMARC reject break my email?

Only if you skip the monitoring phase. Run p=none, read the aggregate reports until every legitimate sender is aligned, then tighten through quarantine to reject.