Namecheap/SendGrid Hijack: Phishing With Perfect DMARC

Quick Answer — On February 27, 2023, customers of Namecheap — one of the world’s largest domain registrars — started receiving Metamask/DHL-themed phishing emails sent through Namecheap’s own legitimate SendGrid account. An attacker had compromised an employee account at a SendGrid supplier, then pivoted into the mail pipeline Namecheap (and others) trusted. The emails passed SPF, DKIM, and DMARC because they genuinely came from authorized infrastructure. The lesson: email authentication proves the sender’s pipeline, not the sender’s intent — your vendors’ vendors are your phishing surface.

What happened

• The send: Starting ~UTC morning Feb 27, phishing mail themed around MetaMask wallet “verification” (plus some DHL and other brands in the wider campaign) went out with valid SendGrid headers under domains recipients already trusted.
• The root cause chain: Per Twilio/SendGrid’s statements, an attacker compromised an employee account at a.SendGrid supplier/subcontractor, gaining access to a set of customer accounts — including Namecheap’s — and abused the managed-service mail path.
• Why mail auth didn’t help: The mail was signed and aligned: a legitimate ESP with legitimate routing and authorized API usage. DMARC has no opinion on whether the authorized user is actually a hijacker upstream.
• Scope: Beyond Namecheap, reports surfaced of similar sends tied to other SendGrid-using brands the same week; the blast was punctuated by waves and pauses as SendGrid killed the access.

Why ESP compromise defeats mail authentication

The attack pattern

• Target an ESP’s own supply chain (a supplier/subcontractor employee), not the customer brand — inherit trust wholesale instead of forging it.
• Pick customer accounts with broad legitimate send volume (registrars, SaaS) so the malicious blast blends into normal flow.
• Theme lures for crypto-wallet urgency (MetaMask verifications were hot that season) to monetize fast before revocation.
• Ride the vicarious-trust halo: security training teaches “check for the lock, check the domain”; here the domain was right and the content almost right.

Timeline

Defensive lessons

• Contract for blast-radius controls. ESP accounts need per-sender IP separation, send-volume anomalies alerted, and instant-revoke runbooks — agreed with the vendor before the incident, not during.
• Train for content anomalies, not just header anomalies. “Looks like a legit domain” is no longer evidence of safety when the pipeline itself can be hijacked; teach recipients to treat urgency + embedded links as the signal.
• Reduce single-vendor mail dependency. Splitting transactional and marketing sends across providers (or dedicated subdomains) caps how much “your” reputation one compromise can torch.
• Monitor your own mailstreams from outside. Brands that caught this fastest saw their own transactional templates being abused via honeypot inboxes and threat-intel feeds — not vendor notifications.
• Vendors: segment employee access by customer blast radius. One supplier-side credential shouldn’t reach a top-ten customer’s send path; least-privilege applies to the mail pipeline too.

Why it still matters in 2026

This incident codified vicarious trust abuse as a first-class phishing vector: subsequent years brought hijacked verified business accounts, compromised marketing automation, and AI-personalized sends riding legit pipelines. In 2026, mail authentication (DMARC, BIMI’s shiny checkmarks included) is table stakes that verifies infrastructure identity, while the actual arms race has moved to behavioral and content-layer detection — anomaly models on send patterns, link-graph analysis, and user education rebuilt around “the sender can be the victim.” The Namecheap/SendGrid case remains the clean teaching example: every header said yes, and every header was honest. Only the intent was false.

Did any recipient protection work?

Partially. Mail providers’ content-level filtering and recipient skepticism caught many samples, and the crypto-lure landing pages were taken down quickly. But the incident proved the ceiling: authentication-based trust had zero defensive value, and reputation systems initially scored the mail as genuine. Protections that fired were the ones modeling what was sent and how abruptly, not who sent it.

Why was a registrar’s mail account such a target?

Scale plus trust: registrars email customers about domains, renewals, and DNS — topics with built-in urgency and authority. A phisher inheriting that channel inherits millions of primed recipients, many of them non-technical. It’s the same logic as targeting a password-reset pipeline: own the channel people are trained to obey.

Was Namecheap itself hacked?

No — and that’s the point. Namecheap’s own systems weren’t breached; its email service provider’s supplier chain was. Per statements, the compromise lived upstream at SendGrid/supplier level, which is why the failure felt invisible to both Namecheap and its customers until the mail started arriving. The case is a required citation in any serious third-party risk program for exactly that reason.

Part of the hmmnm.com security-timeline series — one event per month, 2021–2024, indexed here.

Detection and response playbook

The Namecheap/SendGrid hijack (February 2023) delivered phishing emails with perfect DMARC — because they were sent through a legitimately compromised email-service-provider account. When the sender is authenticated by design, the entire email-trust stack becomes the attack surface.

