DKIM's Crypto Footgun: Auditing SHA-1 Before It Bites Back

You see a `DKIM=pass` verdict in an `Authentication-Results` header and move on. It’s a passing grade. The cryptographic signature checked out, the key was valid, the domain is authenticated. But what if that pass is a lie? Not a forgery, but a signature written with a broken pen, using an ink that security researchers proved could be convincingly imitated years ago.

This is the reality of SHA-1 in DomainKeys Identified Mail (DKIM) signatures. While the broader security world has moved on, a surprising amount of email is still signed using this deprecated hash algorithm. It’s a ticking time bomb of technical debt, a signal of poor security hygiene that most mail receivers currently ignore for the sake of deliverability.

For security analysts and IT admins, this isn't just cryptographic pedantry. It’s a hidden vulnerability in your trust model for email. That passing verdict might be giving a free pass to senders who are cutting corners, and it’s on us to find them.

The Memo Everyone Missed: RFC 8301

The official death warrant for SHA-1 in DKIM was signed in January 2018. RFC 8301, titled "Cryptographic Algorithm and Key Usage Update to DKIM," was unambiguous. Citing the first public collision attack against SHA-1 from 2017 (known as SHAttered), the IETF authors laid out a clear directive. Signers MUST NOT generate signatures using `rsa-sha1`, and verifiers SHOULD NOT treat such signatures as valid.

Let's be precise about the language. The RFC uses standard requirement levels. "MUST NOT" is an absolute prohibition for signers. For verifiers—the inbound mail gateways—the guidance was a softer "SHOULD NOT." This wiggle room is the crux of our current problem. In the name of not breaking email delivery for laggards, major mailbox providers have largely ignored the "SHOULD NOT" and continue to validate SHA-1 signatures.

Why does it matter? DKIM's security relies on the collision resistance of its hash function. The signature process, simplified, involves taking a hash of the email's body and selected headers, then encrypting that hash with a private key. If an attacker can create two different email bodies (one benign, one malicious) that produce the same SHA-1 hash, they could potentially get a valid signature for the benign content and apply it to the malicious one. This is a chosen-prefix collision attack, and while not simple, it moved from theoretical to practical years ago.

Anatomy of a Weak Signature

To hunt for this vulnerability, you need to know what you're looking for. The evidence is hiding in plain sight within the `DKIM-Signature` header itself. This header is a collection of tags, each identified by a single letter, that describes the signature.

The `a=` Tag: Where the Algorithm Lives

The most important tag for this audit is `a=`, which specifies the algorithm used to create the signature. A modern, secure signature will declare `a=rsa-sha256`. The deprecated, weak signature will declare `a=rsa-sha1`. This is the smoking gun. It’s a direct confession from the sender that they are using an outdated cryptographic primitive.

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=thirdparty.example.com; s=selector123; h=From:To:Subject:Date:Message-ID; bh=...; b=...

When you see `rsa-sha1`, you've found it. Don't be fooled by a `DKIM=pass` in the `Authentication-Results` header. That pass only confirms that the signature mathematically validates against the public key in DNS. It says nothing about the strength of the hash algorithm used to generate it.

The `h=` Tag: A Quick Clarification

It's also worth understanding the `h=` tag. This tag lists which headers have been included in the hash calculation. Common entries are `From`, `To`, `Subject`, and `Date`. An attacker can modify any header *not* on this list without invalidating the DKIM signature. While header inclusion is critical for preventing spoofing, the hash algorithm specified in `a=` is what determines the cryptographic integrity of the entire signature.

Do Weak Signatures Still Pass Muster?

So, how do the big players handle this? Do Gmail and Microsoft 365, which process a massive percentage of global email, reject these signatures as RFC 8301 recommends?

The short answer, as of today, is no. They don't.

Both Google Workspace and Microsoft 365 will still validate a DKIM signature using `rsa-sha1` and return a `dkim=pass` result. This means that if the DKIM signature is aligned (the domain in the `d=` tag matches the `From` header domain), it will contribute to a DMARC `pass`. An organization can be at `p=reject` and still have its brand abused by a third-party sender using weak crypto, because the receiving gateways are choosing compatibility over strict security.

