Email link phishing: why your email app should always show the URL

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 January 2026, we saw exactly this attack vector exploited at scale through SendGrid, one of the world's largest email sending platforms. The campaign was effective, the authentication checks all passed, 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:

Case study: SendGrid phishing attack (January 2026)

In early January 2026, attackers launched a targeted phishing campaign that exploited SendGrid's infrastructure in a particularly clever way. Rather than attempting to spoof SendGrid or its customers, they 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 passed every authentication check. SPF aligned. DKIM signatures validated. DMARC policies passed. From an infrastructure perspective, these were legitimate SendGrid emails; they just happened to be sent by unauthorised users.

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 real service in real time. If the credentials work, the victim is forwarded to the genuine dashboard; if not, they are prompted to try again. Either way they never see the tell-tale failure of a dead phishing form, which is what makes the deception so convincing.

Why current mitigations failed

This attack bypassed nearly every common email security measure:

• Authentication passed: SPF, DKIM, and DMARC all validated because the emails genuinely came from SendGrid infrastructure
• Domain reputation intact: The compromised sender accounts had established sending histories
• Content filtering evasion: Politically themed content appeared legitimate and didn't trigger spam filters
• Trust exploitation: SendGrid branding combined with authenticated infrastructure created false confidence
• Link obfuscation: Display text showed benign purposes whilst URLs pointed to credential theft pages

For many users, manually inspecting the actual URL before clicking was one of the few visible client-side signals available, even though some organisations also had link rewriting, click-time scanning, or browser protections in play. On desktop, that inspection requires hovering over the link and reading the destination in the status bar. On mobile, it requires a long-press and careful inspection of the preview. All of it requires user awareness, deliberate action, and the technical knowledge to identify a suspicious domain.

For a detailed analysis of this attack, see Fred Benenson's case study.

Current phishing attack vectors

The SendGrid attack is part of a broader trend. Email phishing has evolved significantly, and attackers are exploiting gaps in both technology and human behaviour.

Display name spoofing

Email clients display sender names more prominently than email addresses. An attacker can set the display name to "Support" or "Human Resources" whilst the actual sender address is something entirely different. Microsoft identified a significant increase in these attacks throughout 2025, particularly via Phishing-as-a-Service platforms like Tycoon2FA^[1]. In March 2026, Microsoft, Europol, and industry partners disrupted 330 active domains associated with Tycoon2FA, yet campaign volume returned to pre-takedown levels within days, a reminder that disrupting phishing-as-a-service infrastructure buys only temporary relief^[8].

Users focus on the familiar display name and don't scrutinise the actual sender address. Email clients could mitigate this by displaying addresses more prominently or flagging mismatches between display names and sender domains, but most don't.

Internal domain spoofing

Misconfigured email routing and inadequate spoofing protections allow attackers to send messages that appear to come from internal addresses. These attacks often show the same sender and recipient address, or use internal display names that employees recognise and trust.

Protection requires strict DMARC reject policies, SPF hard fail configurations, and proper third-party connector settings, but many organisations haven't implemented these correctly, particularly those with MX records not pointed directly to their email provider.

Homograph and homoglyph attacks

Attackers register domains using visually similar characters from different character sets. The Cyrillic "а" (U+0430) looks identical to the Latin "a" (U+0061) in most fonts. A domain like "pаypal.com" (with a Cyrillic 'a') is indistinguishable from "paypal.com" to most users.

Browsers can mitigate this: many display risky domains in Punycode form (e.g., "xn--pypal-4ve.com"), but the behaviour is heuristic, policy-dependent, and varies between browsers, not a universal protection. Email clients and web content often display the Internationalised Domain Name (IDN) form directly, enabling the attack. Users see what appears to be a legitimate domain and have no reason to suspect otherwise.

Credential phishing surged 703% in the second half of 2024^[2], and the average breach cost reached $4.44 million^[3]. More recently, Microsoft detected 8.3 billion email-based phishing threats in the first quarter of 2026 alone, 78% of them link-based^[6], confirming that malicious links remain the dominant delivery mechanism. The sophistication and scale of these attacks continue to grow.

Legitimate service abuse

Beyond SendGrid, attackers have exploited Google Cloud's Application Integration service, Microsoft's legitimate email infrastructure, and numerous other trusted platforms. When the sending infrastructure is genuinely trusted and authenticated, traditional email security filters have nothing to flag. The attack surface has shifted from spoofing to compromise.

