A SendGrid Phish, Signed by SendGrid, on a 15-Minute Domain

SPF passed. DKIM passed with a signing domain of sendgrid[.]net and the selector SendGrid uses for its own API traffic. The ARC chain arrived intact at the recipient's inbound relay, sealed and consistent with those results.

None of that was forged. The message genuinely transited SendGrid's outbound infrastructure and was genuinely signed by it.

The message was a fake SendGrid subscription renewal receipt.

That inversion is the whole case. The familiar shape of email service provider abuse is an attacker riding one company's authenticated channel to costume as an unrelated brand, and the tell is the gap between the domain that signed the mail and the brand a human reads in the sender alias. There was no such gap here. The impersonated brand and the sending infrastructure were the same company, so the comparison that catches the ordinary version of this attack returns a clean answer.

The Lure Domain Typosquatted the Sender

The message carried five links. Two pointed at the real sendgrid[.]com website under unsubscribe labels, and a click tracking wrapper plus a one pixel open beacon on the provider's own tracking hostname were genuine as well. Four of five were authentic vendor infrastructure.

The fifth was a button labelled as a receipt view, and it resolved to myconnsend-grid[.]com.

Read the string slowly. It is not a lookalike of a bank, a courier, or a document service. It spells the sending platform's own name inside a longer host, split across a hyphen so the substring survives a glance while the whole thing reads as some unremarkable connector service. Nothing about the registration stood out except when it happened.

One Header Field Could Not Have Existed

The From address on this message read noreply@sendgrid. No top level domain. No dot. That is not a domain that can resolve, and it is not a domain that can be registered.

It is also the only deterministic signal in the message. Authentication evaluates the envelope sender and the signing domain, not the display header a reader sees, so a syntactically impossible header From rode a valid DKIM signature and a sealed ARC chain to an executive inbox. Scoring that field needs no reputation lookup and no model. A string check is enough.

It also explains a quieter finding. The platform's brand impersonation flag never fired, because impersonation logic keys on a recognised brand asserted over an unrelated domain and the domain relationship here was real. A syntactic validity test on the same header would have failed it outright.

The Scan Verdict Was Clean

This part is easy to describe wrongly, so be precise.

The platform's automated URL scanner did visit myconnsend-grid[.]com, rendered the page, and captured a screenshot. Its recorded verdict was Clean.

There is no finding in the record that a credential form was caught sitting on that host. The reputation and content layer simply had nothing to say about it, and that is the point rather than a footnote. A domain created moments earlier has no blocklist entry, no crawl history, no passive DNS depth, and often no finished attacker content when a scanner looks. A clean verdict on infrastructure that new is an absence of evidence read as evidence of absence.

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

Fifteen Minutes and Forty Seconds

WHOIS puts the creation of that domain at 14:35:39 UTC. The Received header puts delivery at 14:51:19 UTC the same day, and the incident opened six seconds after that.

Fifteen minutes and forty seconds separated the two events.

Domain age is a control most tooling expresses in days, and the better implementations reach down to hours. Neither resolution helps here. A bucket boundary at one day, or even at one hour, files this domain alongside hosts that have had time to accumulate a history. The attacker never had to age or warm the infrastructure, because the only thing it had to survive was one lookup in the same quarter hour it was created.

The Copy Knew Nothing About the Account

The body was generic software billing language. A subscription had been successfully renewed, and a large round quota of monthly requests remained. No invoice number. No account identifier. No customer name. No amount.

Real transactional billing mail is dense with account specific detail, because that detail is the reason the message exists. A receipt that cannot name what was renewed is describing a relationship the sender does not have. The recipient was a president-level executive at a small organization, a single mailbox, and a first time sender for that tenant.

What Was Left to Detect With

Strip out everything that came back green and the remaining evidence is thin but coherent: a first time sender, billing copy with no account identity, a header From that cannot exist, a call to action on a hostname spelling a vendor brand inside itself, and a creation timestamp minutes old.

That combination is what caught it. Themis scored the message at 86% confidence and labelled it credential theft, drawing on phishing pattern language in the content, sender analysis, and community reputation signals from similar reports resolved in other environments. The incident was automatically resolved as phishing for the one affected mailbox. Reading intent out of content and sender behaviour, rather than out of provenance, is the specific job Adaptive AI is doing at that moment.

The 2026 Verizon Data Breach Investigations Report puts phishing at 16% of breach initial access vectors and credentials in 39% of breaches across the full kill chain, which is why credential harvesting remains the cheapest useful outcome an attacker can buy with a domain registration and a self serve sending account.

Controls for Infrastructure With No History

Measure domain age in minutes at delivery time, not in days, and treat a creation timestamp inside the same hour as the send as a standalone escalation trigger. Log that age next to the scan verdict so the two are always read together, because a clean result on a domain with no observable history is a null answer rather than a pass.

Validate the syntax of the header From independently of authentication. An address with no top level domain should never reach a mailbox, however the envelope authenticated. CISA phishing guidance makes the same argument for layered controls that do not lean on a single verdict, and the NIST definition of phishing is about deceiving a reader, which no signature can speak to.

Match hostnames against your own vendor brand list as substrings, not just whole labels. A brand spelled inside a longer host, split by a hyphen, is what that check is for. And require account specific detail before trusting billing mail: a renewal notice with no invoice number is reconnaissance grade no matter how well it authenticated.

Indicators of Compromise

MITRE ATT&CK Mapping

A hostile link inside an otherwise authentic vendor message is T1566.002, Phishing: Spearphishing Link, the click itself is T1204.001, User Execution: Malicious Link, and registering a brand adjacent domain minutes before use is T1583.001, Acquire Infrastructure: Domains.

The Bottom Line

Two independent green lights fired here and both were honest. Authentication was real because the provider really sent the mail. The scan verdict was clean because there was nothing yet to know about a domain fifteen minutes old. Neither control was broken, and neither was informative. What remained was a header address that could not exist, a receipt that could not name a purchase, and a hostname wearing the sender's own brand. Those are content questions, and content was the only layer still holding a signal.