Postmortem: The Phish That Passed DKIM

It's the alert every analyst has learned to mistrust: a user-reported phish where the initial automated scan comes back clean. The headers look plausible, there are no obviously malicious links, and worst of all, the Authentication-Results header flashes a confident 'dkim=pass'. Your gut says it's bad. The machine says it's fine. The machine is wrong.

This isn't a failure of cryptography. It's a failure of context. That 'pass' verdict is technically correct, but it’s the answer to the wrong question. The signature is valid, but is it from who you *think* it's from? Almost certainly not.

Let’s walk through the triage of one of these incidents. We’ll pop the hood, read the headers like the crime scene they are, and pinpoint exactly how a threat actor can get a green checkmark next to their name by hijacking someone else's infrastructure.

That Deceptive Green 'Pass' in the Headers

When an email lands in a modern inbox, the receiving mail transfer agent (MTA) performs a series of checks defined by standards like SPF (RFC 7208) and DKIM (RFC 6376). The results are stamped into the Authentication-Results header. It's the first place any analyst looks during triage.

Authentication-Results: mx.google.com; dkim=pass header.i=@acme-marketing.com header.s=s1 header.b=xyz...; spf=pass (google.com: domain of bounce-123@sendgrid.net designates 168.245.122.56 as permitted sender) smtp.mailfrom=bounce-123@sendgrid.net;

Seeing `dkim=pass` feels like a sign of legitimacy. It means the receiving server successfully validated a cryptographic signature attached to the email. But what did it actually validate? It confirmed that the message was signed by a private key, and that the corresponding public key exists in the DNS records of the domain listed in the signature's `d=` tag. That's it. It proves *who signed it*, not that the signer is *authorized to send on behalf of the From address*.

Authentication vs. Authorization

This is the absolute crux of the issue. DKIM authenticates the signing domain. It does not, by itself, authorize that domain to send mail for the purported author. Imagine a notary public who stamps a document. The stamp proves the notary is real, but it doesn't prove the claims *in the document* are true. In our case, the 'notary' is a massive, legitimate email service provider (ESP) like SendGrid, Postmark, or Mailchimp. The document is the phish.

Following the Signature Trail

To unravel this, you need to dissect the `DKIM-Signature` header itself, not just the summary in `Authentication-Results`. This header is a block of key-value pairs, separated by semicolons. It’s dense, but two tags are critical for our investigation: `d=` for the signing domain and `s=` for the selector.

Identifying the True Signer

The `d=` tag tells you which domain's DNS to query for the public key. The `s=` tag is the specific record name. Together, they form a DNS query path: `s._domainkey.d`. In a typical phish exploiting a third-party service, the `From:` header will say something like `From: "Your Bank" <security@yourbank.com>`, but the `d=` tag in the DKIM signature will be `d=sendgrid.net` or `d=amazonses.com`.

This mismatch is the first major red flag. The email claims to be from Your Bank, but it's cryptographically signed by an ESP. This is a common and legitimate practice for marketing mail, but in a security context, it requires immediate suspicion.

Verifying the Public Key

With the selector and domain in hand, you can perform a manual DNS lookup to confirm what the receiving MTA did. Using a command-line tool like `dig`, you can query the TXT record directly.

dig s1._domainkey.sendgrid.net TXT

The result will be a TXT record containing the public key (`p=...`). The fact that this record exists and contains a valid key is why the check resulted in `dkim=pass`. You've just manually confirmed the cryptographic validity. Now you know the signature is real, and you know it belongs to the ESP. The investigation shifts from cryptography to supply chain.

Root Cause: The Compromised Vendor Account

The attacker didn't break DKIM. They didn't forge a signature or compromise a bank's mail servers. They did something much simpler: they compromised an account on a trusted third-party platform.

Think about how many departments use services like SendGrid, Mailchimp, or other ESPs. A marketing team at a small vendor that provides services to 'Your Bank' might have an account. If a threat actor gets the credentials for that marketing account—via credential stuffing, password spraying, or a simple phish targeting the vendor—they inherit the ability to send DKIM-signed mail.

The ESP's infrastructure is working exactly as designed. It receives an API call from an authenticated user, constructs an email, signs it with its own key infrastructure (`d=sendgrid.net`), and sends it. The ESP has no idea the content is malicious; it only knows the API key or password was valid. The resulting email passes DKIM because it's genuinely signed by a legitimate, high-reputation sender. This is a classic Business Email Compromise (BEC) that exploits the supply chain.

The DMARC Hammer: Why Alignment Is the Answer

This is where DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489, becomes the essential control. DMARC doesn't just check if SPF and DKIM pass; it checks for *alignment*.

DMARC alignment requires that the domain used for the SPF or DKIM check has a relationship with the domain in the `From:` header. There are two modes: `relaxed` and `strict`. Relaxed alignment allows subdomains (e.g., `d=marketing.yourbank.com` can align with `From: user@yourbank.com`). Strict alignment, specified with `aspf=s` and `adkim=s` in the DMARC record, requires an exact match.

How Alignment Catches This Attack

In our scenario, the email has a `From:` header containing `yourbank.com`. The DKIM signature, however, passed with `d=sendgrid.net`. Because `sendgrid.net` does not match `yourbank.com`, this message fails DKIM alignment check, even though the signature itself passed the cryptographic check. A properly configured DMARC policy at `p=quarantine` or `p=reject` would instruct the receiving MTA to junk or block the message.

This is the operational stake of DMARC. It closes the loophole that allows a valid signature from an unauthorized source. It moves beyond 'Is this signature real?' to ask 'Is this signature from the entity that's *supposed* to be speaking?' Without DMARC alignment, a `dkim=pass` is a weak signal in the face of a determined attacker.

For organizations, this means your DMARC implementation can't stop at `p=none`. You need an enforcement policy. For analysts, it means knowing to check DMARC alignment results in the `Authentication-Results` header, not just the simple SPF/DKIM verdicts.

The takeaway

A `dkim=pass` verdict on a phishing email isn't an anomaly; it's a feature of modern email delivery being exploited. Attackers know that security teams and automated filters can be lulled into a false sense of security by that green checkmark. They’ve moved on from breaking crypto to simply borrowing trust from legitimate platforms.

The next time you see a phish that passed an authentication check, don't close the ticket. Start digging. Find the signing domain, check for alignment, and map it back to your known vendors. Authentication results are clues, not conclusions. The real analysis starts when you ask not just *if* it passed, but *why* it passed. Platforms like MailSleuth.AI can automate this header deconstruction and vendor cross-referencing, but the fundamental analytic mindset is irreplaceable.