What do SPF, DKIM and DMARC actually prove?¶

SPF, DKIM and DMARC test parts of the domain and delivery arrangement used by an email. They can support that a message followed an authorised route, carried a valid domain signature or aligned with the visible From domain. They do not identify the person who wrote the message, prove that the content is true or guarantee that the email is safe.

Start with the result in the suspicious message¶

In the supplier-payment investigation, the recipient's provider records three successful checks:

The results support that the email used an authorised and aligned route for ridgeway-componants.example. That is useful. It shows the message is not merely a crude direct forgery of that lookalike domain.

It does not make the lookalike domain genuine. Ridgeway Components actually uses ridgeway-components.example. The fraudster's domain can pass every authentication test while still being one letter wrong in exactly the right place.

The three checks perform different jobs¶

They contribute different information. “Authentication passed” is therefore too vague for an investigation. Record the method, result, assessed domain and trusted system that added it.

SPF checks an authorised route¶

SPF normally tests whether the IP address that handed the message to the receiving system was authorised by the policy for the SMTP envelope-sender domain - often reflected in the Return-Path.

An attacker using a domain they control can authorise their own server and achieve a perfect SPF pass. A legitimate message may also fail after some forms of forwarding because the forwarding server is not listed in the original domain's policy.

DKIM checks a domain signature¶

DKIM adds a cryptographic signature using a private key associated with a signing domain. The receiver retrieves the corresponding public key from DNS and checks the signed material.

A valid signature can support that the signing domain's key created the signature and that the covered parts of the message have not changed in a way that breaks it. The signing domain may be the visible From domain or a third-party platform. Not every header field has to be covered.

A compromised genuine account can send a harmful message through the normal provider and receive a valid DKIM signature. DKIM has then worked correctly; it has not identified the person who used the account.

DMARC checks alignment with the visible From domain¶

DMARC passes when at least one successful SPF or DKIM result aligns with the domain presented in the From field under the applicable DMARC rules. This makes simple direct spoofing of a protected domain harder.

DMARC therefore tests consistency between technical identities. It does not compare componants with the supplier name in somebody's invoice system and decide that the spelling looks a bit cheeky.

A failure also needs context¶

SPF, DKIM or DMARC failure may support spoofing, unauthorised sending or message alteration. It may also arise through forwarding, mailing-list changes, third-party platforms or poor configuration.

The result should therefore generate questions, not an automatic verdict.

Use results added by infrastructure you trust¶

A sender can insert convincing-looking text called Authentication-Results before the message enters the recipient's environment. The useful field is normally the one added by the recipient's provider or another system whose position and behaviour can be established.

Work from the trusted Received chain and identify which system performed the checks. Provider-side message trace may also preserve the result and connect it to a delivery event.

Read authentication in a repeatable sequence¶

1. Preserve the complete header

   Retain the native message because copied extracts may omit the domains, methods and trusted system needed to interpret the result.

2. Identify the trusted result

   Locate the Authentication-Results field added by the recipient's provider because sender-supplied result text can be fabricated.

3. Read SPF precisely

   Record the tested IP address and envelope-sender domain because SPF does not normally authenticate the visible author address directly.

4. Read DKIM precisely

   Record the signing domain and validation result because the signature may belong to a third-party platform and cover selected fields only.

5. Read DMARC alignment

   Identify which successful method aligned with the From domain because a pass describes domain consistency, not human authorship.

6. Move to attribution

   Use provider, account, session, device and contextual records because authentication cannot identify who caused the message to be sent.

Use a conclusion that says what actually passed¶

Avoid:

SPF, DKIM and DMARC passed, so Martin Cole sent the email.

A supported conclusion is closer to:

The recipient's provider recorded successful SPF, DKIM and DMARC checks aligned with ridgeway-componants.example, the lookalike domain used in the message.

That conclusion is useful because it identifies the authenticated domain arrangement without turning it into a person.

The point to remember¶