MailDingo

dkim=pass

dkim=pass

A domain digitally signed this message and the signed parts arrived unchanged, but check which domain signed it: it may not be the sender you see.

dkim=pass means the message carried a DKIM signature, the receiver fetched the public key from the signing domain's DNS, and the signature matched the headers and body as they arrived. Two things follow from that. The domain in the signature's d= tag took responsibility for the message, and the parts it signed have not been changed since. Which domain that is matters more than the pass itself.

What the RFC says

RFC 8601 §2.7.1 defines pass as a signature that was acceptable to the receiver and passed verification. The verification steps are in RFC 6376 §6.1.3: hash the canonicalized body and compare it with bh=, then check the b= signature over the signed headers with the published key. The d= value is the Signing Domain Identifier (§2.5), and the A-R header reports it as header.d (or header.i, which is the same domain or a subdomain of it).

From: "Example Support" <help@example.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
       s=sel2026; h=from:to:subject:date:message-id; bh=...; b=...
DKIM-Signature: v=1; a=rsa-sha256; d=mailer.example.net; s=esp1; ...
Authentication-Results: mx.example.org;
       dkim=pass header.d=example.com header.s=sel2026;
       dkim=pass header.d=mailer.example.net header.s=esp1;
       dmarc=pass header.from=example.com

Read header.d before you relax

Messages often carry two signatures, as above: one from the brand and one from the email service that sent it. Each gets its own dkim= entry. A signature from mailer.example.net proves only that the service sent it. An attacker can just as easily sign phishing mail with their own domain and get a clean pass. For DMARC, a pass counts only if the d= domain aligns with the From domain (RFC 9989 §4.4.1). The analyser marks which signatures align.

Two further details are worth checking in the DKIM-Signature header:

  • h= lists the signed headers. From must always be signed (RFC 6376 §6.1.1). If Subject or To are missing, those could have been changed without breaking the signature.
  • l= limits how much of the body was signed. Anything after that length is unsigned, and RFC 6376 §8.2 warns that someone can exploit this by appending content. Some receivers report such signatures as dkim=policy instead.

If you received this message

An aligned pass, which usually shows up as dmarc=pass, is strong evidence that the From domain really sent it. A pass for some other domain tells you who sent it, nothing more.

If you own the domain

Make sure at least one signature uses your own domain, not just your provider's default. Most providers offer this as "custom domain authentication", set up with a couple of CNAME or TXT records. Use RSA keys of at least 2048 bits (RFC 8301 §3.2 says signers should), sign Subject, To, Date and Message-ID as well as From, and don't use l=.

See it in your own message

Paste the headers into the analyser to see which domain DKIM checked and whether it lines up with the From address.

Open the analyser