A clear example emerged in early 2026 with the abuse of Amazon Simple Email Service (SES). Attackers harvest leaked AWS access keys from public repositories, environment files, and container images, then use the compromised SES accounts to send phishing and business email compromise messages. Because the mail genuinely originates from Amazon's infrastructure, it passes SPF, DKIM, and DMARC, and even carries .amazonses.com in the Message-ID headers. The messages, often impersonating services like DocuSign, link to credential-harvesting sign-in pages hosted on amazonaws.com^[7]. It is the same pattern as the SendGrid case: compromise trusted infrastructure, then let authentication work in the attacker's favour.

Existing mitigation approaches

Email providers and security vendors have developed various mitigation strategies, each with its own strengths and limitations.

Link rewriting and click-time scanning

Services like Microsoft Defender Safe Links, Check Point Harmony Email, Sophos Email Security, and Symantec Email Security rewrite URLs in emails to redirect through a scanning service. When a user clicks the link, the service performs real-time checks against threat intelligence databases and malware analysis.

Strengths: Effective against known malicious URLs and domains. Provides time-of-click protection, catching threats that emerge after the email was delivered.

Limitations: May not work on S/MIME-signed or encrypted messages, since rewriting can break the signature. Organisations can allow-list tracking URLs to prevent rewriting, which can open security gaps. Rewritten URLs can expire^[4], breaking old email links. And it relies on centralised threat intelligence, which may miss zero-day or targeted attacks.

Hover-to-preview URL inspection

Desktop email clients display the actual URL in a status bar or tooltip when users hover over a link. Mobile clients offer similar functionality through long-press gestures.

Strengths: Allows technically aware users to verify destinations before clicking. No infrastructure changes required.

Limitations: Requires user awareness and deliberate action. Mobile interaction is less intuitive than desktop hover. Microsoft's "New Outlook" faced criticism in 2024 for inadequate URL preview functionality^[5], demonstrating that even established protections can vanish due to product decisions. Users must know what constitutes a suspicious URL, understand domain structures, and recognise homograph attacks.

As one user commented during the New Outlook controversy: "Seeing the true URL is the #1 way people can avoid getting email scammed." Yet this protection is entirely voluntary and depends on user behaviour.

Visual trust indicators

Some email clients implement visual cues to distinguish trusted from untrusted links. For example, trusted domains might appear with a white background and link icon, whilst untrusted domains get an orange background and warning icon.

Strengths: Passive protection requiring no user action. Visually distinct warnings can deter clicks.

Limitations: Relies on predefined trust lists. Doesn't address compromised accounts on trusted platforms (as in the SendGrid case). Trust indicators can create false confidence; users might trust any link without a warning, even if it's a targeted attack against an organisation's specific infrastructure.

The proposal: always show the URL

What if email clients simply displayed the actual URL alongside every link, regardless of the display text? No hover required. No manual inspection needed. Just always-visible destination URLs.

How it would work

Email rendering engines would modify how links appear:

<!-- The email contains an ordinary link -->
<a href="https://malicious-site.com/phishing">Click here to verify your account</a>

<!-- Current clients render only the link text: -->
[Click here to verify your account]

<!-- Proposed: the client injects the destination before the text -->
<a href="https://malicious-site.com/phishing">
  <span class="email-url-display">→ https://malicious-site.com/phishing</span>
  Click here to verify your account
</a>

<!-- ...so the user now sees: -->
→ https://malicious-site.com/phishing
[Click here to verify your account]

The domain (or full URL, depending on policy) would be displayed directly above the link text. No special user action or technical know-how is required. Just immediate, unavoidable visibility of where the link actually goes.

Visual mock-up: current vs proposed

Strengths of this approach

• Greatly reduces display-text mismatch: The specific deception that enabled the SendGrid campaign largely stops working once users can always see the actual destination
• No user action required: Unlike hover-to-preview, this is passive protection that doesn't rely on user awareness or behaviour
• Works on mobile: No long-press gestures or complex interactions needed
• Addresses homograph attacks: Suspicious domains become visible and can be inspected
• Implementable at presentation time: Browser extensions and mail-client plugins can post-process rendered content; first-party clients face more work (sanitisation, mobile UX, signed content, accessibility)
• Transport-agnostic: Applied when the message is rendered, without changing message transport, though signed or high-integrity mail flows still need careful UX design

Weaknesses and trade-offs