This creates a dangerous gap. A security team might believe their DMARC policy is protecting them, but a key pillar of that protection, DKIM, could be compromised by a sender stuck in 2017. Imagine a vendor's payment notification system signs with `rsa-sha1`. An attacker could theoretically craft a fake invoice with a malicious link that shares a signature with a legitimate, benign notification. The email lands in the user's inbox with all the green checkmarks of a validly authenticated message. This is the operational risk.

The Hunt: An Auditing Playbook

You can't fix what you can't find. Auditing your email ecosystem for SHA-1 requires identifying all the third-party services that send email on your behalf and then inspecting the signatures they generate.

Step 1: Identify Your Senders and Selectors

Start with your DMARC aggregate reports. These reports list all sources sending email claiming to be from your domain and the DKIM domains they are using for signing. For each DKIM domain (`d=`), you need to find the selector (`s=`). A selector is just a label that allows a domain to have multiple DKIM keys at once, often for different services. You'll find it in the `DKIM-Signature` header of any email sent by that service.

Step 2: Inspect the Signatures

The most reliable method is to trigger an email from each service and inspect the raw headers. Send a password reset, a test marketing email, or a system notification to a mailbox where you can view the full, unprocessed source. Look for the `Authentication-Results` header added by your gateway and the `DKIM-Signature` header from the sender.

In the `DKIM-Signature`, find the `a=` tag. Is it `a=rsa-sha1` or `a=rsa-sha256`? Document every sender that is still using SHA-1. This is your remediation list.

Authentication-Results: mx.google.com;
dkim=pass header.s=s1 header.b=... header.d=thirdparty.example.com;
spf=pass (google.com: domain of ... designates ... as permitted sender) smtp.mailfrom=...;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com — Example Authentication-Results Header

Notice the `dkim=pass` and `dmarc=pass` in the example above. This is what a successful but weak authentication looks like. The receiver notes the DKIM signature is valid, which is enough for DMARC to pass, completely ignoring the deprecated crypto used to generate it.

Practical Risk vs. Cryptographic Hygiene

Is a chosen-prefix collision attack on an email's DKIM signature a viable threat for the average attacker? Probably not. It's computationally expensive and requires a sophisticated adversary. You're far more likely to be targeted by a simple lookalike domain or credential phishing.

But that misses the point. The continued use of SHA-1 is a powerful signal—a 'tell' in the poker game of vendor security assessment. It signals a lack of attention to security bulletins, a resistance to updating infrastructure, and a culture that prioritizes 'if it ain't broke, don't fix it' over proactive risk management.

If a SaaS vendor hasn't managed to update a simple DKIM signing algorithm in the years since RFC 8301 was published, what other, more critical security practices are they neglecting? Are they patching servers? Are they rotating credentials? Are they enforcing MFA? The use of SHA-1 is a proxy indicator for poor security hygiene. It's a risk to your supply chain, and it erodes the trust you place in that vendor to handle your data or communicate with your customers.

Forcing the Upgrade

Once you've identified the offending senders, remediation becomes a matter of vendor management. The server signing with SHA-1 is almost certainly not yours; it belongs to your marketing platform, your HR system, or your customer support software.

Contact their support or your account manager with a clear, direct request. Don't ask if they can support SHA-256. Assume they should and demand a timeline for the migration. You can frame it as a compliance issue for your organization.

Our security policy no longer permits email sent on our behalf to be signed with the deprecated rsa-sha1 algorithm, as per IETF RFC 8301. Your platform is currently signing with rsa-sha1 for the selector 's123' on domain 'thirdparty.example.com'. Please provide your timeline for migrating all signatures to rsa-sha256.

This approach shifts the burden to them. You are the customer, and their lack of maintenance is putting your domain's reputation and security at risk. If they push back or have no plan, it may be time to evaluate competitors. The ability to use modern cryptography is a basic feature, not a premium add-on.

The takeaway

Auditing for SHA-1 in DKIM isn't about chasing cryptographic ghosts. It is a fundamental test of your email supply chain's security posture. Every `DKIM=pass` built on `rsa-sha1` is a crack in your DMARC armor, a sign that a vendor is asleep at the wheel. It's a pass you can't fully trust.

The responsibility falls to us, the defenders, to hold senders accountable. By finding these weak links and demanding they upgrade, we not only reduce a theoretical attack surface but also raise the security bar for the entire ecosystem. Platforms like MailSleuth.AI can help automate the discovery of these issues across all your senders, but the push for remediation starts with a simple question to your vendor: when will you stop using broken crypto?