E-maillink-phishing: waarom je mailprogramma altijd de URL zou moeten tonen

Op het gebied van e-mailbeveiliging hebben we enorme stappen gezet. SPF, DKIM en DMARC hebben domain spoofing aanzienlijk teruggedrongen wanneer ze correct zijn ingericht. Als een e-mail die controles doorstaat, is de kans groot dat hij via de infrastructuur van het opgegeven domein is verstuurd, in plaats van door een vervalste afzender. Dat is een echte verbetering, maar wel een beperkte garantie.

Maar er is een gat. Een aanzienlijk gat. Authenticatiestandaarden controleren wie de e-mail heeft verstuurd, niet waar de links naartoe leiden. Een aanvaller hoeft het domein van je bank niet te spoofen als hij een legitiem account op een vertrouwd platform kan compromitteren en je een perfect geauthenticeerde e-mail kan sturen met daarin een kwaadaardige link. De authenticatie klopt. De link is de valstrik.

In januari 2026 zagen we precies deze aanvalsvector grootschalig terug bij SendGrid, een van de grootste e-mailverzendplatforms ter wereld. De campagne was effectief, alle authenticatiecontroles slaagden, en gebruikers waren vaak aangewezen op een van de weinige zichtbare verdedigingen aan de clientzijde: het handmatig inspecteren van link-URL's. Dit artikel laat zien waarom dit gebeurde, waarom de huidige maatregelen tekortschieten, en stelt een radicale oplossing voor:

Casestudy: SendGrid-phishingaanval (januari 2026)

Begin januari 2026 lanceerden aanvallers een gerichte phishingcampagne die op een bijzonder slimme manier misbruik maakte van de infrastructuur van SendGrid. In plaats van te proberen SendGrid of zijn klanten te spoofen, compromitteerden zij echte SendGrid-klantaccounts via credential stuffing en hergebruik van wachtwoorden. Eenmaal binnen gebruikten zij de legitieme verzendcapaciteit van SendGrid om phishing-e-mails te verspreiden.

De gecompromitteerde accounts behoorden toe aan echte bedrijven: drummond.com, nellions.co.ke, theraoffice.com. Dit waren gevestigde domeinen met een verzendgeschiedenis en reputatie. Toen de phishing-e-mails binnenkwamen, doorstonden ze elke authenticatiecontrole. SPF kwam overeen. DKIM-handtekeningen werden gevalideerd. DMARC-beleidsregels slaagden. Vanuit infrastructuuroogpunt waren dit legitieme SendGrid-e-mails; ze werden alleen toevallig verstuurd door onbevoegde gebruikers.

De social-engineeringvector

Wat deze campagne bijzonder effectief maakte, was de social engineering. In plaats van de gebruikelijke melding "uw account is opgeschort", deden de e-mails zich naar verluidt voor als SendGrid die controversiële beleidswijzigingen aankondigde, doelbewust ingekleed rond emotioneel geladen, verdeeldheid zaaiende thema's die bedoeld waren om een sterke, verontwaardigde reactie uit te lokken.

Het doel was om ontvangers te laten reageren voordat ze nadachten, door op "afmelden" of "voorkeuren beheren" te klikken zonder even stil te staan bij het verifiëren van de URL. Het markeert een opmerkelijke verschuiving in tactiek: een lokmiddel ontworpen voor verontwaardiging in plaats van angst of nieuwsgierigheid, omdat een lezer die emotioneel reageert minder geneigd is om kritisch te bekijken waar een link daadwerkelijk naartoe gaat.

Het mechanisme van de linkverhulling

De phishing-e-mails bevatten actieknoppen die werden gelabeld als opties voor voorkeursbeheer of accountherstel. De weergegeven tekst luidde "Beheer uw voorkeuren" of "Werk accountinstellingen bij". Maar de daadwerkelijke URL's wezen naar pagina's voor het oogsten van inloggegevens, ontworpen om eruit te zien als de inloginterface van SendGrid.

Dit soort campagnes kan steunen op een bekende adversary-in-the-middle-techniek: de nep-inlogpagina valideert de ingevoerde inloggegevens in realtime bij de echte dienst. Als de inloggegevens werken, wordt het slachtoffer doorgestuurd naar het echte dashboard; zo niet, dan wordt hem gevraagd het opnieuw te proberen. Hoe dan ook zien zij nooit de veelzeggende mislukking van een dood phishingformulier, en juist dat maakt de misleiding zo overtuigend.

Waarom de huidige mitigaties faalden

Deze aanval omzeilde vrijwel elke gangbare e-mailbeveiligingsmaatregel:

