Barracuda Gateway Broke DKIM: Law Firm Email Carries Malicious Link After Authentication Collapses in Transit

The email read like routine legal correspondence. An attorney discussed retaining an investigator for a claims assignment, asked about sharing resources with another firm, and included the standard confidentiality disclaimer at the bottom. Signature blocks, firm addresses, and an embedded logo all matched what you would expect from a mid-Atlantic law firm. Nothing in the prose asked for credentials, money, or urgent action.

The sender domain, whiteandwilliams[.]com, is a legitimate law firm that has held its domain since 2001. DNS records show an active MX entry pointing to Office 365 mail protection, published SPF and DKIM records across two selectors, and a DMARC policy of v=DMARC1; p=none. This is a real organization with properly configured email authentication.

But on final delivery, every authentication check failed. SPF=fail. DKIM=fail (body hash did not verify). DMARC=fail with action=quarantine. The message that started life as a fully authenticated Office 365 outbound email arrived looking like a spoofed forgery.

How a Security Gateway Became the Authentication Problem

The Received headers tell the story. The message originated from 52[.]101[.]85[.]138, an Office 365 outbound IP (mail-westus...outbound.protection.outlook.com). An earlier ARC (Authenticated Received Chain) set confirmed SPF pass, DKIM pass, and DMARC pass at that point in the relay.

The message then passed through a Barracuda email security gateway at 209[.]222[.]82[.]241 (outbound-ip77a.ess.barracuda.com). Barracuda is a legitimate email security vendor. Organizations deploy it to scan outbound and inbound mail for threats, rewrite URLs for safe-link protection, and insert banners.

The problem: when the gateway modified the message body (to insert link-protection wrappers, add a banner, or rewrite content), it invalidated the DKIM body hash. DKIM signatures cover the body content at the time of signing. Any alteration, even a single character, causes the hash to fail on verification. The final receiving server saw the modified body, computed the hash, and found it did not match the original DKIM signature.

SPF also failed because the final sending IP (209[.]222[.]82[.]241, the Barracuda gateway) was not listed in whiteandwilliams[.]com's SPF record. The SPF record authorized Office 365 IPs, not Barracuda relay IPs. With both SPF and DKIM failing, DMARC had no passing mechanism to align against, so it failed as well.

The authentication collapse is not the attack itself. It is the cover under which the attack operates. When security tools see SPF=fail, DKIM=fail, DMARC=fail on a message from a legitimate domain, they face a classification dilemma. Is this a spoofed message, or is it a legitimate email that was modified in transit? The ambiguity benefits the attacker.

Buried within the otherwise routine legal thread was a link to hxxps://subrogationstrategist[.]com/. The domain name was contextually plausible for a law firm that handles insurance subrogation claims. Automated link scanning flagged it as malicious. The domain served as the delivery vector for credential harvesting or malware, embedded inside a message that looked, read, and was structured like real attorney correspondence.

See Your Risk: Calculate how many threats your SEG is missing

This attack maps to MITRE ATT&CK T1566.002 (Phishing: Spearphishing Link) for the malicious link delivery, and T1586.002 (Compromise Accounts: Email Accounts) for the likely use of a compromised legitimate email account.

Behavioral Detection in an Authentication Void

When authentication fails across all three checks, content-based filters must rely entirely on other signals. Link scanning caught the malicious domain in this case, but the broader challenge is that gateway-induced authentication failures create persistent noise. Security teams operating in environments with Barracuda, Proofpoint, or similar inline gateways see legitimate emails failing authentication routinely. Over time, that erodes the signal value of DMARC failures.

Themis, our Adaptive AI, evaluated this message using behavioral signals that are independent of authentication state. The combination of a malicious URL verdict, the presence of link-protection rewriting (indicating the message was modified in transit), and the ARC chain showing initial pass followed by final failure created a risk profile that authentication alone could not resolve.

Community intelligence from across the platform tracked subrogationstrategist[.]com as it appeared in multiple campaigns targeting insurance and legal organizations. The domain name itself was a social-engineering choice: "subrogation strategist" is terminology that would appear natural to anyone in insurance claims, lowering the barrier to clicking.

Research shows that 67.5 phishing emails per 100 mailboxes per month bypass traditional secure email gateways. Gateway-induced authentication failures compound this problem by reducing the reliability of the signals those gateways are supposed to strengthen.

Implications for Organizations Using Inline Security Gateways

This case illustrates a tension in email security architecture. The security gateway that organizations deploy to protect their mail flow can, by modifying message content, break the authentication mechanisms that downstream recipients rely on.

Defenders should consider:

• ARC chain analysis. When final-hop authentication fails, check whether an earlier ARC set shows the message initially passed. ARC was designed to preserve authentication context across forwarding hops.
• DMARC policy alignment. Organizations with p=none policies should consider moving to p=quarantine or p=reject to reduce the window for spoofed messages. However, they must first ensure that their own outbound gateways are not breaking DKIM on legitimate mail.
• Link scanning independence. URL analysis should operate independently of authentication results. A malicious link is malicious regardless of whether the message that carries it passed or failed DMARC.
• Gateway audit. Organizations should periodically verify that their outbound security gateways are not modifying message bodies in ways that invalidate DKIM signatures. Some gateways offer DKIM-aware modes that apply changes before signing.

IOC Table