The Renewal Notice for a Domain That Could Not Be Renewed

In late August 2026, a shared partnerships mailbox at a global digital advertising agency received a renewal reminder styled as a Squarespace domain invoice. Amount due: $12.47. Current status: pending payment. Deadline: the day after the mail arrived.

The message had exactly one personalized detail, and it was a good one. It did not name the company's corporate domain. It named a legacy domain the organization still owns but no longer uses for mail, and it asserted that this domain was hours from expiring. That is the detail that makes a recipient lean in, because a stranger guessing at a company's domains does not usually land on the dormant one.

It is also the detail that destroys the message. The named domain has a public registration record, and that record refutes three separate claims in the mail: the deadline, the requested action, and the identity of whoever supposedly sent it. None of that check requires cooperation from the sender, and none of it requires a security tool.

Refutation one: there was no deadline

The domain had been renewed months before the mail arrived and was paid up well into the following year. The expiry the notice asserted was not an approximation or a rounding error. It was fiction about a fact anyone can look up.

The claimed date being wrong is where analysis of a scam like this usually stops. Here it is the weakest of the three findings.

Refutation two: the demanded action was impossible

The domain carries a full set of client status locks in the registry: delete prohibited, transfer prohibited, update prohibited, and, decisively, renew prohibited. While a clientRenewProhibited status stands, the registry rejects a renew command for that domain.

Sit with what that means. The mail demanded an operation the registry would refuse. Not refuse from a stranger, refuse from anybody who owns it, until the lock is deliberately lifted. A renewal notice for a renew-locked domain is not a plausible request that happens to be fraudulent. It is a request nobody could have fulfilled, which is a stronger statement than any date comparison can make.

Registry status codes are free, public, and reported by every registration lookup. They are also almost never read.

Refutation three: the implied employer is wrong

The domain is held at a registrar with no relationship to the brand in the message. Renewal billing comes from the registrar of record, so a genuine notice for this domain could not have carried this brand at all. That one field, with no expiry arithmetic at all, disqualifies the sender's implied identity.

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

How the message was built

The brand existed only in fields the sender controls for free. The display name and the Organization header both rendered the brand in mathematical sans-serif bold codepoints. The footer pasted the brand's genuine New York and Dublin postal addresses above six navigation links whose destinations were dead stubs, and the in-body support links were dead too. There was no logo anywhere; an empty anchor sat in the header cell where one would go, next to the letter-spaced word domains and a thin red rule. The salutation was a generic greeting to a customer.

A hidden preheader block repeated the invoice number and the trivial amount, and the headers asserted urgent priority. The small sum is part of the design: $12.47 sits below the threshold at which most people escalate anything.

The sending domain was registered roughly four and a half months before this post, publishes its own SPF record and a default DKIM selector, and enforces a reject policy. So SPF, DKIM and DMARC all passed at the single inbound hop, aligned to the sender's own domain. There was no gateway and no rewriter in the chain, so none of the usual pass-then-fail artifacts apply. This mail authenticated, and DMARC said nothing whatsoever about the impersonated brand, which never appeared in an authenticated identifier. Replies were steered to a mailbox at an unrelated small retailer. Submission came through the attacker's own Exim instance on a rented managed VPS.

The single call to action, labelled Renew Domain, pointed at a Google-owned shortlink rather than any brand URL. One note for the mechanics: the shortlink and the address it resolved to were verdicted separately inside the same incident, Clean for the shortener and Malicious for the destination behind it, which is a reminder that a verdict on a redirector is a verdict on the redirector. That destination was a host built on the exact brand string under a different top-level domain, registered about five months before this post. Its content was never observed, because the attacker's own bot protection returned a block page to the scanner instead of the page. Treat it as a page the scanner was never allowed to see, not as an observed login form.

Our Adaptive AI resolved the incident automatically at 90% confidence with the label Credential Theft, driven by reputation on the resolved destination plus language, structure and community signals. Notably, the platform's structural impersonation flag read false, even though brand impersonation was the entire premise. That is what happens when a brand lives in a display name and a pasted address block rather than in a lookalike sending domain: there is no identifier to compare. The catch came from the destination, not the costume. Google Workspace tenants can close that gap with layered detection on top of native filtering, and our Adaptive AI scores intent rather than waiting for a brand string to match.

The lesson: your own assets are checkable from outside

The tradecraft here is ordinary. The interesting property is epistemic. When an attacker personalizes a lure with a claim about your property, that claim enters the jurisdiction of the public record, and the more specific the personalization, the more checkable it becomes. A domain has an expiry, a registrar of record, and a set of status codes, all published, all free, none of which the sender can influence.

The 2026 Verizon Data Breach Investigations Report puts phishing at 16% of initial access vectors and pretexting at 6%, and finds the human element in 62% of breaches. Pretexting works because the recipient cannot audit the sender. That asymmetry inverts the moment the pretext makes a factual claim about something the recipient owns. CISA's guidance on stopping the attack cycle and NIST's definition of phishing both frame these messages as attempts to induce action under false premises; verifying the premise, rather than the sender, is the shortest path when the premise is a matter of public record. DMARC alignment rules, now specified in RFC 9989, tell you which domain authenticated, not which brand was invoked.

So add a step for renewal, suspension and expiry mail: look up the asset. Expiry, registrar, status codes. Ten seconds, no ticket, no sender required. If the record contradicts the mail, you are finished, and you have not clicked anything.

Indicators of Compromise

MITRE ATT&CK mapping