• Authenticatie slaagde: SPF, DKIM en DMARC werden allemaal gevalideerd omdat de e-mails daadwerkelijk afkomstig waren van SendGrid-infrastructuur
• Domeinreputatie intact: De gecompromitteerde afzenderaccounts hadden een gevestigde verzendgeschiedenis
• Ontwijking van contentfiltering: Politiek getinte inhoud leek legitiem en activeerde geen spamfilters
• Misbruik van vertrouwen: SendGrid-branding gecombineerd met geauthenticeerde infrastructuur wekte een vals gevoel van vertrouwen
• Linkverhulling: De weergegeven tekst toonde onschuldige doeleinden, terwijl de URL's naar pagina's voor diefstal van inloggegevens wezen

Voor veel gebruikers was het handmatig inspecteren van de daadwerkelijke URL vóór het klikken een van de weinige zichtbare signalen aan de clientzijde, ook al hadden sommige organisaties daarnaast linkherschrijving, scanning op het klikmoment of browserbescherming in werking. Op de desktop vereist die inspectie dat je met de muis over de link beweegt en de bestemming in de statusbalk leest. Op mobiel vereist het een lange druk en een zorgvuldige inspectie van de voorvertoning. Daarvoor zijn gebruikersbewustzijn, gericht handelen en voldoende technische kennis nodig om een verdacht domein te herkennen.

Voor een gedetailleerde analyse van deze aanval, zie de casestudy van Fred Benenson.

Huidige phishing-aanvalsvectoren

De SendGrid-aanval past in een bredere trend. E-mailphishing is sterk geëvolueerd, en aanvallers buiten gaten uit in zowel technologie als menselijk gedrag.

Spoofing van weergavenaam

E-mailprogramma's tonen afzendernamen prominenter dan e-mailadressen. Een aanvaller kan de weergavenaam instellen op "Support" of "Human Resources" terwijl het daadwerkelijke afzenderadres iets heel anders is. Microsoft constateerde gedurende heel 2025 een aanzienlijke toename van deze aanvallen, met name via Phishing-as-a-Service-platforms zoals Tycoon2FA^[1]. In maart 2026 ontmantelden Microsoft, Europol en partners uit de sector 330 actieve domeinen die met Tycoon2FA in verband werden gebracht, maar het campagnevolume keerde binnen enkele dagen terug naar het niveau van vóór de takedown, een herinnering dat het verstoren van phishing-as-a-service-infrastructuur slechts tijdelijke verlichting koopt^[8].

Gebruikers richten zich op de vertrouwde weergavenaam en bekijken het daadwerkelijke afzenderadres niet kritisch. E-mailprogramma's zouden dit kunnen verzachten door adressen prominenter te tonen of door discrepanties tussen weergavenamen en afzenderdomeinen te markeren, maar de meeste doen dat niet.

Spoofing van interne domeinen

Verkeerd geconfigureerde e-mailroutering en ontoereikende beschermingen tegen spoofing stellen aanvallers in staat om berichten te versturen die afkomstig lijken van interne adressen. Deze aanvallen tonen vaak hetzelfde afzender- en ontvangeradres, of gebruiken interne weergavenamen die medewerkers herkennen en vertrouwen.

Bescherming vereist strikte DMARC-reject-beleidsregels, SPF-hardfail-configuraties en correcte instellingen voor connectors van derden, maar veel organisaties hebben deze niet correct geïmplementeerd, met name die met MX-records die niet rechtstreeks naar hun e-mailprovider verwijzen.

Homograaf- en homoglyph-aanvallen

Aanvallers registreren domeinen met visueel vergelijkbare tekens uit verschillende tekensets. De Cyrillische "а" (U+0430) ziet er in de meeste lettertypen identiek uit aan de Latijnse "a" (U+0061). Een domein als "pаypal.com" (met een Cyrillische 'a') is voor de meeste gebruikers niet te onderscheiden van "paypal.com".

Browsers kunnen dit verzachten: veel ervan tonen risicovolle domeinen in Punycode-vorm (bijv. "xn--pypal-4ve.com"), maar het gedrag is heuristisch, afhankelijk van beleid en verschilt per browser, geen universele bescherming. E-mailprogramma's en webcontent tonen de vorm van de Internationalised Domain Name (IDN) vaak rechtstreeks, waardoor de aanval mogelijk wordt. Gebruikers zien wat een legitiem domein lijkt en hebben geen reden om anders te vermoeden.

Credential-phishing steeg met 703% in de tweede helft van 2024^[2], en de gemiddelde kosten van een datalek bereikten 4,44 miljoen dollar^[3]. Recenter detecteerde Microsoft alleen al in het eerste kwartaal van 2026 8,3 miljard e-mailgebaseerde phishingdreigingen, waarvan 78% linkgebaseerd^[6], wat bevestigt dat kwaadaardige links het dominante afleveringsmechanisme blijven. De geraffineerdheid en schaal van deze aanvallen blijven toenemen.

Misbruik van legitieme diensten

