Skip to content
EML-025 Email Evidence

What do SPF, DKIM and DMARC actually prove?

title: What do SPF, DKIM and DMARC actually prove? subtitle: They test parts of the domain and delivery arrangement. They don’t identify the person who wrote the message. slug: what-do-spf-dkim-and-dmarc-actually-prove series: email-evidence section: technical-interpretation card_type: question_card pathway_order: 16 section_order: 3 status: draft public_safe: true video_ready: true word_count: 670 estimated_read_time_seconds: 277 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - SPF - DKIM - DMARC - authentication sources: - title: 'RFC 6376: DomainKeys Identified Mail (DKIM) Signatures' url: https://www.rfc-editor.org/info/rfc6376/ - title: 'RFC 7208: Sender Policy Framework (SPF)' url: https://www.rfc-editor.org/info/rfc7208/ - title: 'RFC 8601: Message Header Field for Indicating Message Authentication Status' url: https://www.rfc-editor.org/info/rfc8601/ - title: 'RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)' url: https://www.rfc-editor.org/info/rfc9989/

What do SPF, DKIM and DMARC actually prove?

They test parts of the domain and delivery arrangement. They don’t identify the person who wrote the message.

Script

SPF, DKIM and DMARC are often presented as though they answer one question:

Is this email genuine?

They don’t.

Each test answers a narrower technical question about the domain and the way the message was sent.

Used together, they can provide useful evidence about whether a message followed an authorised route.

They still don’t identify the person who wrote it.

Start with SPF.

SPF checks whether the IP address that handed the message to the receiving system was authorised to send for the domain used in the SMTP envelope sender, sometimes called the MAIL FROM or Return-Path domain.

A pass means the connecting server was authorised by that domain’s SPF policy.

It doesn’t prove that the visible From address was genuine.

It doesn’t prove the content was truthful.

And it doesn’t prove which account or person caused the message to be sent.

An attacker using a domain they control can achieve a perfect SPF pass.

A legitimate message can also fail SPF after certain types of forwarding, because the forwarding server may not be authorised by the original envelope-sender domain.

Now DKIM.

DKIM adds a cryptographic signature created using a key associated with a domain.

The signature covers the message body and selected header fields. A receiving system retrieves the public key from DNS and checks whether the signed material still matches.

A valid DKIM signature can support two useful points.

First, the signing domain controlled the private key used to create the signature.

Second, the signed parts of the message haven’t changed in a way that breaks the signature since signing.

But the signing domain may be a third-party platform rather than the visible From domain.

Not every header field has to be signed.

And a valid signature still doesn’t tell you which employee, customer, account holder or intruder triggered the message.

A compromised account can send a DKIM-valid email through the genuine provider.

DMARC connects these ideas to the visible From domain.

For DMARC to pass, at least one successful SPF or DKIM result must align with the domain presented in the From field.

Alignment means the relevant authenticated domain matches, or is permitted to relate to, the visible From domain under the DMARC rules.

That makes simple From-address spoofing harder.

A DMARC pass supports that the message used an authenticated route aligned with the domain shown to the recipient.

It still doesn’t prove human authorship.

It also doesn’t guarantee that the message is safe. A real but compromised organisation, abused customer account or authorised mailing platform can send harmful content that passes all three checks.

A DMARC failure also needs context.

It may support spoofing or unauthorised sending.

It may also result from forwarding, mailing-list changes, message modification or poor configuration.

Look at the exact result and the domain each test assessed.

Don’t just record “SPF pass” or “DKIM fail”.

Ask:

Which envelope-sender domain did SPF check?

Which IP address was tested?

Which domain signed with DKIM?

Which header fields were covered?

Did the DKIM body hash validate?

Which domain appeared in From?

Which method gave DMARC alignment?

And which trusted receiving system added the Authentication-Results field?

That last question matters because a sender can insert fake-looking authentication results before the message enters the recipient’s trusted environment.

Use the Authentication-Results field created by the recipient’s provider or another system whose position and behaviour you understand.

The common mistake is:

“SPF, DKIM and DMARC all passed, so the named person definitely sent the email.”

The correct conclusion is closer to:

“The recipient’s provider recorded that the message passed these domain-authentication checks and aligned with the visible From domain.”

That is valuable.

It can distinguish an authorised domain route from crude spoofing.

But if the question is who controlled the account, which device was used or who wrote the words, you need provider, session, device and contextual evidence.

Think of SPF, DKIM and DMARC as checks on the delivery arrangement.

They can strengthen or challenge the message’s claim about its domain.

They don’t turn a domain into a person.

Key takeaway

SPF checks a sending route, DKIM checks a domain signature, and DMARC checks alignment with the visible From domain.

Source notes

Keep moving

Where this question leads

These links explain why the next page may matter, rather than presenting an undifferentiated list.