DKIM Passed, Phish Landed: Your Post-Incident Triage Guide

You see the alert. A user reported a phish, and your EDR confirms they clicked. As you pull the email for analysis, your eyes catch the one line in the header that makes your stomach drop: `dkim=pass`.

This is the moment of cognitive dissonance every SOC analyst knows. We're trained to see SPF, DKIM, and DMARC as our primary authentication backstops. A pass should mean the message is legitimate, or at least that it's authenticated. But the credential harvesting page staring back at you says otherwise.

The truth is, DKIM isn't a seal of approval. It’s a seal of *provenance*. As defined in RFC 6376, DomainKeys Identified Mail provides a cryptographic signature that verifies two things: the signing domain (`d=`) is responsible for the message, and parts of the message (specified in the `h=` tag) haven't been modified in transit. It says nothing about the sender's *intent*. A phish that passes DKIM isn't a paradox; it's just the start of a more interesting investigation.

The Initial Autopsy: From Authentication-Results to DKIM-Signature

Your first move in any email-based incident is to grab the full, raw headers. Don't trust the summary your mail client shows you. You need the complete story, written by every mail transfer agent (MTA) that touched the message.

Start with the `Authentication-Results` header. This is the summary generated by *your* inbound mail gateway, and it's your ground truth for what your environment saw. It will give you the topline verdict for SPF, DKIM, and DMARC in one convenient place. If it says `dkim=pass`, your next job is to find the corresponding `DKIM-Signature` header that it evaluated. There may be several if the email was processed by multiple systems.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=some-saas-vendor.com; s=s1; t=1678886400; bh=AbCdEfGhIjKlMnOpQrStUvWxYz1234567890abc=; h=From:To:Subject:Date:MIME-Version:Content-Type; b=AGoodSignatureWouldBeMuchLongerAndLookLikeRandomData...

This block of text is the evidence. Let's break down the critical tags: `d=` is the signing domain, `s=` is the selector (the specific key used), `a=` is the algorithm, `bh=` is the body hash, and `b=` is the digital signature itself. In our triage, the most important piece of data right now is the `d=` domain. This tells you who *claims* to have sent the message, which is often different from the `From` header address.

Who Signed This? Chasing Down the 'd=' Domain

The investigation hinges on the identity of the domain in the `d=` tag. Was it your own organization, a trusted partner, or an unknown entity? The answer dictates your next steps.

The Signer is Your Domain (d=yourcompany.com)

This is a high-priority situation. A DKIM-valid signature from your own domain implies the message originated from a system that possesses a valid private key. This could be a compromised server, a web application with a 'send mail' feature, or an employee's compromised account on an integrated third-party service that is authorized to send on your behalf. The signature is legitimate, but it's signing malicious content.

The Signer is a Third-Party Vendor (d=some-crm.com)

This is an extremely common scenario. Modern enterprises use dozens of SaaS platforms for marketing, sales, HR, and finance—many of which send email. These platforms (think Salesforce, Mailchimp, SendGrid) typically sign emails with their own DKIM keys. So you might see an email with `From: sales@yourcompany.com` but a DKIM signature with `d=sendgrid.net`.

Here, the DKIM `pass` is technically correct; SendGrid's infrastructure did, in fact, send the message. The problem is a potential compromise of *your account* within that third-party service. An attacker with credentials to your company's CRM account can use that platform's trusted sender status to blast out phishing emails that carry a valid DKIM signature. This is where DMARC alignment becomes critical. DMARC checks if the `d=` domain aligns with the `From` domain. If it doesn't, and your DMARC policy is set to `p=quarantine` or `p=reject`, the message should be stopped. But if alignment isn't enforced, that phish sails right through.

The Signer is an Attacker's Domain (d=attacker-c2.net)

Sometimes the `d=` domain is completely unrelated to your company or its vendors. The attacker sets up DKIM on their own domain, `attacker-c2.net`, and sends a phish with a spoofed display name like "CEO John Doe" but a `From` address of `john.doe@attacker-c2.net`. The email passes DKIM because the signature is valid for the sending domain. This isn't a failure of DKIM, but an attempt to bypass filters that only check for a signature's existence, not its relevance. Again, a properly configured DMARC policy on your domain is the defense here, as it would flag the mismatch between the `From` header (`yourcompany.com`) and the authenticated signing domain (`attacker-c2.net`).

Inspecting the Weapon: Key Strength and Test Flags

