A DKIM Signature That Pointed at No Key

The authentication line read dkim=permerror (no key for signature), and in most triage queues that phrase means one thing: the sending domain's DNS is broken, which is somebody else's problem. It was not broken. The domain named in that signature publishes a healthy 2048-bit RSA key under its default selector, and it answered a direct query without hesitation. The message had simply been signed under a different name, a sixteen-digit numeric selector, and nothing anywhere in DNS answers to that name.

Verification never reached the cryptography. It died at key lookup.

The message itself was a Japanese-language parcel redelivery notice, displaying the corporate name of a major national courier over a mailbox at an unrelated real Japanese company, delivered to a shared corporate intake mailbox with no individual owner, on Google Workspace.

Fail and Permerror Are Not the Same Verdict

The distinction is load-bearing and it is routinely collapsed.

A DKIM fail means the receiver successfully fetched a public key from the selector's DNS record, ran the signature against it, and the math did not agree. That is a strong signal: either something rewrote the message in transit, or someone forged a signature using a key they do not control.

A permerror means the evaluation could not be completed at all. It can be a malformed signature header, an unparseable key record, or, as here, no key record whatsoever. The receiver was handed a signature and a place to go look, went there, and found nothing.

Both land in the same "DKIM didn't work" bucket in most triage workflows, and permerror gets the gentler read of the two. Nobody escalates a configuration problem at somebody else's registrar.

The Domain's Real Key Was Sitting Right There

A direct DNS query settles which read this one deserved.

Query the standard default selector's key record at the spoofed domain and you get back a live v=DKIM1; k=rsa; p=... record carrying a 2048-bit public key. Query the record for the sixteen-digit selector the message actually claimed, and you get no TXT record at all, just an authority section. The apex domain runs DKIM competently. The selector in this signature has never existed.

Why does an attacker bother signing at all? Two reasons, neither requiring the signature to verify. A message carrying a DKIM-Signature header looks structurally complete in a way a bare forged From header does not, and plenty of tooling reads the presence of a signature as evidence of a legitimate sending platform. And the failure it produces is the softest one available: forge with a real selector and no private key and you get a hard fail, invent a selector and you get permerror.

Worth noting on the record: the DKIM body hash and the ARC body hash matched exactly, so the body was untouched in transit. The signature was not broken. It was unverifiable by construction.

Nothing Was Left to Enforce

The spoofed domain's SPF record ends in ~all, so the injecting host produced a softfail rather than a hard fail. That host has no reverse DNS record, appears nowhere in the domain's SPF record, is not a recognized mail gateway, and geolocates outside Japan, while the Received header shows it announcing the spoofed domain's own name at HELO. WHOIS shows a real business registered in late 2018 on mainstream Japanese hosting, with intact records. This is external spoofing of an innocent bystander company, not a vendor compromise.

The gap that mattered is what the domain does not publish. There is no DMARC record for it at all. With no policy asking the receiver to do anything on failure, an SPF softfail and a DKIM permerror are two pieces of recorded telemetry and zero enforcement actions. DMARC is the layer that turns those results into a decision, and continuous DMARC monitoring is how an organization learns its own name is being used this way. Google's ARC seal recorded both failures faithfully and carried them forward rather than laundering them.

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

The Prose Was Japanese, the Font Stack Was Not

The body was good work. Natural, grammatically clean Japanese. A plausible multi-segment tracking number. A delivery attempt dated the previous day, a four-hour delivery window, a stated parcel type, an offer of a leave-in-place option, and a deadline warning that the parcel would be returned to sender within two days. The footer even carried the courier's genuine head-office address.

The tell was in the markup rather than the writing. The body tag specified a Simplified Chinese font family, which is not what a Japanese sender writing to Japanese recipients would ever set, and the generator string identified an Internet Explorer 11-era HTML editor from roughly a decade ago. Attackers localize copy far more carefully than they localize templates.

Three separate headers requested read receipts, all pointing back at the spoofed mailbox. Any client honoring one silently confirms the address is live and monitored, which makes even a non-click a small win for the sender.

A Consumer Lure in a Mailbox That Receives No Parcels

Here is the part no header check can produce.

The recipient was a shared corporate intake mailbox with no individual owner. It is not a person. It does not order anything, and no courier has ever had a parcel for it. A missed-delivery notice arriving there is not a suspicious message so much as an impossible one, and that contextual impossibility is exactly the signal an authentication-first pipeline throws away, because the headers had already produced a permerror and a softfail that resolved to no action.

The URL scanner did not rescue this either: it returned only a partial verdict on the single call to action and captured no screenshot. What carried the detection was Themis, our Adaptive AI, at 88% confidence with a credential-theft label, weighing the flagged link against language and structure analysis of the body and against community reputation matching from previously reported phishing across 35,000+ security professionals in 17,000+ organizations. The incident auto-resolved as phishing with one mailbox affected, and no mitigation action was recorded against that mailbox.

The 2024 Verizon Data Breach Investigations Report puts the median time from opening a phishing email to clicking a link at 21 seconds, with phishing present in 15% of breaches and stolen credentials in 38%. Twenty-one seconds is not enough time to query a selector's key record. The pipeline has to do it.

MITRE ATT&CK Mapping

Indicators of Compromise

Where to Put the Controls

Three things to take from this. First, treat permerror as unresolved rather than benign, and make the follow-up query automatic: if the selector named in a signature has no key record while the domain publishes a working one elsewhere, that is not a misconfiguration, it is a fabricated signature. CISA's phishing guidance is blunt about not treating partial authentication results as clearance, and NIST's definition of phishing has always centered on the deception rather than the transport.

Second, publish and monitor a DMARC policy for every domain you own, including the ones that never send. The spoofed company here did most things right and still handed an attacker a free softfail, purely because it had no policy for a receiver to act on.

Third, score the pretext against the mailbox. Consumer-shaped lures aimed at functional aliases are a category, not a coincidence, and the same pretexting logic drives the business email compromise losses of roughly $2.9 billion reported in the 2023 FBI IC3 Internet Crime Report. A parcel notice sent to a mailbox that cannot receive parcels should never have needed a signature check at all.