• Significant UX degradation: Emails become more cluttered and harder to read, particularly marketing emails with many links
• Breaks legitimate marketing campaigns: Tracking URLs (e.g., newsletter click tracking) look suspicious even when harmless
• Increases visual noise: Long URLs consume screen space and reduce readability
• May reduce click-through rates: Legitimate calls to action might see reduced engagement as users become overwhelmed by URL information
• Doesn't address account compromise: If an attacker controls a legitimate domain, the URL will appear trustworthy even when displayed
• User education still needed: Users must understand what constitutes a suspicious domain

Implementation approaches

Email clients could implement this in several ways:

• Full URL display: Show the complete URL for every link
• Domain-only display: Show just the domain, reducing clutter whilst preserving security benefit
• External link highlighting: Only display URLs for links pointing outside the sender's domain
• User preference setting: Allow users to opt in or out (though this reduces effectiveness for less technical users)

What it doesn't solve

Always showing the URL defeats display-text mismatch, but it is not a universal remedy. Two techniques rising sharply through 2026 sidestep it entirely:

• OAuth device-code phishing: In a campaign uncovered in late April 2026, Tycoon2FA operators abandoned fake login pages altogether. The victim is asked to enter a short code at the genuine microsoft.com/devicelogin page; Microsoft then handles authentication, including MFA, and unwittingly issues OAuth tokens to an attacker-controlled device^[9]. Displaying the URL reveals a legitimate Microsoft domain, so there is nothing suspicious to flag.
• QR-code phishing ("quishing"): The destination is embedded in an image rather than an anchor tag, so there is no link text or URL for the client to display at all. Microsoft recorded a 146% rise in QR-code phishing across the first quarter of 2026, from 7.6 million to 18.7 million messages^[6].

Both are variants of adversary-in-the-middle phishing, where the attacker relays a live authentication session and captures tokens rather than passwords. Always-visible URLs raise the bar against the most common attacks, but they reinforce rather than replace the need for layered defences.

Alternative strategies

Always showing URLs is one approach, but it's not the only possibility. Here are several alternatives, each with different trade-offs between security and usability.

Same-domain links only (verified senders)

Email clients could enforce a policy where authenticated senders can only include links to their own domain. If an email from bank.com is DMARC-authenticated, it can include links to bank.com but not to third-party domains.

Pros: Prevents direct links to obviously suspicious external domains. Maintains clean UX for internal communications. Leverages existing authentication infrastructure. May catch unsophisticated phishing attempts.

Cons: Doesn't prevent attacks using email platform tracking URLs (like SendGrid's click tracking) which redirect through trusted domains. Breaks legitimate use cases like newsletters linking to resources, partnership communications, content aggregation, and shared documents. Doesn't prevent subdomain takeover attacks. May encourage use of URL shorteners, defeating the purpose. Requires strict DMARC enforcement.

Feasibility: Medium. Technical implementation is straightforward, but policy enforcement creates significant usability problems.

Full URL display with click confirmation

Display the URL and require explicit confirmation before navigating. When a user clicks a link, show a dialogue: "You are about to visit https://example.com. Continue?"

Pros: Preserves link functionality with explicit user consent. Educational: it trains users to verify URLs. Can be configured with allowlists for trusted domains.

Cons: Click fatigue: users will auto-confirm without reading, just as they do with other security dialogues. Doubles interaction cost for every email link. Terrible mobile usability. Doesn't prevent sophisticated attacks because users don't carefully read confirmation dialogues.

Feasibility: High technically, but very low user acceptance. Confirmation fatigue makes this largely ineffective.

Graduated URL display policy

Implement configurable display modes allowing users to choose their security level:

Strict mode Security-focused users	Balanced mode Default recommended	Permissive mode UX-focused users
→ https://example.com/verify?token=abc123 [Verify account]	→ example.com (same domain) [Verify account] → external-site.com (different) [Click here]	(URL hidden, shown on hover) [Verify account]
Full URL always visible	Show domain for external links only	Current behaviour, manual inspection

Pros: Balances security and usability. Users can choose their preference. Organisations can enforce policies for different user groups. Balanced mode provides meaningful protection without overwhelming clutter.

Cons: Requires user awareness to configure appropriately. Less technical users may choose permissive mode and remain vulnerable. Complexity in implementation and user education.

Feasibility: Medium. Implementation is straightforward, but user configuration awareness and education are challenging.

Machine learning-based link risk scoring

Train ML models to assess link risk based on domain reputation, sender history, text/URL mismatch patterns, lexical analysis of domains, and historical click behaviour. Display risk scores or warnings only for suspicious links.

Pros: Automated detection without breaking legitimate use cases. Adapts to evolving attack patterns. Scales well across large organisations. Can combine multiple signals (sender reputation, domain age, text similarity, etc.).

Cons: False positives are a significant problem: legitimate links flagged as suspicious cause user fatigue and erode trust in the system. Users learn to ignore warnings, reducing effectiveness over time. False negatives create risk. Requires significant training data and ongoing tuning. Attackers can potentially learn to evade ML models. Complex implementation requiring ML infrastructure.

Feasibility: Medium. Large email providers have the data and resources, but false positive fatigue significantly limits real-world effectiveness.

Enhanced mobile hover UX

Improve mobile link preview functionality. Instead of requiring long-press, show a small domain badge beside every link. Tapping the link navigates; tapping the badge shows full URL details.

Pros: Improves mobile security without desktop impact. Provides immediate domain visibility. Preserves current UX whilst enhancing security.

Cons: Still requires user awareness and action. Adds visual complexity to link rendering. May be confusing for less technical users. Doesn't address desktop vulnerabilities.

Feasibility: High. Relatively simple client-side implementation with significant mobile security benefit.

Cryptographic link signing (DKIM for URLs)

What if links in emails could be cryptographically signed, similar to how DKIM signs email headers and body? A sender could sign each URL in their email, and the recipient's email client would verify these signatures before allowing navigation.

How it would work: A new DNS record type (e.g., EMLNK or _linkkey TXT record) would publish the public key for email link verification, similar to how DKIM uses _domainkey records. Crucially, this would be separate from DKIM: the DKIM signing keys reside on the mail server and shouldn't be accessible to email applications. The link signing keys would be managed by the organisation's email composing systems or email service provider.

When composing an email, the sending application would sign each URL using the domain's link-signing private key. These signatures could be embedded as a separate MIME part (e.g., application/link-signatures) or as data-signature attributes on anchor tags. The receiving email client would fetch the public key from DNS (e.g., _linkkey.example.com) and verify each signature before allowing navigation.

If a link's signature doesn't verify, because the URL was modified, injected, or the sender didn't actually include it, the email client could warn the user, disable the link, or display it differently.

Pros: Cryptographically proves link authenticity. Prevents link injection and modification attacks. Builds on existing DKIM infrastructure and key distribution. Works with encrypted emails. Doesn't require URL display changes. Could be implemented as an extension to existing email standards.

Cons: Requires new email standards and widespread adoption. Doesn't prevent attacks from compromised accounts (they can sign malicious links with valid keys). Implementation complexity for email clients and servers. Requires new DNS infrastructure and record types. Backwards compatibility challenges with existing emails. May break legitimate email forwarding and mailing list scenarios where content is modified.

Feasibility: Low to medium in the short term due to standardisation requirements, but potentially high long-term value. Would require IETF RFC development and adoption by major email providers.

Comparison of mitigation strategies

Strategy	Effectiveness	UX impact	Feasibility	User action
Always show URL	●●● High	●●● Significant	●● Build easy, adopt hard	None
Same-domain only	●● Medium	●●● Breaks workflows	●● Medium	None
Click confirmation	● Low	●●● Very high	●●● High	Every click
Graduated policy	●●● High	●● Configurable	●● Medium	Configuration
ML risk scoring	●● Medium	● Minimal	●● Complex	None
Cryptographic link signing	●●● High	● None	● Low (new standard)	None
Enhanced mobile UX	●● Medium	● Low	●●● High	Optional
Current (hover)	● Low	● None	●●● Exists	Manual

Adoption barriers and industry challenges

Even if always-show-URL or similar strategies prove technically effective, widespread adoption faces significant hurdles.

Marketing department resistance

Marketing teams rely heavily on link aesthetics and tracking. A "Click here to claim your offer" button is more appealing than "→ tracking.mailchimp.com/c/eJw... [Click here to claim your offer]". Email marketing metrics such as open rates, click-through rates, and conversion might decline if URLs are always visible, creating internal resistance to implementation.

Organisations must balance security against revenue impact. For many businesses, a 10% reduction in email conversion rates has direct bottom-line consequences. Security teams will need to demonstrate clear ROI or regulatory compliance benefits to overcome this resistance.

User experience concerns

Email is a communication medium, not just a security perimeter. Users value readability, clarity, and aesthetics. Always-visible URLs degrade the reading experience, particularly for newsletters, digests, and content-heavy emails. If users find emails harder to read, they may disengage entirely, reducing the value of email as a communication channel.

Design teams will push back against changes that make emails objectively uglier and less usable. Security improvements that significantly harm UX face uphill battles in user acceptance.

Industry coordination requirements

Email security depends on standards adopted across the industry. SPF, DKIM, and DMARC succeeded because major providers (Gmail, Outlook, Yahoo) all implemented and enforced them. A similar coordinated effort would be needed for URL display policies.

If only one email provider implements always-show-URL, users might simply switch to providers with better UX. Standards bodies (IETF, email client working groups) would need to develop specifications, and major providers would need to adopt them in roughly the same timeframe.

The backwards compatibility problem

Billions of existing emails contain links formatted for current rendering engines. Changing how links display retroactively affects archived emails, forwarded messages, and threaded conversations. This creates confusion when older emails suddenly render differently, or when users with different email clients see different link presentations in the same thread.

Conclusion and call to action

Email authentication standards have successfully addressed domain spoofing, but link-based phishing remains a critical vulnerability. The SendGrid attack demonstrates that compromised accounts on trusted platforms can bypass all authentication checks, leaving users with only manual URL inspection as defence.

Always displaying the link destination would greatly reduce display-text mismatch as a deception technique, though not phishing via trusted domains, QR codes, or OAuth device flows. It can be applied at presentation time, but it comes with real UX costs and faces substantial adoption barriers.

Perhaps the answer isn't a single solution. Defence in depth applies here too: graduated display policies give users choice, ML-based risk scoring provides automated detection, enhanced mobile UX improves inspection capabilities, and industry-wide standards could establish baseline protections.

What's clear is that doing nothing isn't viable. Phishing is growing in sophistication and scale: credential phishing jumped 703% in late 2024^[2], breach costs approach $4.5M^[3], and Microsoft logged 8.3 billion email phishing threats in a single quarter of 2026^[6]. The industry must act.

For email client developers: Consider implementing graduated URL display policies and enhanced mobile inspection UX. These provide security benefits with configurable UX impact.

For security teams: Evaluate ML-based link risk scoring and enforce strict link rewriting policies. Layer defences and don't rely solely on user behaviour.

For standards bodies: Initiate discussions on URL display standards and link safety protocols. Email security needs continued evolution.

For users: Enable link preview features, inspect URLs before clicking, and advocate for better security UX in your email clients.

The gap between authentication and link safety won't close itself. It's time for the industry to have this conversation.

References

1. Phishing actors exploit complex routing and misconfigurations to spoof domains. Microsoft Security Blog (January 2026). Microsoft Defender for Office 365 blocked over 13 million malicious emails linked to Tycoon2FA in October 2025.
2. SlashNext 2024 Phishing Intelligence Report (PRNewswire). Credential phishing attacks increased 703% in H2 2024.
3. IBM Cost of a Data Breach Report 2025. Global average breach cost: $4.44 million.
4. Complete Safe Links overview for Microsoft Defender for Office 365. Microsoft Learn. Documentation on Safe Links URL scanning and rewriting functionality, including limitations regarding URL expiration and one-time use links.
5. New Outlook not showing link URLs. Microsoft Tech Community. User discussions regarding missing URL hover preview functionality in New Outlook, raising security concerns about verifying links before clicking.
6. Email threat landscape: Q1 2026 trends and insights. Microsoft Security Blog (April 2026). 8.3 billion email-based phishing threats detected in Q1 2026, 78% of them link-based; QR-code phishing rose 146% over the quarter.
7. Phishing campaigns and BEC attacks through Amazon SES. Securelist (Kaspersky), 2026. Attackers abuse leaked AWS access keys to send fully authenticated phishing and BEC messages via Amazon SES, with credential-harvesting pages hosted on amazonaws.com.
8. Tycoon2FA phishing-as-a-service platform persists following takedown. CrowdStrike (March 2026). Microsoft, Europol, and partners disrupted 330 active Tycoon2FA domains on 4 March 2026, but campaign volume returned to pre-takedown levels within days.
9. Tycoon 2FA operators use OAuth device code phishing to bypass MFA. GBHackers (April 2026). Late-April 2026 campaign abusing microsoft.com/devicelogin to capture OAuth tokens without presenting a fake login page.