SPF, DKIM and DMARC Explained Simply – With Examples

Definition: SPF, DKIM and DMARC are three email authentication methods. They show the receiving server whether a message really comes from the domain given as the sender. All three are published as records in your domain's DNS.

At its core, email is an old protocol. Originally, any server could enter any sender address. Attackers use exactly that for spoofing: they send mail that appears to come from your bank, your supplier or your own management. SPF, DKIM and DMARC close this gap for your own domain.

SPF: Who may send for your domain?

The Sender Policy Framework (SPF) is a list of permitted senders. It is published as a TXT record in your domain's DNS. The receiving server checks whether the message comes from a server on that list.

example.com.  TXT  "v=spf1 mx include:_spf.mailprovider.example -all"

mx allows your domain's mail servers.
include: adds a provider's list, for example a newsletter tool.
-all says: all other servers are not allowed. ~all would be the softer option.

Limits: SPF only checks the technical sender address in the message envelope, not the sender users see. SPF often fails on forwarding. And an SPF record may trigger at most ten DNS lookups. If you include many services, you quickly hit that limit.

DKIM: A digital signature on every message

DomainKeys Identified Mail (DKIM) adds a digital signature to every outbound message. Your mail server signs with a private key. You publish the matching public key in DNS.

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The receiver fetches the key and checks the signature. If it matches, the signed parts were not changed on the way: the body and the header fields the sender included in the signature, such as From, Subject and Date. The message also comes from a server that knows the key of the signing domain. The part before ._domainkey is called the selector. It lets you run several keys in parallel, for example for different services.

Limits: DKIM alone says nothing about whether the signing domain matches the visible sender. And attackers can resend a genuinely signed message unchanged. This is called DKIM replay.

DMARC: The rule that ties it all together

Domain-based Message Authentication, Reporting and Conformance (DMARC) builds on SPF and DKIM. It requires that at least one of the two checks passes and matches the domain in the visible sender. This match is called alignment.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

The p= policy defines what happens to mail that fails:

p=none: monitor only, block nothing.
p=quarantine: move the message to spam or quarantine.
p=reject: reject the message.

With rua= you receive daily aggregate reports from receivers. They show which servers send in your name and whether they pass.

How the three work together

A message from invoice@example.com reaches the recipient.
The server uses SPF to check whether the sending server is allowed.
It uses DKIM to check the signature.
DMARC checks whether at least one of the two passes and matches example.com.
If the message fails, the receiver applies your DMARC policy and records the result in its report.

Rolling out DMARC step by step

List your senders: Write down every system that sends mail with your domain: mail server, newsletter, CRM, ticket system, invoicing.
Set up SPF and DKIM: Add every service to SPF and enable DKIM wherever possible.
Start DMARC with p=none: Review the reports for a few weeks.
Close the gaps: Fix legitimate senders that still fail.
Tighten: Move to p=quarantine and then to p=reject.
Protect subdomains and unused domains: Domains that never send mail get v=spf1 -all and p=reject.

Why this is a must in 2026

Large mailbox providers such as Google, Yahoo and Microsoft now require SPF, DKIM and a DMARC record from bulk senders. Without them, mail lands in spam or is rejected. The German Federal Office for Information Security (BSI) describes the methods in its technical guideline TR-03182 on email authentication. Organizations covered by NIS2 must implement security measures that reflect the state of the art. A protected mail domain is usually part of that.

What SPF, DKIM and DMARC do not do

With a strict DMARC policy, the three methods protect your exact domain from forgery. Forgeries are only rejected from p=quarantine or p=reject on, and only by receivers that evaluate DMARC. They do not help against other tricks:

Domains that look almost like yours, for example with swapped or foreign characters.
Fake display names such as "Management" with a free mail address behind them.
Mail from real but hacked accounts. It passes all checks.

This is where a secure email gateway comes in. The SecTepe Mail Security Gateway, for example, detects lookalike domains, fake display names and DKIM replay. Its behavior analysis raises an alert when a known sender suddenly fails the DMARC check.

Conclusion

SPF says who may send. DKIM shows that the signed parts of the message are unchanged and come from the signing domain. DMARC ties both to the visible sender and decides what happens to forgeries. Set up all three, start DMARC in monitoring mode and tighten the policy step by step up to p=reject.

FAQ about SPF, DKIM and DMARC

What is the difference between SPF, DKIM and DMARC?

SPF defines which servers may send mail for your domain. DKIM adds a digital signature to every message. DMARC ties both checks to the visible sender address and tells the receiver what to do with mail that fails.

Do I need all three?

Yes. Each check alone has gaps. SPF breaks on forwarding, and DKIM alone says nothing about the visible sender address. Only DMARC links both to the sender the recipient sees. Large mailbox providers now require the combination from bulk senders.

Which DMARC policy should I choose?

Start with p=none and review the reports. Once all legitimate senders pass cleanly, move to p=quarantine and later to p=reject. Only p=reject reliably rejects forged mail sent in your domain's name.

Why does my mail land in spam even with SPF?

Common causes are a service missing from the SPF record, such as a newsletter tool, more than ten DNS lookups in the SPF record, or a missing DKIM signature. Also check whether the domain in the visible sender matches SPF or DKIM. Otherwise DMARC fails.

Do SPF, DKIM and DMARC protect against phishing?

They stop attackers from forging your exact domain once your DMARC policy is set to p=quarantine or p=reject and the receiver applies it. With p=none you only see forgeries in the reports. They do not help against lookalike domains, fake display names or hacked real accounts. For those you need additional checks, for example in a secure email gateway, and trained employees.

What is MTA-STS?

MTA-STS is a complementary standard. It specifies that mail to your domain may only be delivered encrypted over TLS. SPF, DKIM and DMARC check the sender, while MTA-STS protects the transport.

More terms in “Network Security”

All terms in “Network Security” →