PHP Freelancer | Email link phishing: why your email app should always show the URL
Home
My work
Selling a house
Laravel
Magento
Python
WordPress
Testimonials
About me
My CV
Blog
Quote
Contact
Blog
Email link phishing: why your email app should always show the URL
Posted on Friday, June 5th, 2026 by Jeroen Derks
Posted on Friday, June 5th, 2026 by Jeroen Derks.
TL;DR: Email authentication (SPF, DKIM, DMARC) reduces domain spoofing but not link-based phishing sent through compromised or trusted accounts. Always displaying the link destination would greatly reduce display-text mismatch as a deception technique, though at a UX cost and without stopping phishing via trusted domains, QR codes, or device-code flows. Consider graduated display policies as a middle ground.
Update (7 July 2026): A practical solution became available on 7 July 2026. See Reveal URLs, a browser extension that shows each link's real destination directly above the link so you can spot phishing mismatches before you click.
We've made tremendous progress in email security. SPF, DKIM, and DMARC have significantly reduced domain spoofing when correctly deployed. When an email passes those checks, it most likely passed through the claimed domain's infrastructure, rather than a spoofed sender. That is a real advance, but it is a narrow guarantee.
But there's a gap. A significant one. Authentication standards verify who sent the email, not where the links go. An attacker doesn't need to spoof your bank's domain if they can compromise a legitimate account on a trusted platform and send you a perfectly authenticated email containing a malicious link. The authentication passes. The link is the trap.
In early 2026, reports described phishing campaigns abusing compromised accounts on SendGrid, one of the world's largest email sending platforms. The messages were delivered through legitimate SendGrid infrastructure, which allowed them to appear authenticated, and users were often left relying on one of the few visible client-side defences: manually inspecting link URLs. This article examines why this happened, why current mitigations fall short, and proposes a radical solution:
Always show the URL.
Contents
Case study: SendGrid phishing attack (January 2026)
Case study: the Booking.com lookalike-link attack (2025)
Current phishing attack vectors
Existing mitigation approaches
The proposal: always show the URL
Alternative strategies
Adoption barriers and industry challenges
Conclusion and call to action
References
Case study: SendGrid phishing attack (January 2026)
In early January 2026, reports described a targeted phishing campaign that abused SendGrid's infrastructure in a particularly clever way. Rather than attempting to spoof SendGrid or its customers, the attackers reportedly compromised real SendGrid customer accounts through credential stuffing and password reuse. Once inside, they used SendGrid's legitimate sending capability to distribute phishing emails.
The compromised accounts belonged to real businesses: drummond.com, nellions.co.ke, theraoffice.com. These were established domains with sending history and reputation. When the phishing emails arrived, they were delivered through legitimate SendGrid infrastructure, which allowed them to appear authenticated: SPF, DKIM and DMARC align for mail genuinely sent through SendGrid. From an infrastructure perspective, these were legitimate SendGrid emails; they just happened to be sent by unauthorised users.
Attacker<br>credential stuffing<br>/ password reuse
Compromised<br>SendGrid account
Phishing email<br>appears authenticated<br>SPF · DKIM · DMARC ✓
Recipient opens<br>and clicks link
Fake login page<br>credentials<br>stolen
Every step rides on legitimate, authenticated infrastructure; only the final link points somewhere malicious.
The social engineering vector
What made this campaign particularly effective was the social engineering. Rather than the usual "your account has been suspended" alert, the emails reportedly posed as SendGrid announcing controversial policy changes, deliberately framed around emotionally charged, divisive themes designed to provoke a strong, indignant reaction.
The goal was to make recipients react before they thought, clicking "opt out" or "manage preferences" without pausing to verify the URL. It marks a notable shift in tactic: a lure engineered for outrage rather than fear or curiosity, because a reader responding emotionally is less likely to scrutinise where a link actually goes.
The link disguise mechanism
The phishing emails included action buttons labelled as preference management or account recovery options. The display text read "Manage your preferences" or "Update account settings". But the actual URLs pointed to credential harvesting pages designed to look like SendGrid's login interface.
This kind of campaign can rely on a known adversary-in-the-middle technique: the fake login page validates entered credentials against the...