Once you know who signed the message, you need to analyze the key they used. This requires a simple DNS query for the public key, located at `selector._domainkey.domain`. For a signature with `d=yourcompany.com` and `s=q1-2024`, you'd query the TXT record for `q1-2024._domainkey.yourcompany.com`.

Weak Keys and Old Algorithms

The DKIM specification in RFC 6376 was published in 2011 and recommended keys of at least 1024 bits. In cryptography, that's ancient history. Modern best practice, reinforced by NIST, is to use 2048-bit RSA keys. While factoring a 1024-bit key isn't trivial, it's considered feasible for well-resourced adversaries. Finding a 1024-bit key (or worse, something smaller) is a sign of poor security hygiene. While it's more likely the attacker simply compromised the system holding the private key, the presence of a weak key is a vulnerability that must be remediated.

The Treacherous Test Flag

This is one of the most overlooked DKIM misconfigurations. RFC 6376 includes a 'test mode' flag, `t=y`, intended for developers to test their DKIM implementation without affecting mail delivery. The RFC explicitly states that verifiers "SHOULD NOT treat messages from signers in testing mode differently from unsigned email."

v=DKIM1; k=rsa; p=...; t=y

Despite this warning, many inbound mail gateways will still grant a `dkim=pass` verdict to a signature with `t=y`. Attackers know this. They can scan DNS for DKIM records containing this flag. If they find a forgotten test record on your domain, they can craft phishing emails and sign them, knowing that many recipients will incorrectly trust the resulting 'pass'. This is a ticking time bomb in your DNS.

From Firefighting to Fortification

Analysis is useless without action. Your triage should lead directly to containment and then to strategic hardening to prevent a recurrence.

Immediate Containment

Your first job is to stop the bleeding. If you've traced the phish to a compromised third-party SaaS account, the immediate actions are clear: force a sign-out on all sessions, rotate the account's credentials (and the user's primary SSO credentials), check for other malicious activity within the platform (like new users or API keys), and begin your incident response process.

If the root cause is a weak or testing key on your own domain (`d=yourcompany.com`), the fastest way to invalidate it is to delete the public key record from your public DNS. This immediately causes signature verification to fail for any future emails using that key. Once the selector is defanged, you can proceed with the hunt for the server or system holding the corresponding private key.

Long-Term Hardening

Post-incident, you must shift to hardening. First, institute a policy for DKIM key rotation. Just like TLS certificates, these keys shouldn't live forever. A yearly rotation for all selectors is a solid baseline. Second, conduct a thorough audit of your DNS zone for all `_domainkey` subdomains. For every selector you find, you must be able to answer: What system uses this key? Who is the owner? When was it last rotated? If you can't answer those questions, the selector is a liability and should be pruned. Unmanaged DKIM selectors are undocumented cryptographic backdoors into your domain's reputation.

DMARC: The Crucial Context for DKIM

It's impossible to discuss DKIM validation without talking about DMARC. A DKIM 'pass' in a vacuum is nearly meaningless for security. It's DMARC, defined in RFC 7489, that provides the necessary context.

DMARC links the result of a DKIM (and/or SPF) check to the domain in the user-visible `From` header. It enforces *alignment*. For a message to be DMARC-aligned with DKIM, the `d=` tag in the DKIM signature must match the domain in the `From` address. An attacker sending from `d=attacker-c2.net` with `From: ceo@yourcompany.com` produces a message that is DKIM-valid but not DMARC-aligned.

A DMARC policy of `p=reject` tells the world: "If an email claims to be from me but fails DMARC alignment, drop it. Don't even put it in the spam folder." This single policy is the most effective defense against the abuse of irrelevant DKIM signatures and basic `From` header forgery. Without it, you are leaving the interpretation of a DKIM 'pass' up to the heuristics of thousands of different mail receivers.

The takeaway

A `dkim=pass` verdict on a malicious email isn't a failure of the protocol. It's a signal. It tells you that your investigation needs to move beyond simple forgery and into the realm of compromised credentials, abused third-party platforms, and forgotten DNS records. It shifts the question from "Was this forged?" to "Who signed this, and was their authority abused?"

Don't just see the green 'pass' and move on. Dig into the signature's domain, the key's strength, and any misconfigured flags. The real story of the incident is written in those details. Tools like MailSleuth.AI can surface these critical data points—key strength, test flags, and DMARC alignment failures—automatically, turning a 30-minute manual DNS crawl into a 30-second verdict.