Naast SendGrid hebben aanvallers ook misbruik gemaakt van de Application Integration-dienst van Google Cloud, de legitieme e-mailinfrastructuur van Microsoft en talloze andere vertrouwde platforms. Wanneer de verzendinfrastructuur daadwerkelijk vertrouwd en geauthenticeerd is, hebben traditionele e-mailbeveiligingsfilters niets om te markeren. Het aanvalsoppervlak is verschoven van spoofing naar compromittering.

Een duidelijk voorbeeld dook begin 2026 op met het misbruik van Amazon Simple Email Service (SES). Aanvallers oogsten gelekte AWS-toegangssleutels uit openbare repositories, environment-bestanden en container images, en gebruiken vervolgens de gecompromitteerde SES-accounts om phishing- en business-email-compromise-berichten te versturen. Omdat de e-mail daadwerkelijk afkomstig is van de infrastructuur van Amazon, doorstaat hij SPF, DKIM en DMARC, en draagt hij zelfs .amazonses.com in de Message-ID-headers. De berichten, die zich vaak voordoen als diensten zoals DocuSign, linken naar inlogpagina's voor het oogsten van inloggegevens die worden gehost op amazonaws.com^[7]. Het is hetzelfde patroon als bij de SendGrid-zaak: compromitteer vertrouwde infrastructuur en laat authenticatie vervolgens in het voordeel van de aanvaller werken.

Bestaande mitigatieaanpakken

E-mailproviders en beveiligingsleveranciers hebben diverse mitigatiestrategieën ontwikkeld, elk met eigen sterke punten en beperkingen.

Linkherschrijving en scanning op het klikmoment

Diensten zoals Microsoft Defender Safe Links, Check Point Harmony Email, Sophos Email Security en Symantec Email Security herschrijven URL's in e-mails om ze via een scandienst om te leiden. Wanneer een gebruiker op de link klikt, voert de dienst realtime controles uit tegen threat-intelligence-databases en malware-analyse.

Sterke punten: Effectief tegen bekende kwaadaardige URL's en domeinen. Biedt bescherming op het moment van klikken en vangt dreigingen op die opduiken nadat de e-mail is afgeleverd.

Beperkingen: Werkt mogelijk niet bij S/MIME-ondertekende of versleutelde berichten, omdat herschrijven de handtekening kan breken. Organisaties kunnen tracking-URL's op een allowlist zetten om herschrijven te voorkomen, wat beveiligingsgaten kan openen. Herschreven URL's kunnen verlopen^[4], waardoor oude e-maillinks niet meer werken. En het leunt op gecentraliseerde threat intelligence, die zero-day- of gerichte aanvallen kan missen.

URL-inspectie door te zweven (hover-to-preview)

Desktop-e-mailprogramma's tonen de daadwerkelijke URL in een statusbalk of tooltip wanneer gebruikers met de muis over een link zweven. Mobiele programma's bieden vergelijkbare functionaliteit via lange-drukgebaren.

Sterke punten: Stelt technisch onderlegde gebruikers in staat om bestemmingen te verifiëren vóór het klikken. Geen infrastructuurwijzigingen vereist.

Beperkingen: Vereist bewustzijn van de gebruiker en doelbewust handelen. Mobiele interactie is minder intuïtief dan zweven op de desktop. Microsofts "New Outlook" kreeg in 2024 kritiek vanwege ontoereikende URL-voorvertoningsfunctionaliteit^[5], wat aantoont dat zelfs gevestigde beschermingen door productbeslissingen kunnen verdwijnen. Gebruikers moeten weten wat een verdachte URL is, domeinstructuren begrijpen en homograaf-aanvallen herkennen.

Zoals een gebruiker opmerkte tijdens de New Outlook-controverse: "Het zien van de echte URL is de #1 manier waarop mensen kunnen voorkomen dat ze via e-mail worden opgelicht." Toch is deze bescherming volledig vrijwillig en afhankelijk van het gedrag van de gebruiker.

Visuele vertrouwensindicatoren

Sommige e-mailprogramma's implementeren visuele aanwijzingen om vertrouwde van niet-vertrouwde links te onderscheiden. Vertrouwde domeinen kunnen bijvoorbeeld verschijnen met een witte achtergrond en een linkicoon, terwijl niet-vertrouwde domeinen een oranje achtergrond en een waarschuwingsicoon krijgen.

Sterke punten: Passieve bescherming die geen actie van de gebruiker vereist. Visueel duidelijk onderscheiden waarschuwingen kunnen kliks ontmoedigen.

Beperkingen: Leunt op vooraf gedefinieerde vertrouwenslijsten. Pakt gecompromitteerde accounts op vertrouwde platforms niet aan (zoals in de SendGrid-zaak). Vertrouwensindicatoren kunnen een vals gevoel van vertrouwen wekken; gebruikers zouden elke link zonder waarschuwing kunnen vertrouwen, zelfs als het een gerichte aanval is op de specifieke infrastructuur van een organisatie.