1. Monitor ESP and marketing-platform accounts like privileged identity. These platforms hold the ability to send authenticated mail as your domain to your entire customer list. MFA, session monitoring, and least-privilege API keys apply with full force — a compromised ESP token is a phishing license stamped by your own domain.
2. Detect anomalous campaign behavior inside the platform. The hijack signals were visible to the provider: new API usage patterns, unusual send volumes, geographic anomalies in administrative sessions. ESP and marketing platforms need the same behavioral baselines as any identity system — applied to the sending identity, not just the login.
3. Stop treating DMARC pass as a safety signal at the recipient side. Authentication proves the sender is authorized by the domain — nothing about the sender intent. Recipient defenses that weight reputation, content, and behavior above authentication survive ESP-compromise campaigns; defenses that treat DMARC as the finish line do not. User education should say exactly this: authenticated mail can still be hostile.
4. Prepare the provider-coordination channel. Victims of ESP-compromise phishing needed the provider to kill the campaign mid-flight — and the clock ran in minutes. Know your providers abuse and security contacts, have your own kill-switch (revoke API keys, pause sending) rehearsed, and monitor your own domain feedback loops so you learn of abuse from bounces and reports before customers report it.
5. Rotate ESP credentials on compromise, and audit standing grants quarterly. API keys accumulate in marketing stacks like credentials accumulate everywhere else. The incident path — infostealer or account takeover at provider level — is closed by the same hygiene: scoped keys, rotation, and no immortal integrations.

Where this sits in the broader pattern

ESP compromise is a recurring genre: the 2019-2021 wave of marketing-platform account takeovers, the AnyDesk-style credential chains reaching SaaS consoles, and later incidents where verified enterprise accounts delivered convincing lures. The genre exists because email authentication succeeded — DMARC closed the spoofing door, so attackers moved to compromising the authenticated senders themselves, converting the trust infrastructure into the delivery mechanism.

The irony is structural and worth internalizing: every hardening of one layer criminalizes compromise of the next. SPF and DKIM made domain spoofing hard; ESP takeover made it unnecessary. The same escalation runs through this series — phishing-resistant MFA moved attackers to session theft and consent phishing; hardened endpoints moved them to credential markets. Defense shifts the attack; it rarely eliminates it.

The consolidation for both senders and recipients: treat the mail platform as critical identity infrastructure, monitor it like you monitor your SSO, and never let an authentication result substitute for judgment about content and behavior.

The bottom line. The phish passed every authentication check because it was real mail from a really compromised sender. Lock down ESP and marketing platforms like the domain-wide phishing licenses they are, monitor sending behavior not just logins, and teach recipients that DMARC proves authorization, not honesty. The trust stack authenticates senders; it has never authenticated intent.

And for the recipient side, the discipline is permanent: authentication status is one input among several, never a verdict. The organizations that survived this campaign un-phished were those whose users had been taught to evaluate requests, not headers.

The sending-side summary fits on one line: treat every platform that can email your customers as a domain-wide phishing license, and govern it accordingly — MFA, scoped keys, behavioral monitoring, and a rehearsed kill switch. That sentence, implemented, is the entire incident retrospectively prevented.

Implement the sentence, and this incident becomes history you read rather than history you repeat.

History read is cheaper than history repeated — by roughly a factor of everything.

Cheaper by every measure that finance can name, and by several it cannot.

Frequently Asked Questions

{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”What was the Namecheap SendGrid phishing incident?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”In February 2023, attackers compromised a SendGrid account related to Namecheap email marketing, sending phishing emails — including crypto lures — that passed DMARC authentication because they genuinely originated from the authorized ESP.”}},{“@type”:”Question”,”name”:”Why did the phishing emails pass DMARC?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Because email authentication verifies that the sender is authorized by the domain, and the attacker was operating inside a legitimately authorized account. DMARC proves authorization, not sender honesty — a limitation intrinsic to the design.”}},{“@type”:”Question”,”name”:”How do you defend against emails from compromised legitimate senders?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Weight behavioral and content analysis above authentication results, monitor and lock down your own ESP and marketing accounts with MFA and scoped keys, and maintain rapid kill-switch and provider-abuse coordination for your sending infrastructure.”}}]}

Related Reading

• What Studying 33 Historic Cyberattacks Taught Me About Defending Systems Today
• Passwordless in 2026: Why Passkeys Are Finally Killing the Password (and How Attackers Are Adapting)
• 2022–2024: Lapsus$, Change Healthcare & the XZ Backdoor
• Authoritative reference: CISA Known Exploited Vulnerabilities

More on this topic

• Twitch Leak: 125GB of Source Code and Payouts on 4chan
• GTA VI Leak: When Your Slack Workspace Is the Vault
• Magecart’s 2024 Resurgence: Skimming in the Polyfill.io Aftermat

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy