Postmortem: When DKIM Passes but DMARC Fails

The alert landed just after lunch. A high-priority phish, reported by a user in finance. The email was an urgent payment confirmation from a SaaS vendor we actually use. The link, however, wasn't to their billing portal. It was a classic credential harvesting page, slick and convincing.

But as our SOC analyst started triage, something felt off. Our initial gateway scan showed a `dkim=pass`. The cryptographic signature was valid. So how could a legitimate signature be attached to a malicious email from a lookalike domain? The answer wasn't in the DKIM pass, but in the DMARC fail that accompanied it.

This is the story of a third-party breach where the attackers leveraged trust built on an incomplete security configuration. It’s a scenario that plays out constantly, and it hinges on a single, critical detail: DKIM identifier alignment.

An Alert That Almost Looked Legitimate

The phishing email was clever. It didn't come from a random Gmail account or a typo-squatted domain that a trained user might spot. The `From:` header displayed `finance@our-trusted-crm.com`, a plausible address from a vendor we’ve worked with for years. The subject line was 'Action Required: Your Quarterly Invoice is Overdue', complete with a convincing reference number.

Everything about the email body—logo, footer, color scheme—was a perfect copy of the vendor's real communications. The call to action was a large button labeled 'View Invoice'. The only giveaway was the destination URL, which pointed to `our-trusted-crm.secure-portal.co`, a domain registered just 24 hours prior. An attacker had compromised an adjacent system, likely a third-party email marketing platform used by the vendor, and was using it to spray their customers with highly targeted phishing.

The initial analyst on keyboard was right to be confused. The raw headers showed a valid DKIM signature. For many automated systems and junior analysts, a `dkim=pass` is a strong signal of legitimacy. It's supposed to mean the message is authentic. In this case, it only meant the message was authentically sent by the compromised *sending service*, not by the company it claimed to be from. And that makes all the difference.

In the Headers: Where Trust Broke Down

Raw email headers are the ground truth. They are the immutable log of a message's journey across the internet, stamped with the verdicts of every mail transfer agent (MTA) that handled it. When an email's legitimacy is in question, the `Authentication-Results` header field is where the real investigation begins.

The Misleading 'dkim=pass'

Looking at the headers for the phishing email, we found exactly what the attacker was counting on us to misinterpret. The DKIM check passed without issue. DomainKeys Identified Mail (DKIM), defined in RFC 6376, provides a way to cryptographically sign a message. It proves two things: that the signed parts of the email haven't been altered in transit, and that the signature was created by a key published in the DNS of the signing domain. The receiving server sees a valid signature, retrieves the public key from DNS, and confirms the match.

Authentication-Results: mx.google.com; dkim=pass header.i=@sendgrid.net header.s=s1 header.b=somehash; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=our-trusted-crm.com

The line above is a condensed version of what we saw. Notice the `dkim=pass`. This tells us the email was signed by a key belonging to `sendgrid.net`—a major email service provider. The signature is technically valid. The problem is, the email *claims* to be from `our-trusted-crm.com`.

The DMARC Verdict: A Hard 'fail'

This is where DMARC saves the day. DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489, doesn't just check for a valid signature. It asks a more important question: Does the domain that signed the message *align* with the domain in the `From:` header? As you can see in the header snippet, the DMARC result was a clear `fail`. The policy of the `From:` domain was `p=REJECT`, an instruction to the receiver to block the message entirely.

DKIM Alignment: The Detail That Matters Most

You can't talk about DMARC without understanding identifier alignment. This concept is the entire reason DMARC was created. SPF (RFC 7208) and DKIM (RFC 6376) were good first steps, but both could be passed by emails that were still completely fraudulent.

Authentication vs. Alignment

Authentication just proves *someone* authorized the message. DKIM proves the email was signed by a private key corresponding to a public key in a specific domain's DNS. In our incident, the mail was authenticated by `sendgrid.net`. No lies there. But that's not who the user thinks the email is from.

Alignment is what connects that cryptographic proof to the identity the user sees. For DKIM alignment, DMARC checks if the domain in the DKIM signature's `d=` tag matches the domain in the `From:` header. If they don't match, alignment fails. It's that simple, and that critical.

In our case:

DKIM Signature Domain (`d=`): sendgrid.net
Header From Domain: our-trusted-crm.com

Because `sendgrid.net` is not `our-trusted-crm.com`, DMARC's DKIM alignment check fails. The vendor had configured SendGrid to send email for them, but they never configured it to use aligned DKIM. This meant SendGrid was signing with its own domain by default. For a long time, nobody noticed because their DMARC policy wasn't set to `reject`. The attackers found a vendor with this exact misconfiguration, compromised their SendGrid account, and had a perfect vector for launching attacks that would pass basic DKIM checks.

Following the Trail with DMARC Forensics

So we know what happened, but we still need to know the scope. How many of these emails were sent? Which specific servers sent them? This is where DMARC reporting becomes an indispensable tool for incident response.

DMARC provides two types of reports. Aggregate (`RUA`) reports are XML-based daily summaries showing IP addresses, sender domains, and pass/fail counts. They're great for monitoring overall compliance and deliverability. But for an active incident, you need the forensic reports.

The Power of RUF Reports

Forensic (`RUF`) reports are generated in near real-time for individual message failures. A `RUF` report is essentially a full copy of the malicious message, including all headers and the message body, sent to an address you specify in your DMARC record. Yes, this means they can contain personally identifiable information (PII), which is why many organizations shy away from them. For a security team, however, they are pure gold.

By analyzing the RUF reports generated by our own mail gateway during this incident, we were able to:

1. Identify the exact source IP addresses of the sending servers within SendGrid's infrastructure. This information was crucial for reporting the abuse to SendGrid's security team with actionable data.
2. Collect copies of every variant of the phishing email, allowing us to extract all unique phishing URLs and indicators of compromise (IOCs).
3. Confirm which of our users were targeted and if the messages were quarantined or rejected, helping us scope our internal response.

Without `ruf` reports, we would have been flying blind, relying solely on user reports. With them, we had a complete, machine-generated picture of the attack campaign as it happened.

Your Playbook for Auditing Third-Party Senders

This entire incident was preventable. A simple audit of the vendor's sending practices would have revealed the DKIM alignment gap. Every organization that uses third-party services to send email—for marketing, transactional mail, payroll, HR—needs a process to validate their configuration.

A Practical Audit Process

First, create an inventory. You can't secure what you don't know you have. List every SaaS platform, service provider, or external system that sends email on behalf of your domain. This includes your CRM, marketing automation platform, customer support desk, and even services like your benefits provider.

Second, for each service, dig into their documentation on email sending. You're looking for instructions on setting up DKIM. The crucial question is: Do they support a custom DKIM setup where they sign with *your* domain, or are you forced to use their shared domain? Any service that doesn't let you set up an aligned signature is a security risk.

Third, validate. Don't trust the documentation. Use each service to send a test email to a mailbox you control. Open the raw message source and inspect the headers. Look at the `Authentication-Results` field. Does the domain in `header.d=` for the DKIM signature match the domain in the `header.from`? If not, you have a DKIM alignment failure.

Finally, remediate or accept the risk. If you find an alignment gap, open a ticket with the vendor. Most reputable services have a clear process for this, which usually involves you creating a few CNAME records in your DNS pointing to their DKIM keys. If a vendor refuses or is unable to support aligned DKIM, you must formally document and accept the risk, or begin searching for a more secure alternative.

The takeaway

A `dkim=pass` verdict on its own is table stakes. It’s a weak signal of trust that attackers are more than happy to exploit. The real security comes from DMARC's insistence on alignment—the unwavering link between the domain that signs the mail and the domain your users see in their inbox. When a third party sends mail on your behalf, they are borrowing your reputation. You have to ensure they are handling it correctly.

Auditing your senders for DKIM alignment isn't a one-time project; it's a continuous part of your security posture management. Every new vendor is a potential source of misconfiguration. Proactively hunting for these alignment gaps is infinitely less painful than explaining a breach. Tools like MailSleuth.AI are designed to automate this header analysis, surfacing these alignment failures before they become the starting point of your next incident.