Het voorstel: toon altijd de URL

Wat als e-mailprogramma's gewoon de daadwerkelijke URL naast elke link zouden tonen, ongeacht de weergegeven tekst? Geen zweven vereist. Geen handmatige inspectie nodig. Gewoon altijd zichtbare bestemmings-URL's.

Hoe het zou werken

E-mailrenderingengines zouden aanpassen hoe links verschijnen:

<!-- De e-mail bevat een gewone link -->
<a href="https://malicious-site.com/phishing">Klik hier om uw account te verifiëren</a>

<!-- Huidige programma's renderen alleen de linktekst: -->
[Klik hier om uw account te verifiëren]

<!-- Voorstel: het programma injecteert de bestemming vóór de tekst -->
<a href="https://malicious-site.com/phishing">
  <span class="email-url-display">→ https://malicious-site.com/phishing</span>
  Klik hier om uw account te verifiëren
</a>

<!-- ...zodat de gebruiker nu ziet: -->
→ https://malicious-site.com/phishing
[Klik hier om uw account te verifiëren]

Het domein (of de volledige URL, afhankelijk van het beleid) zou direct boven de linktekst worden getoond. Geen speciale actie van de gebruiker of technische kennis vereist. Gewoon onmiddellijke, onvermijdelijke zichtbaarheid van waar de link daadwerkelijk naartoe gaat.

Visuele mock-up: huidig versus voorgesteld

Sterke punten van deze aanpak

• Dringt display-tekst-mismatch sterk terug: De specifieke misleiding die de SendGrid-campagne mogelijk maakte, werkt grotendeels niet meer zodra gebruikers de daadwerkelijke bestemming altijd kunnen zien
• Geen actie van de gebruiker vereist: In tegenstelling tot hover-to-preview is dit passieve bescherming die niet afhankelijk is van bewustzijn of gedrag van de gebruiker
• Werkt op mobiel: Geen lange-drukgebaren of complexe interacties nodig
• Pakt homograaf-aanvallen aan: Verdachte domeinen worden zichtbaar en kunnen worden geïnspecteerd
• Implementeerbaar op weergavemoment: Browserextensies en mailprogramma-plug-ins kunnen gerenderde content nabewerken; first-party-programma's hebben meer werk (sanitisatie, mobiele UX, ondertekende content, toegankelijkheid)
• Transport-onafhankelijk: Toegepast wanneer het bericht wordt gerenderd, zonder het berichttransport te wijzigen, hoewel ondertekende of hoog-integere mailstromen nog steeds zorgvuldig UX-ontwerp vereisen

Zwakke punten en afwegingen

• Aanzienlijke achteruitgang van de gebruikerservaring: E-mails worden rommeliger en moeilijker leesbaar, met name marketing-e-mails met veel links
• Breekt legitieme marketingcampagnes: Tracking-URL's (bijv. klikregistratie van nieuwsbrieven) zien er verdacht uit, zelfs als ze onschuldig zijn
• Vergroot de visuele ruis: Lange URL's nemen schermruimte in beslag en verminderen de leesbaarheid
• Kan klikpercentages verlagen: Legitieme calls to action kunnen minder betrokkenheid zien doordat gebruikers worden overspoeld met URL-informatie
• Pakt accountcompromittering niet aan: Als een aanvaller een legitiem domein beheert, zal de URL betrouwbaar lijken, ook wanneer hij wordt getoond
• Voorlichting van gebruikers blijft nodig: Gebruikers moeten begrijpen wat een verdacht domein is

Implementatieaanpakken

E-mailprogramma's kunnen dit op verschillende manieren implementeren:

• Volledige URL-weergave: Toon de volledige URL voor elke link
• Alleen-domein-weergave: Toon alleen het domein, wat de rommel vermindert en tegelijk het beveiligingsvoordeel behoudt
• Externe links markeren: Toon alleen URL's voor links die buiten het domein van de afzender wijzen
• Gebruikersvoorkeursinstelling: Sta gebruikers toe om zich aan- of af te melden (hoewel dit de effectiviteit voor minder technische gebruikers vermindert)

Wat het niet oplost

Altijd de URL tonen verslaat display-tekst-mismatch, maar het is geen universeel medicijn. Twee technieken die in de loop van 2026 sterk in opkomst zijn, omzeilen het volledig:

