Perfect DKIM Alignment, Completely Unrelated Sender

The page wore the document title, house palette and footer block of a long-established American manufacturer of industrial measurement instruments. The domain that cryptographically signed the message belonged to a small South American internet service provider. Both things were true at once, and only one of them was visible to anything checking at the edge.

One mailbox took delivery: a manager in the audit practice of a mid-sized US accounting and advisory firm. The message reached Microsoft's edge in a single hop out of an Amazon SES region in Europe, with no gateway and no relay in the Received chain. SPF passed. Two DKIM signatures verified, one of them aligned exactly to the domain in the From header. Microsoft scored the mail at spam confidence level 1, filter verdict not spam, and delivered it carrying nothing but a first-contact safety banner.

The alignment was flawless. It was also worthless.

What The Alignment Actually Proved

Two valid signatures rode with the message. One covered the sending platform's own domain, routine for anything leaving that service. The other covered the domain in the From header, applied through the platform's managed signing feature under a selector published beneath that domain, and it verified cleanly. That is genuine DKIM alignment. Nothing was spoofed, and no lookalike domain was involved anywhere in this attack.

That domain belonged to a small South American internet service provider: a real operating business, registered years before the attack, with a named human contact at a street address and its national host's nameservers. It is a bystander here, which is why both the domain and the alias it sent from stay withheld. The convention of masking a local part while keeping the domain visible applies to genuinely attacker-owned infrastructure, and this is not that.

So the signature established that the mail really did leave an authorized sending identity for an internet service provider on another continent. It established nothing whatsoever about the manufacturer whose branding filled the body. Alignment tells you who owns the sending domain. It does not tell you who the brand on the page is, and no amount of cryptographic rigour will make it answer that second question.

The DMARC line offers no help either. It reads bestguesspass action=none, the value Microsoft records when the From domain gives it no policy to evaluate, so the receiver inferred an outcome from the SPF and DKIM results it already held. Publish a record for your own domains so nobody has to infer, watch what comes back through DMARC monitoring, and read that verdict on inbound mail as no record found rather than as a policy decision.

The Brand On The Page Belonged To Someone Else

The impersonation was purely visual and cost the attacker nothing to build. The footer pulled the manufacturer's logo live off the manufacturer's own website, straight out of its public media library. The company sent nothing, hosted nothing and was never compromised, and every link in the message pointing at its real site scanned clean. It is the third bystander in a case where no piece of named infrastructure belongs to the attacker.

The personalization was machine work. The greeting was the title-cased local part of the recipient's own mailbox address, and the party said to be assigning the document was the title-cased stem of the recipient's own domain. At a glance it reads as a system notice from a colleague. Read twice, it is the recipient's email address shredded into two fields.

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

Below the branding sat a document box showing a quarterly remittance-adjustment file name, a bare fiscal-year line, and a date several days after the message that delivered it. A remittance advice cannot be dated in its own future, which is a template generator giving itself away. There was also no file: the whole box was text painted inside the HTML body, and the attachment array in the record is empty. The subject line, meanwhile, ended in a forty-character hex token serving as a per-recipient tracking identifier.

A Link That Arrived Already Wrapped

The single actionable button carried the only real object in the message. Before Microsoft's own link protection touched it, that anchor's address was already a security vendor's URL-rewriter link wrapping a path on a small Brazilian company's website. The two decorative links to the manufacturer's real site were plain, unwrapped addresses.

Both DKIM signatures verified, so the body was not altered after signing, which places the wrapper in the content as sent rather than in anything the recipient's stack did. Beyond that, restraint is warranted. An attacker pasting a harvested wrapper to borrow a reputable string, and a policy-based outbound rewriter that wraps unfamiliar domains while skipping known ones, both produce exactly this pattern. The message never crossed that vendor's gateway, and no product failure is implied.

The landing host is a small Brazilian business site, online for well over a decade on shared hosting, with attacker content dropped on a subpath. Scanner verdicts on that path were mixed rather than a clean malicious confirmation, and a later look found it serving no kit at all and redirecting offsite to a mainstream social network's public signup page. That is a snapshot taken well after the send, not what the recipient would have seen, and no credential form was ever captured.

What Actually Flagged It

Nothing in the authentication or reputation layer objected, because nothing in that layer is built to compare a signing domain against a brand. What caught it was relationship data. The sender was new to the organization, with no prior correspondence in any direction, and the platform rated it high risk on that basis. Themis, our Adaptive AI, returned a confidence of 90 under labels for credential theft and VIP recipient, citing a link flagged as malicious. Those labels describe predicted intent, not an observed login page. The incident was raised by automated detection rather than a human reporter and closed as automatically resolved as phishing.

Both CISA phishing guidance and the NIST definition of phishing frame the threat as deception and elicited action rather than as files and signatures, which is the only framing that survives a case like this. The 2024 Verizon Data Breach Investigations Report found the human element present in 68 percent of breaches, and the 2023 FBI IC3 Internet Crime Report put reported business email compromise losses near $2.9 billion.

The operator came back the next day. Four more mailboxes at the same firm, spanning a second firm domain and including a shared firm-wide address, received a harder finance-specific lure. Each was mitigated a second or two after receipt.

What Alignment Can And Cannot Tell You

Verify the signature, then ask the question the signature cannot answer: which domain did it cover, and does that domain have any relationship to the brand, the document or the request on the page? A perfectly aligned signature from a party with no connection to the content is not authentication working. It is authentication being asked the wrong question and answering it correctly. The mismatch is the finding, and spotting it is a content and relationship judgement rather than a cryptographic one.

Indicators of Compromise

MITRE ATT&CK Mapping