• OAuth device-code-phishing: In een campagne die eind april 2026 werd ontdekt, lieten de operators van Tycoon2FA nep-inlogpagina's volledig achterwege. Het slachtoffer wordt gevraagd een korte code in te voeren op de echte pagina microsoft.com/devicelogin; Microsoft handelt vervolgens de authenticatie af, inclusief MFA, en geeft onbewust OAuth-tokens af aan een door de aanvaller beheerd apparaat^[9]. Het tonen van de URL onthult een legitiem Microsoft-domein, dus er is niets verdachts om te markeren.
• QR-code-phishing ("quishing"): De bestemming is ingebed in een afbeelding in plaats van in een anchor-tag, dus er is helemaal geen linktekst of URL voor het programma om te tonen. Microsoft registreerde in het eerste kwartaal van 2026 een stijging van 146% in QR-code-phishing, van 7,6 miljoen naar 18,7 miljoen berichten^[6].

Beide zijn varianten van adversary-in-the-middle-phishing, waarbij de aanvaller een live authenticatiesessie doorstuurt en tokens in plaats van wachtwoorden buitmaakt. Altijd zichtbare URL's leggen de lat hoger tegen de meest voorkomende aanvallen, maar ze versterken eerder dan vervangen de noodzaak van gelaagde verdediging.

Alternatieve strategieën

Altijd URL's tonen is één aanpak, maar het is niet de enige mogelijkheid. Hier zijn enkele alternatieven, elk met andere afwegingen tussen beveiliging en bruikbaarheid.

Alleen links binnen hetzelfde domein (geverifieerde afzenders)

E-mailprogramma's zouden een beleid kunnen afdwingen waarbij geauthenticeerde afzenders alleen links naar hun eigen domein mogen opnemen. Als een e-mail van bank.com DMARC-geauthenticeerd is, mag deze links naar bank.com bevatten, maar niet naar domeinen van derden.

Voordelen: Voorkomt directe links naar overduidelijk verdachte externe domeinen. Behoudt een schone UX voor interne communicatie. Maakt gebruik van bestaande authenticatie-infrastructuur. Kan ongeraffineerde phishingpogingen onderscheppen.

Nadelen: Voorkomt geen aanvallen via tracking-URL's van e-mailplatforms (zoals de klikregistratie van SendGrid) die omleiden via vertrouwde domeinen. Breekt legitieme gebruiksscenario's zoals nieuwsbrieven die naar bronnen linken, partnercommunicatie, contentaggregatie en gedeelde documenten. Voorkomt geen subdomain-takeover-aanvallen. Kan het gebruik van URL-verkorters aanmoedigen, wat het doel ondermijnt. Vereist strikte DMARC-handhaving.

Haalbaarheid: Gemiddeld. De technische implementatie is eenvoudig, maar de handhaving van het beleid veroorzaakt aanzienlijke bruikbaarheidsproblemen.

Volledige URL-weergave met klikbevestiging

Toon de URL en vereis expliciete bevestiging vóór het navigeren. Wanneer een gebruiker op een link klikt, toon een dialoogvenster: "U staat op het punt https://example.com te bezoeken. Doorgaan?"

Voordelen: Behoudt de linkfunctionaliteit met expliciete toestemming van de gebruiker. Educatief: het traint gebruikers om URL's te verifiëren. Kan worden geconfigureerd met allowlists voor vertrouwde domeinen.

Nadelen: Klikmoeheid: gebruikers zullen automatisch bevestigen zonder te lezen, net zoals ze dat bij andere beveiligingsdialoogvensters doen. Verdubbelt de interactiekosten voor elke e-maillink. Vreselijke mobiele bruikbaarheid. Voorkomt geen geraffineerde aanvallen omdat gebruikers bevestigingsdialoogvensters niet zorgvuldig lezen.

Haalbaarheid: Technisch hoog, maar zeer lage acceptatie door gebruikers. Bevestigingsmoeheid maakt dit grotendeels ineffectief.

Gefaseerd URL-weergavebeleid

Implementeer configureerbare weergavemodi waarmee gebruikers hun beveiligingsniveau kunnen kiezen:

Strikte modus Beveiligingsgerichte gebruikers	Gebalanceerde modus Standaard aanbevolen	Toegeeflijke modus UX-gerichte gebruikers
→ https://example.com/verify?token=abc123 [Account verifiëren]	→ example.com (zelfde domein) [Account verifiëren] → external-site.com (anders) [Klik hier]	(URL verborgen, getoond bij zweven) [Account verifiëren]
Volledige URL altijd zichtbaar	Toon domein alleen voor externe links	Huidig gedrag, handmatige inspectie

Voordelen: Balanceert beveiliging en bruikbaarheid. Gebruikers kunnen hun voorkeur kiezen. Organisaties kunnen beleidsregels afdwingen voor verschillende gebruikersgroepen. De gebalanceerde modus biedt betekenisvolle bescherming zonder overweldigende rommel.

Nadelen: Vereist bewustzijn van de gebruiker om correct te configureren. Minder technische gebruikers kunnen de toegeeflijke modus kiezen en kwetsbaar blijven. Complexiteit in implementatie en gebruikersvoorlichting.

Haalbaarheid: Gemiddeld. De implementatie is eenvoudig, maar het bewustzijn rond gebruikersconfiguratie en voorlichting zijn uitdagend.

Machine-learning-gebaseerde risicoscoring van links

Train ML-modellen om het risico van links te beoordelen op basis van domeinreputatie, afzendergeschiedenis, patronen van tekst/URL-mismatch, lexicale analyse van domeinen en historisch klikgedrag. Toon risicoscores of waarschuwingen alleen voor verdachte links.

Voordelen: Geautomatiseerde detectie zonder legitieme gebruiksscenario's te breken. Past zich aan evoluerende aanvalspatronen aan. Schaalt goed over grote organisaties. Kan meerdere signalen combineren (afzenderreputatie, domeinleeftijd, tekstovereenkomst, enz.).

Nadelen: Vals-positieven zijn een aanzienlijk probleem: legitieme links die als verdacht worden gemarkeerd, veroorzaken gebruikersmoeheid en ondermijnen het vertrouwen in het systeem. Gebruikers leren waarschuwingen te negeren, wat de effectiviteit na verloop van tijd vermindert. Vals-negatieven creëren risico. Vereist aanzienlijke trainingsdata en doorlopende afstemming. Aanvallers kunnen mogelijk leren om ML-modellen te omzeilen. Complexe implementatie die ML-infrastructuur vereist.

Haalbaarheid: Gemiddeld. Grote e-mailproviders hebben de data en middelen, maar vals-positieve moeheid beperkt de effectiviteit in de praktijk aanzienlijk.

Verbeterde mobiele hover-UX

Verbeter de mobiele linkvoorvertoningsfunctionaliteit. In plaats van een lange druk te vereisen, toon een klein domeinbadge naast elke link. Tikken op de link navigeert; tikken op het badge toont de volledige URL-details.

Voordelen: Verbetert de mobiele beveiliging zonder impact op de desktop. Biedt onmiddellijke domeinzichtbaarheid. Behoudt de huidige UX en verbetert tegelijk de beveiliging.

Nadelen: Vereist nog steeds bewustzijn en actie van de gebruiker. Voegt visuele complexiteit toe aan de linkweergave. Kan verwarrend zijn voor minder technische gebruikers. Pakt desktopkwetsbaarheden niet aan.

Haalbaarheid: Hoog. Relatief eenvoudige implementatie aan de clientzijde met aanzienlijk mobiel beveiligingsvoordeel.

Cryptografische linkondertekening (DKIM voor URL's)

Wat als links in e-mails cryptografisch ondertekend zouden kunnen worden, vergelijkbaar met hoe DKIM e-mailheaders en -body ondertekent? Een afzender zou elke URL in zijn e-mail kunnen ondertekenen, en het e-mailprogramma van de ontvanger zou deze handtekeningen verifiëren vóórdat navigatie wordt toegestaan.

Hoe het zou werken: Een nieuw type DNS-record (bijv. een EMLNK- of _linkkey-TXT-record) zou de publieke sleutel voor e-maillinkverificatie publiceren, vergelijkbaar met hoe DKIM _domainkey-records gebruikt. Cruciaal: dit zou losstaan van DKIM: de DKIM-ondertekeningssleutels bevinden zich op de mailserver en zouden niet toegankelijk mogen zijn voor e-mailapplicaties. De linkondertekeningssleutels zouden worden beheerd door de e-mailopstelsystemen van de organisatie of de e-mailserviceprovider.

Bij het opstellen van een e-mail zou de verzendende applicatie elke URL ondertekenen met de private linkondertekeningssleutel van het domein. Deze handtekeningen zouden kunnen worden ingebed als een aparte MIME-part (bijv. application/link-signatures) of als data-signature-attributen op anchor-tags. Het ontvangende e-mailprogramma zou de publieke sleutel uit DNS ophalen (bijv. _linkkey.example.com) en elke handtekening verifiëren vóórdat navigatie wordt toegestaan.

Als de handtekening van een link niet verifieert, omdat de URL is gewijzigd, geïnjecteerd, of de afzender hem in werkelijkheid niet heeft opgenomen, zou het e-mailprogramma de gebruiker kunnen waarschuwen, de link kunnen uitschakelen of hem anders kunnen weergeven.

Voordelen: Bewijst cryptografisch de authenticiteit van een link. Voorkomt link-injectie- en link-modificatie-aanvallen. Bouwt voort op bestaande DKIM-infrastructuur en sleuteldistributie. Werkt met versleutelde e-mails. Vereist geen wijzigingen in de URL-weergave. Zou kunnen worden geïmplementeerd als een uitbreiding op bestaande e-mailstandaarden.

Nadelen: Vereist nieuwe e-mailstandaarden en brede adoptie. Voorkomt geen aanvallen vanaf gecompromitteerde accounts (die kunnen kwaadaardige links met geldige sleutels ondertekenen). Implementatiecomplexiteit voor e-mailprogramma's en -servers. Vereist nieuwe DNS-infrastructuur en recordtypes. Uitdagingen rond achterwaartse compatibiliteit met bestaande e-mails. Kan legitieme e-maildoorsturing en mailinglijst-scenario's breken waarin content wordt gewijzigd.

Haalbaarheid: Laag tot gemiddeld op korte termijn vanwege standaardisatievereisten, maar potentieel hoge waarde op lange termijn. Zou de ontwikkeling van een IETF-RFC en adoptie door grote e-mailproviders vereisen.

Vergelijking van mitigatiestrategieën

Strategie	Effectiviteit	UX-impact	Haalbaarheid	Gebruikersactie
Altijd URL tonen	●●● Hoog	●●● Aanzienlijk	●● Bouwen makkelijk, adopteren lastig	Geen
Alleen zelfde domein	●● Gemiddeld	●●● Breekt workflows	●● Gemiddeld	Geen
Klikbevestiging	● Laag	●●● Zeer hoog	●●● Hoog	Elke klik
Gefaseerd beleid	●●● Hoog	●● Configureerbaar	●● Gemiddeld	Configuratie
ML-risicoscoring	●● Gemiddeld	● Minimaal	●● Complex	Geen
Cryptografische linkondertekening	●●● Hoog	● Geen	● Laag (nieuwe standaard)	Geen
Verbeterde mobiele UX	●● Gemiddeld	● Laag	●●● Hoog	Optioneel
Huidig (zweven)	● Laag	● Geen	●●● Bestaat	Handmatig

Adoptiedrempels en uitdagingen voor de sector

Zelfs als altijd-URL-tonen of vergelijkbare strategieën technisch effectief blijken, stuit brede adoptie op aanzienlijke hindernissen.

Weerstand van de marketingafdeling

Marketingteams leunen sterk op linkesthetiek en tracking. Een knop "Klik hier om je aanbieding te claimen" is aantrekkelijker dan "→ tracking.mailchimp.com/c/eJw... [Klik hier om je aanbieding te claimen]". E-mailmarketingstatistieken zoals openings-, doorklik- en conversiepercentages kunnen dalen als URL's altijd zichtbaar zijn, wat interne weerstand tegen implementatie creëert.

Organisaties moeten beveiliging afwegen tegen impact op de omzet. Voor veel bedrijven heeft een daling van 10% in e-mailconversiepercentages directe gevolgen voor het resultaat. Beveiligingsteams zullen een duidelijke ROI of voordelen op het gebied van regelgevingscompliance moeten aantonen om deze weerstand te overwinnen.

Zorgen rond gebruikerservaring

E-mail is een communicatiemedium, niet alleen een beveiligingsperimeter. Gebruikers hechten waarde aan leesbaarheid, duidelijkheid en esthetiek. Altijd zichtbare URL's verslechteren de leeservaring, met name voor nieuwsbrieven, digests en content-rijke e-mails. Als gebruikers e-mails moeilijker leesbaar vinden, kunnen ze volledig afhaken, wat de waarde van e-mail als communicatiekanaal vermindert.

Ontwerpteams zullen zich verzetten tegen wijzigingen die e-mails objectief lelijker en minder bruikbaar maken. Beveiligingsverbeteringen die de UX aanzienlijk schaden, hebben het zwaar te verduren bij de acceptatie door gebruikers.

Vereisten voor coördinatie binnen de sector

E-mailbeveiliging is afhankelijk van standaarden die in de hele sector worden aangenomen. SPF, DKIM en DMARC slaagden omdat grote providers (Gmail, Outlook, Yahoo) ze allemaal implementeerden en afdwongen. Een vergelijkbare gecoördineerde inspanning zou nodig zijn voor URL-weergavebeleid.

Als slechts één e-mailprovider altijd-URL-tonen implementeert, zouden gebruikers eenvoudigweg kunnen overstappen naar providers met een betere UX. Standaardisatie-instanties (IETF, werkgroepen voor e-mailprogramma's) zouden specificaties moeten ontwikkelen, en grote providers zouden ze in ongeveer hetzelfde tijdsbestek moeten aannemen.

Het probleem van achterwaartse compatibiliteit

Miljarden bestaande e-mails bevatten links die zijn opgemaakt voor de huidige renderingengines. Het wijzigen van hoe links worden weergegeven, beïnvloedt met terugwerkende kracht gearchiveerde e-mails, doorgestuurde berichten en gespreksthreads. Dit zorgt voor verwarring wanneer oudere e-mails plotseling anders worden gerenderd, of wanneer gebruikers met verschillende e-mailprogramma's verschillende linkweergaven zien in dezelfde thread.

Conclusie en oproep tot actie

E-mailauthenticatiestandaarden hebben domain spoofing met succes aangepakt, maar linkgebaseerde phishing blijft een kritieke kwetsbaarheid. De SendGrid-aanval toont aan dat gecompromitteerde accounts op vertrouwde platforms alle authenticatiecontroles kunnen omzeilen, waardoor gebruikers alleen handmatige URL-inspectie als verdediging overhouden.

De linkbestemming altijd tonen zou display-tekst-mismatch als misleidingstechniek sterk terugdringen, zij het niet phishing via vertrouwde domeinen, QR-codes of OAuth-device-flows. Het kan op het weergavemoment worden toegepast, maar het brengt reële UX-kosten met zich mee en stuit op aanzienlijke adoptiedrempels.

Misschien is het antwoord niet één enkele oplossing. Defence in depth is hier ook van toepassing: gefaseerde weergavebeleidsregels geven gebruikers keuze, ML-gebaseerde risicoscoring biedt geautomatiseerde detectie, verbeterde mobiele UX verbetert de inspectiemogelijkheden, en sectorbrede standaarden zouden basisbeschermingen kunnen vaststellen.

Wat duidelijk is, is dat niets doen geen optie is. Phishing groeit in geraffineerdheid en schaal: credential-phishing sprong met 703% eind 2024^[2], de kosten van een datalek naderen de 4,5 miljoen dollar^[3], en Microsoft registreerde 8,3 miljard e-mailphishingdreigingen in één kwartaal van 2026^[6]. De sector moet handelen.

Voor ontwikkelaars van e-mailprogramma's: Overweeg de implementatie van gefaseerd URL-weergavebeleid en verbeterde mobiele inspectie-UX. Deze bieden beveiligingsvoordelen met configureerbare UX-impact.

Voor beveiligingsteams: Evalueer ML-gebaseerde risicoscoring van links en dwing strikt linkherschrijvingsbeleid af. Stapel verdedigingen en vertrouw niet uitsluitend op het gedrag van gebruikers.

Voor standaardisatie-instanties: Start discussies over URL-weergavestandaarden en linkveiligheidsprotocollen. E-mailbeveiliging heeft voortdurende evolutie nodig.

Voor gebruikers: Schakel linkvoorvertoningsfuncties in, inspecteer URL's vóór het klikken, en pleit voor betere beveiligings-UX in je e-mailprogramma's.

Het gat tussen authenticatie en linkveiligheid sluit zichzelf niet. Het is tijd dat de sector dit gesprek voert.

Bronnen

1. Phishing actors exploit complex routing and misconfigurations to spoof domains. Microsoft Security Blog (januari 2026). Microsoft Defender for Office 365 blokkeerde in oktober 2025 meer dan 13 miljoen kwaadaardige e-mails die aan Tycoon2FA gelinkt waren.
2. SlashNext 2024 Phishing Intelligence Report (PRNewswire). Credential-phishingaanvallen namen met 703% toe in de tweede helft van 2024.
3. IBM Cost of a Data Breach Report 2025. Wereldwijde gemiddelde kosten van een datalek: 4,44 miljoen dollar.
4. Complete Safe Links overview for Microsoft Defender for Office 365. Microsoft Learn. Documentatie over de URL-scanning- en herschrijvingsfunctionaliteit van Safe Links, inclusief beperkingen rond het verlopen van URL's en eenmalig te gebruiken links.
5. New Outlook not showing link URLs. Microsoft Tech Community. Gebruikersdiscussies over de ontbrekende URL-voorvertoning bij zweven in New Outlook, die beveiligingszorgen opwerpen over het verifiëren van links vóór het klikken.
6. Email threat landscape: Q1 2026 trends and insights. Microsoft Security Blog (april 2026). 8,3 miljard e-mailgebaseerde phishingdreigingen gedetecteerd in Q1 2026, waarvan 78% linkgebaseerd; QR-code-phishing steeg 146% over het kwartaal.
7. Phishing campaigns and BEC attacks through Amazon SES. Securelist (Kaspersky), 2026. Aanvallers misbruiken gelekte AWS-toegangssleutels om volledig geauthenticeerde phishing- en BEC-berichten te versturen via Amazon SES, met pagina's voor het oogsten van inloggegevens die op amazonaws.com worden gehost.
8. Tycoon2FA phishing-as-a-service platform persists following takedown. CrowdStrike (maart 2026). Microsoft, Europol en partners ontmantelden op 4 maart 2026 330 actieve Tycoon2FA-domeinen, maar het campagnevolume keerde binnen enkele dagen terug naar het niveau van vóór de takedown.
9. Tycoon 2FA operators use OAuth device code phishing to bypass MFA. GBHackers (april 2026). Campagne van eind april 2026 die misbruik maakt van microsoft.com/devicelogin om OAuth-tokens buit te maken zonder een nep-inlogpagina te tonen.