E-Mail-Link-Phishing: Warum Ihre Mail-App immer die URL anzeigen sollte

Bei der E-Mail-Sicherheit haben wir enorme Fortschritte gemacht. SPF, DKIM und DMARC haben Domain-Spoofing erheblich reduziert, sofern sie korrekt eingerichtet sind. Besteht eine E-Mail diese Prüfungen, ist sie sehr wahrscheinlich über die Infrastruktur der angegebenen Domain gelaufen und stammt nicht von einem gefälschten Absender. Das ist ein echter Fortschritt, aber nur eine sehr begrenzte Garantie.

Doch es gibt eine Lücke. Eine bedeutende. Authentifizierungsstandards prüfen, wer die E-Mail gesendet hat, nicht, wohin die Links führen. Ein Angreifer muss die Domain Ihrer Bank nicht fälschen, wenn er ein legitimes Konto auf einer vertrauenswürdigen Plattform kompromittieren und Ihnen eine einwandfrei authentifizierte E-Mail mit einem schädlichen Link senden kann. Die Authentifizierung stimmt. Der Link ist die Falle.

Im Januar 2026 sahen wir genau diesen Angriffsvektor in großem Maßstab bei SendGrid, eine der weltweit größten Plattformen für den E-Mail-Versand. Die Kampagne war wirkungsvoll, alle Authentifizierungsprüfungen wurden bestanden, und die Nutzer blieben häufig auf eine der wenigen sichtbaren clientseitigen Verteidigungen angewiesen: das manuelle Prüfen der Link-URLs. Dieser Artikel zeigt, warum das passiert ist und warum die aktuellen Gegenmaßnahmen nicht ausreichen, und schlägt eine radikale Lösung vor:

Fallstudie: SendGrid-Phishing-Angriff (Januar 2026)

Anfang Januar 2026 starteten Angreifer eine gezielte Phishing-Kampagne, die die Infrastruktur von SendGrid auf besonders raffinierte Weise ausnutzte. Statt zu versuchen, SendGrid oder dessen Kunden zu fälschen, kompromittierten sie echte SendGrid-Kundenkonten über Credential Stuffing und die Wiederverwendung von Passwörtern. Einmal eingedrungen, nutzten sie die legitime Versandfunktion von SendGrid, um Phishing-E-Mails zu verbreiten.

Die kompromittierten Konten gehörten echten Unternehmen: drummond.com, nellions.co.ke, theraoffice.com. Es handelte sich um etablierte Domains mit Versandhistorie und Reputation. Als die Phishing-E-Mails eintrafen, bestanden sie jede Authentifizierungsprüfung. SPF stimmte überein. DKIM-Signaturen wurden validiert. DMARC-Richtlinien wurden bestanden. Aus Sicht der Infrastruktur waren dies legitime SendGrid-E-Mails; sie wurden nur zufällig von unbefugten Nutzern versendet.

Der Social-Engineering-Vektor

Was diese Kampagne besonders wirkungsvoll machte, war das Social Engineering. Statt der üblichen Warnung „Ihr Konto wurde gesperrt“ gaben sich die E-Mails Berichten zufolge als SendGrid aus, das kontroverse Richtlinienänderungen ankündigte — bewusst um emotional aufgeladene, spaltende Themen herum gestaltet, um eine starke, empörte Reaktion zu provozieren.

Das Ziel war, die Empfänger zum Reagieren zu bewegen, bevor sie nachdachten — also auf „Abmelden“ oder „Einstellungen verwalten“ zu klicken, ohne innezuhalten und die URL zu prüfen. Dies markiert eine bemerkenswerte Verschiebung in der Taktik: ein auf Empörung statt auf Angst oder Neugier ausgelegter Köder, denn wer emotional reagiert, prüft seltener, wohin ein Link tatsächlich führt.

Der Mechanismus der Link-Tarnung

Die Phishing-E-Mails enthielten Aktionsschaltflächen, die als Optionen zur Verwaltung von Einstellungen oder zur Kontowiederherstellung gekennzeichnet waren. Der Anzeigetext lautete „Einstellungen verwalten“ oder „Kontoeinstellungen aktualisieren“. Die tatsächlichen URLs verwiesen jedoch auf Seiten zum Abgreifen von Zugangsdaten, die so gestaltet waren, dass sie wie die Login-Oberfläche von SendGrid aussahen.

Eine solche Kampagne kann sich auf eine bekannte Adversary-in-the-Middle-Technik stützen: Die gefälschte Login-Seite überprüft die eingegebenen Zugangsdaten in Echtzeit gegen den echten Dienst. Funktionieren die Zugangsdaten, wird das Opfer an das echte Dashboard weitergeleitet; andernfalls wird es aufgefordert, es erneut zu versuchen. So oder so sieht es nie das verräterische Versagen eines toten Phishing-Formulars — und genau das macht die Täuschung so überzeugend.

Warum die aktuellen Gegenmaßnahmen versagten

Dieser Angriff umging nahezu jede gängige E-Mail-Sicherheitsmaßnahme:

• Authentifizierung bestanden: SPF, DKIM und DMARC wurden alle validiert, weil die E-Mails tatsächlich von der SendGrid-Infrastruktur stammten
• Domain-Reputation intakt: Die kompromittierten Absenderkonten hatten etablierte Versandhistorien
• Umgehung der Inhaltsfilterung: Politisch gefärbte Inhalte wirkten legitim und lösten keine Spamfilter aus
• Ausnutzung von Vertrauen: Das SendGrid-Branding in Kombination mit authentifizierter Infrastruktur erzeugte ein falsches Vertrauen
• Link-Verschleierung: Der Anzeigetext zeigte harmlose Zwecke an, während die URLs auf Seiten zum Diebstahl von Zugangsdaten verwiesen

Für viele Nutzer war das manuelle Prüfen der tatsächlichen URL vor dem Klicken eines der wenigen sichtbaren clientseitigen Signale — auch wenn manche Organisationen zusätzlich Link-Rewriting, Scans zum Klickzeitpunkt oder Browser-Schutzmechanismen im Einsatz hatten. Auf dem Desktop erfordert diese Prüfung, mit der Maus über den Link zu fahren und das Ziel in der Statusleiste zu lesen. Auf Mobilgeräten erfordert sie einen langen Fingerdruck und das sorgfältige Prüfen der Vorschau. All das setzt Aufmerksamkeit des Nutzers, bewusstes Handeln und das technische Wissen voraus, eine verdächtige Domain zu erkennen.

Eine detaillierte Analyse dieses Angriffs finden Sie in Fred Benensons Fallstudie.

Aktuelle Phishing-Angriffsvektoren

Der SendGrid-Angriff steht für einen breiteren Trend. E-Mail-Phishing hat sich deutlich weiterentwickelt, und Angreifer nutzen Lücken sowohl in der Technik als auch im menschlichen Verhalten aus.

Anzeigename-Spoofing

E-Mail-Programme zeigen Absendernamen prominenter an als E-Mail-Adressen. Ein Angreifer kann den Anzeigenamen auf „Support“ oder „Personalabteilung“ setzen, während die tatsächliche Absenderadresse etwas völlig anderes ist. Microsoft stellte über das gesamte Jahr 2025 hinweg einen deutlichen Anstieg dieser Angriffe fest, insbesondere über Phishing-as-a-Service-Plattformen wie Tycoon2FA^[1]. Im März 2026 zerschlugen Microsoft, Europol und Branchenpartner 330 aktive, mit Tycoon2FA verbundene Domains, doch das Kampagnenvolumen kehrte innerhalb weniger Tage auf das Niveau vor der Zerschlagung zurück — eine Erinnerung daran, dass das Lahmlegen von Phishing-as-a-Service-Infrastruktur nur vorübergehende Entlastung bringt^[8].

Nutzer konzentrieren sich auf den vertrauten Anzeigenamen und prüfen die tatsächliche Absenderadresse nicht. E-Mail-Programme könnten dem entgegenwirken, indem sie Adressen prominenter anzeigen oder Diskrepanzen zwischen Anzeigenamen und Absenderdomains kennzeichnen, doch die meisten tun das nicht.

Internes Domain-Spoofing

Falsch konfiguriertes E-Mail-Routing und unzureichende Schutzmaßnahmen gegen Spoofing ermöglichen es Angreifern, Nachrichten zu versenden, die von internen Adressen zu stammen scheinen. Bei diesen Angriffen ist häufig dieselbe Adresse als Absender und Empfänger angegeben, oder es werden interne Anzeigenamen verwendet, die Mitarbeiter wiedererkennen und denen sie vertrauen.

Der Schutz erfordert strikte DMARC-Reject-Richtlinien, SPF-Hard-Fail-Konfigurationen und korrekte Einstellungen für Drittanbieter-Konnektoren, doch viele Organisationen haben diese nicht korrekt umgesetzt — insbesondere jene, deren MX-Einträge nicht direkt auf ihren E-Mail-Anbieter verweisen.

Homograph- und Homoglyph-Angriffe

Angreifer registrieren Domains mit optisch ähnlichen Zeichen aus unterschiedlichen Zeichensätzen. Das kyrillische „а“ (U+0430) sieht in den meisten Schriftarten identisch aus wie das lateinische „a“ (U+0061). Eine Domain wie „pаypal.com“ (mit einem kyrillischen „a“) ist für die meisten Nutzer nicht von „paypal.com“ zu unterscheiden.

Browser können dem entgegenwirken: Viele zeigen riskante Domains in Punycode-Form an (z. B. „xn--pypal-4ve.com“), doch dieses Verhalten ist heuristisch, richtlinienabhängig und variiert zwischen Browsern — kein universeller Schutz. E-Mail-Programme und Webinhalte zeigen die Form des internationalisierten Domainnamens (IDN) oft direkt an und ermöglichen so den Angriff. Nutzer sehen, was wie eine legitime Domain aussieht, und haben keinen Grund, etwas anderes zu vermuten.

Credential-Phishing stieg in der zweiten Jahreshälfte 2024 um 703 %^[2], und die durchschnittlichen Kosten einer Datenpanne erreichten 4,44 Millionen US-Dollar^[3]. Jüngst entdeckte Microsoft allein im ersten Quartal 2026 8,3 Milliarden E-Mail-basierte Phishing-Bedrohungen, von denen 78 % link-basiert waren^[6], was bestätigt, dass schädliche Links nach wie vor der dominierende Übertragungsmechanismus sind. Die Raffinesse und das Ausmaß dieser Angriffe nehmen weiter zu.

Missbrauch legitimer Dienste

Neben SendGrid haben Angreifer auch Googles Application-Integration-Dienst, die legitime E-Mail-Infrastruktur von Microsoft und zahlreiche weitere vertrauenswürdige Plattformen ausgenutzt. Wenn die versendende Infrastruktur tatsächlich vertrauenswürdig und authentifiziert ist, haben herkömmliche E-Mail-Sicherheitsfilter nichts, was sie kennzeichnen könnten. Die Angriffsfläche hat sich vom Spoofing zur Kompromittierung verlagert.

Ein deutliches Beispiel zeigte sich Anfang 2026 mit dem Missbrauch von Amazon Simple Email Service (SES). Angreifer sammeln durchgesickerte AWS-Zugangsschlüssel aus öffentlichen Repositories, Umgebungsdateien und Container-Images und nutzen dann die kompromittierten SES-Konten, um Phishing- und Business-E-Mail-Compromise-Nachrichten zu versenden. Da die Mail tatsächlich von der Infrastruktur von Amazon stammt, besteht sie SPF, DKIM und DMARC und trägt sogar .amazonses.com in den Message-ID-Kopfzeilen. Die Nachrichten, die häufig Dienste wie DocuSign imitieren, verlinken auf Anmeldeseiten zum Abgreifen von Zugangsdaten, die auf amazonaws.com gehostet werden^[7]. Es ist dasselbe Muster wie im Fall SendGrid: vertrauenswürdige Infrastruktur kompromittieren und dann die Authentifizierung zum Vorteil des Angreifers arbeiten lassen.

Bestehende Gegenmaßnahmen

E-Mail-Anbieter und Sicherheitsanbieter haben verschiedene Strategien zur Risikominderung entwickelt, jede mit eigenen Stärken und Grenzen.

Link-Rewriting und Scans zum Klickzeitpunkt

Dienste wie Microsoft Defender Safe Links, Check Point Harmony Email, Sophos Email Security und Symantec Email Security schreiben URLs in E-Mails um, sodass sie über einen Scan-Dienst umgeleitet werden. Wenn ein Nutzer auf den Link klickt, führt der Dienst in Echtzeit Prüfungen gegen Threat-Intelligence-Datenbanken und eine Malware-Analyse durch.

Stärken: Wirksam gegen bekannte schädliche URLs und Domains. Bietet Schutz zum Klickzeitpunkt und fängt damit Bedrohungen ab, die erst nach der Zustellung der E-Mail auftauchen.

Grenzen: Funktioniert möglicherweise nicht bei S/MIME-signierten oder verschlüsselten Nachrichten, da das Umschreiben die Signatur zerstören kann. Organisationen können Tracking-URLs auf eine Positivliste setzen, um das Umschreiben zu verhindern, was Sicherheitslücken öffnen kann. Umgeschriebene URLs können ablaufen^[4] und alte E-Mail-Links unbrauchbar machen. Zudem stützt sich der Ansatz auf zentralisierte Threat Intelligence, die Zero-Day- oder gezielte Angriffe verpassen kann.

URL-Prüfung per Hover-Vorschau

Desktop-E-Mail-Programme zeigen die tatsächliche URL in einer Statusleiste oder einem Tooltip an, wenn Nutzer mit der Maus über einen Link fahren. Mobile Clients bieten eine ähnliche Funktion über einen langen Fingerdruck.

Stärken: Ermöglicht technisch versierten Nutzern, Ziele vor dem Klicken zu überprüfen. Keine Änderungen an der Infrastruktur erforderlich.

Grenzen: Erfordert Aufmerksamkeit und bewusstes Handeln des Nutzers. Die mobile Interaktion ist weniger intuitiv als das Hovern am Desktop. Microsofts „New Outlook“ geriet 2024 wegen unzureichender URL-Vorschaufunktion in die Kritik^[5], was zeigt, dass selbst etablierte Schutzmechanismen aufgrund von Produktentscheidungen verschwinden können. Nutzer müssen wissen, was eine verdächtige URL ausmacht, Domainstrukturen verstehen und Homograph-Angriffe erkennen.

Wie ein Nutzer während der Kontroverse um New Outlook anmerkte: „Die echte URL zu sehen ist die wichtigste Möglichkeit, wie Menschen vermeiden können, per E-Mail betrogen zu werden.“ Dennoch ist dieser Schutz vollständig freiwillig und hängt vom Verhalten des Nutzers ab.

Visuelle Vertrauensindikatoren

Manche E-Mail-Programme setzen visuelle Hinweise ein, um vertrauenswürdige von nicht vertrauenswürdigen Links zu unterscheiden. Vertrauenswürdige Domains könnten beispielsweise mit weißem Hintergrund und Link-Symbol erscheinen, während nicht vertrauenswürdige Domains einen orangefarbenen Hintergrund und ein Warnsymbol erhalten.

Stärken: Passiver Schutz, der kein Zutun des Nutzers erfordert. Visuell auffällige Warnungen können vom Klicken abhalten.

Grenzen: Stützt sich auf vordefinierte Vertrauenslisten. Adressiert keine kompromittierten Konten auf vertrauenswürdigen Plattformen (wie im Fall SendGrid). Vertrauensindikatoren können falsches Vertrauen erzeugen; Nutzer könnten jedem Link ohne Warnung vertrauen, selbst wenn es sich um einen gezielten Angriff gegen die spezifische Infrastruktur einer Organisation handelt.

Der Vorschlag: immer die URL anzeigen

Was wäre, wenn E-Mail-Programme die tatsächliche URL einfach neben jedem Link anzeigen würden, unabhängig vom Anzeigetext? Kein Hovern erforderlich. Keine manuelle Prüfung nötig. Einfach stets sichtbare Ziel-URLs.

Wie es funktionieren würde

Die Rendering-Engines für E-Mails würden ändern, wie Links erscheinen:

<!-- Die E-Mail enthält einen gewöhnlichen Link -->
<a href="https://malicious-site.com/phishing">Klicken Sie hier, um Ihr Konto zu verifizieren</a>

<!-- Aktuelle Clients rendern nur den Linktext: -->
[Klicken Sie hier, um Ihr Konto zu verifizieren]

<!-- Vorschlag: Der Client fügt das Ziel vor dem Text ein -->
<a href="https://malicious-site.com/phishing">
  <span class="email-url-display">→ https://malicious-site.com/phishing</span>
  Klicken Sie hier, um Ihr Konto zu verifizieren
</a>

<!-- ...sodass der Nutzer nun sieht: -->
→ https://malicious-site.com/phishing
[Klicken Sie hier, um Ihr Konto zu verifizieren]

Die Domain (oder die vollständige URL, je nach Richtlinie) würde direkt über dem Linktext angezeigt. Es ist keine besondere Nutzeraktion und kein technisches Fachwissen erforderlich. So wird für den Nutzer sofort und unübersehbar sichtbar, wohin der Link tatsächlich führt.

Visuelles Mockup: aktuell vs. vorgeschlagen

Stärken dieses Ansatzes

• Reduziert die Anzeigetext-Diskrepanz erheblich: Die konkrete Täuschung, die die SendGrid-Kampagne ermöglichte, funktioniert weitgehend nicht mehr, sobald Nutzer das tatsächliche Ziel stets sehen können
• Keine Nutzeraktion erforderlich: Anders als die Hover-Vorschau ist dies ein passiver Schutz, der nicht auf Aufmerksamkeit oder Verhalten des Nutzers angewiesen ist
• Funktioniert auf Mobilgeräten: Keine langen Fingerdrücke oder komplexen Interaktionen nötig
• Adressiert Homograph-Angriffe: Verdächtige Domains werden sichtbar und können geprüft werden
• Zum Darstellungszeitpunkt umsetzbar: Browser-Erweiterungen und Mail-Client-Plugins können gerenderte Inhalte nachbearbeiten; Erstanbieter-Clients haben mehr Arbeit (Bereinigung, mobile UX, signierte Inhalte, Barrierefreiheit)
• Transportunabhängig: Wird beim Rendern der Nachricht angewendet, ohne den Nachrichtentransport zu ändern — wobei signierte oder besonders integritätssensible Mail-Flüsse weiterhin eine sorgfältige UX-Gestaltung erfordern

Schwächen und Kompromisse

• Erhebliche Verschlechterung der Benutzerfreundlichkeit: E-Mails werden unübersichtlicher und schwerer lesbar, insbesondere Marketing-E-Mails mit vielen Links
• Bricht legitime Marketing-Kampagnen: Tracking-URLs (z. B. Klick-Tracking in Newslettern) wirken verdächtig, selbst wenn sie harmlos sind
• Erhöht das visuelle Rauschen: Lange URLs verbrauchen Bildschirmplatz und mindern die Lesbarkeit
• Kann die Klickraten senken: Legitime Handlungsaufforderungen könnten an Resonanz verlieren, wenn Nutzer von den URL-Informationen überfordert werden
• Adressiert keine Kontokompromittierung: Kontrolliert ein Angreifer eine legitime Domain, wirkt die URL auch bei Anzeige vertrauenswürdig
• Nutzeraufklärung weiterhin nötig: Nutzer müssen verstehen, was eine verdächtige Domain ausmacht

Umsetzungsansätze

E-Mail-Programme könnten dies auf verschiedene Weisen umsetzen:

• Vollständige URL-Anzeige: Die komplette URL für jeden Link anzeigen
• Nur-Domain-Anzeige: Nur die Domain anzeigen, was die Unübersichtlichkeit verringert und den Sicherheitsgewinn erhält
• Hervorhebung externer Links: URLs nur für Links anzeigen, die aus der Domain des Absenders herausführen
• Einstellung nach Nutzerpräferenz: Nutzern erlauben, sich an- oder abzumelden (was die Wirksamkeit für weniger technisch versierte Nutzer allerdings verringert)

Was es nicht löst

Die URL immer anzuzeigen, schlägt die Anzeigetext-Diskrepanz, ist aber kein Allheilmittel. Zwei Techniken, die im Verlauf von 2026 stark zunehmen, umgehen es vollständig:

• OAuth-Device-Code-Phishing: In einer Ende April 2026 aufgedeckten Kampagne gaben die Tycoon2FA-Betreiber gefälschte Login-Seiten gänzlich auf. Das Opfer wird gebeten, einen kurzen Code auf der echten Seite microsoft.com/devicelogin einzugeben; Microsoft übernimmt dann die Authentifizierung, einschließlich MFA, und stellt unwissentlich OAuth-Token für ein vom Angreifer kontrolliertes Gerät aus^[9]. Die Anzeige der URL offenbart eine legitime Microsoft-Domain, sodass es nichts Verdächtiges zu kennzeichnen gibt.
• QR-Code-Phishing („Quishing“): Das Ziel ist in einem Bild eingebettet statt in einem Anker-Tag, sodass es überhaupt keinen Linktext und keine URL gibt, die der Client anzeigen könnte. Microsoft verzeichnete im ersten Quartal 2026 einen Anstieg des QR-Code-Phishings um 146 %, von 7,6 Millionen auf 18,7 Millionen Nachrichten^[6].

Beide sind Varianten des Adversary-in-the-Middle-Phishings, bei dem der Angreifer eine laufende Authentifizierungssitzung weiterleitet und Token statt Passwörter abfängt. Stets sichtbare URLs erhöhen die Hürde gegen die häufigsten Angriffe, aber sie verstärken die Notwendigkeit mehrschichtiger Verteidigung, statt sie zu ersetzen.

Alternative Strategien

Die URL immer anzuzeigen, ist ein Ansatz, aber nicht die einzige Möglichkeit. Im Folgenden finden Sie mehrere Alternativen, jede mit unterschiedlichen Kompromissen zwischen Sicherheit und Benutzerfreundlichkeit.

Nur Links zur selben Domain (verifizierte Absender)

E-Mail-Programme könnten eine Richtlinie durchsetzen, nach der authentifizierte Absender nur Links zu ihrer eigenen Domain einfügen dürfen. Ist eine E-Mail von bank.com DMARC-authentifiziert, darf sie Links zu bank.com enthalten, aber nicht zu Drittanbieter-Domains.

Vorteile: Verhindert direkte Links zu offensichtlich verdächtigen externen Domains. Erhält eine saubere Benutzerführung für interne Kommunikation. Nutzt die bestehende Authentifizierungsinfrastruktur. Kann unraffinierte Phishing-Versuche abfangen.

Nachteile: Verhindert keine Angriffe, die Tracking-URLs von E-Mail-Plattformen nutzen (wie das Klick-Tracking von SendGrid), die über vertrauenswürdige Domains umleiten. Bricht legitime Anwendungsfälle wie Newsletter, die auf Ressourcen verlinken, Partnerkommunikation, Inhaltsaggregation und geteilte Dokumente. Verhindert keine Subdomain-Übernahme-Angriffe. Kann den Einsatz von URL-Kürzern fördern und damit den Zweck untergraben. Erfordert eine strikte DMARC-Durchsetzung.

Machbarkeit: Mittel. Die technische Umsetzung ist unkompliziert, aber die Durchsetzung der Richtlinie schafft erhebliche Probleme bei der Benutzerfreundlichkeit.

Vollständige URL-Anzeige mit Klickbestätigung

Die URL anzeigen und vor dem Aufrufen eine ausdrückliche Bestätigung verlangen. Wenn ein Nutzer auf einen Link klickt, einen Dialog anzeigen: „Sie sind im Begriff, https://example.com zu besuchen. Fortfahren?“

Vorteile: Erhält die Linkfunktion mit ausdrücklicher Einwilligung des Nutzers. Lehrreich: Es schult Nutzer darin, URLs zu prüfen. Kann mit Positivlisten für vertrauenswürdige Domains konfiguriert werden.

Nachteile: Klick-Ermüdung: Nutzer bestätigen automatisch, ohne zu lesen, genau wie bei anderen Sicherheitsdialogen. Verdoppelt die Interaktionskosten für jeden E-Mail-Link. Schreckliche Benutzerfreundlichkeit auf Mobilgeräten. Verhindert keine raffinierten Angriffe, weil Nutzer Bestätigungsdialoge nicht sorgfältig lesen.

Machbarkeit: Technisch hoch, aber sehr geringe Nutzerakzeptanz. Die Bestätigungsermüdung macht dies weitgehend unwirksam.

Abgestufte URL-Anzeigerichtlinie

Konfigurierbare Anzeigemodi umsetzen, die es Nutzern ermöglichen, ihr Sicherheitsniveau zu wählen:

Strikter Modus Sicherheitsorientierte Nutzer	Ausgewogener Modus Empfohlene Standardeinstellung	Freizügiger Modus UX-orientierte Nutzer
→ https://example.com/verify?token=abc123 [Konto verifizieren]	→ example.com (gleiche Domain) [Konto verifizieren] → external-site.com (abweichend) [Hier klicken]	(URL verborgen, beim Hovern sichtbar) [Konto verifizieren]
Vollständige URL stets sichtbar	Domain nur für externe Links anzeigen	Aktuelles Verhalten, manuelle Prüfung

Vorteile: Hält Sicherheit und Benutzerfreundlichkeit in der Waage. Nutzer können ihre Präferenz wählen. Organisationen können Richtlinien für unterschiedliche Nutzergruppen durchsetzen. Der ausgewogene Modus bietet wirksamen Schutz ohne überwältigende Unübersichtlichkeit.

Nachteile: Erfordert Aufmerksamkeit der Nutzer, um angemessen konfiguriert zu werden. Weniger technisch versierte Nutzer wählen möglicherweise den freizügigen Modus und bleiben verwundbar. Komplexität in Umsetzung und Nutzeraufklärung.

Machbarkeit: Mittel. Die Umsetzung ist unkompliziert, aber das Bewusstsein der Nutzer für die Konfiguration und die Aufklärung sind herausfordernd.

Risikobewertung von Links mittels maschinellem Lernen

ML-Modelle trainieren, um das Risiko eines Links anhand von Domain-Reputation, Absenderhistorie, Mustern der Text-/URL-Diskrepanz, lexikalischer Analyse von Domains und historischem Klickverhalten zu bewerten. Risikobewertungen oder Warnungen nur für verdächtige Links anzeigen.

Vorteile: Automatisierte Erkennung, ohne legitime Anwendungsfälle zu brechen. Passt sich an sich entwickelnde Angriffsmuster an. Skaliert gut über große Organisationen hinweg. Kann mehrere Signale kombinieren (Absenderreputation, Domainalter, Textähnlichkeit usw.).

Nachteile: Falschpositive sind ein erhebliches Problem: Als verdächtig gekennzeichnete legitime Links verursachen Nutzerermüdung und untergraben das Vertrauen in das System. Nutzer lernen, Warnungen zu ignorieren, was die Wirksamkeit mit der Zeit verringert. Falschnegative erzeugen Risiken. Erfordert umfangreiche Trainingsdaten und fortlaufende Feinabstimmung. Angreifer können potenziell lernen, ML-Modelle zu umgehen. Komplexe Umsetzung, die ML-Infrastruktur erfordert.

Machbarkeit: Mittel. Große E-Mail-Anbieter verfügen über die Daten und Ressourcen, aber die Ermüdung durch Falschpositive begrenzt die Wirksamkeit in der Praxis erheblich.

Verbesserte mobile Hover-UX

Die mobile Linkvorschau-Funktion verbessern. Statt einen langen Fingerdruck zu verlangen, neben jedem Link ein kleines Domain-Abzeichen anzeigen. Das Tippen auf den Link führt zur Navigation; das Tippen auf das Abzeichen zeigt die vollständigen URL-Details.

Vorteile: Verbessert die mobile Sicherheit ohne Auswirkungen auf den Desktop. Bietet sofortige Domain-Sichtbarkeit. Erhält die aktuelle Benutzerführung und erhöht zugleich die Sicherheit.

Nachteile: Erfordert weiterhin Aufmerksamkeit und Handeln des Nutzers. Erhöht die visuelle Komplexität der Linkdarstellung. Kann für weniger technisch versierte Nutzer verwirrend sein. Adressiert keine Desktop-Schwachstellen.

Machbarkeit: Hoch. Relativ einfache clientseitige Umsetzung mit erheblichem Sicherheitsgewinn auf Mobilgeräten.

Kryptografische Linksignierung (DKIM für URLs)

Was wäre, wenn Links in E-Mails kryptografisch signiert werden könnten, ähnlich wie DKIM E-Mail-Kopfzeilen und -Inhalt signiert? Ein Absender könnte jede URL in seiner E-Mail signieren, und das E-Mail-Programm des Empfängers würde diese Signaturen überprüfen, bevor es die Navigation zulässt.

Wie es funktionieren würde: Ein neuer DNS-Eintragstyp (z. B. ein EMLNK- oder _linkkey-TXT-Eintrag) würde den öffentlichen Schlüssel für die Überprüfung von E-Mail-Links veröffentlichen, ähnlich wie DKIM _domainkey-Einträge nutzt. Entscheidend ist, dass dies getrennt von DKIM wäre: Die DKIM-Signierschlüssel liegen auf dem Mailserver und sollten für E-Mail-Anwendungen nicht zugänglich sein. Die Schlüssel zur Linksignierung würden von den E-Mail-Verfassungssystemen der Organisation oder vom E-Mail-Dienstanbieter verwaltet.

Beim Verfassen einer E-Mail würde die versendende Anwendung jede URL mit dem privaten Linksignierschlüssel der Domain signieren. Diese Signaturen könnten als separater MIME-Teil eingebettet werden (z. B. application/link-signatures) oder als data-signature-Attribute an Anker-Tags. Das empfangende E-Mail-Programm würde den öffentlichen Schlüssel aus dem DNS abrufen (z. B. _linkkey.example.com) und jede Signatur überprüfen, bevor es die Navigation zulässt.

Wenn die Signatur eines Links nicht überprüft werden kann — weil die URL verändert, eingeschleust oder vom Absender gar nicht aufgenommen wurde —, könnte das E-Mail-Programm den Nutzer warnen, den Link deaktivieren oder ihn anders darstellen.

Vorteile: Belegt kryptografisch die Echtheit eines Links. Verhindert Angriffe durch Linkeinschleusung und -veränderung. Baut auf der bestehenden DKIM-Infrastruktur und Schlüsselverteilung auf. Funktioniert mit verschlüsselten E-Mails. Erfordert keine Änderungen an der URL-Anzeige. Könnte als Erweiterung bestehender E-Mail-Standards umgesetzt werden.

Nachteile: Erfordert neue E-Mail-Standards und breite Einführung. Verhindert keine Angriffe über kompromittierte Konten (sie können schädliche Links mit gültigen Schlüsseln signieren). Komplexität der Umsetzung für E-Mail-Programme und -Server. Erfordert neue DNS-Infrastruktur und Eintragstypen. Herausforderungen bei der Abwärtskompatibilität mit bestehenden E-Mails. Kann legitime E-Mail-Weiterleitung und Mailinglisten-Szenarien brechen, in denen Inhalte verändert werden.

Machbarkeit: Kurzfristig niedrig bis mittel aufgrund des Standardisierungsbedarfs, aber potenziell hoher langfristiger Wert. Würde die Entwicklung eines IETF-RFC und die Einführung durch große E-Mail-Anbieter erfordern.

Vergleich der Gegenmaßnahmen

Strategie	Wirksamkeit	UX-Auswirkung	Machbarkeit	Nutzeraktion
URL immer anzeigen	●●● Hoch	●●● Erheblich	●● Einfach zu bauen, schwer einzuführen	Keine
Nur gleiche Domain	●● Mittel	●●● Bricht Arbeitsabläufe	●● Mittel	Keine
Klickbestätigung	● Niedrig	●●● Sehr hoch	●●● Hoch	Jeder Klick
Abgestufte Richtlinie	●●● Hoch	●● Konfigurierbar	●● Mittel	Konfiguration
ML-Risikobewertung	●● Mittel	● Minimal	●● Komplex	Keine
Kryptografische Linksignierung	●●● Hoch	● Keine	● Niedrig (neuer Standard)	Keine
Verbesserte mobile UX	●● Mittel	● Niedrig	●●● Hoch	Optional
Aktuell (Hover)	● Niedrig	● Keine	●●● Vorhanden	Manuell

Hürden bei der Einführung und Herausforderungen der Branche

Selbst wenn sich „URL immer anzeigen“ oder ähnliche Strategien als technisch wirksam erweisen, steht eine breite Einführung vor erheblichen Hürden.

Widerstand der Marketingabteilung

Marketing-Teams setzen stark auf Link-Ästhetik und Tracking. Eine Schaltfläche „Hier klicken, um Ihr Angebot einzulösen“ ist ansprechender als „→ tracking.mailchimp.com/c/eJw... [Hier klicken, um Ihr Angebot einzulösen]“. E-Mail-Marketing-Kennzahlen wie Öffnungsraten, Klickraten und Conversion könnten sinken, wenn URLs stets sichtbar sind, was internen Widerstand gegen die Umsetzung erzeugt.

Organisationen müssen Sicherheit gegen die Auswirkungen auf den Umsatz abwägen. Für viele Unternehmen hat eine Senkung der E-Mail-Conversion-Raten um 10 % direkte Folgen für das Ergebnis. Sicherheitsteams müssen einen klaren ROI oder Vorteile bei der Einhaltung regulatorischer Vorgaben nachweisen, um diesen Widerstand zu überwinden.

Bedenken bei der Benutzerfreundlichkeit

E-Mail ist ein Kommunikationsmedium, nicht nur ein Sicherheitsperimeter. Nutzer schätzen Lesbarkeit, Klarheit und Ästhetik. Stets sichtbare URLs verschlechtern das Leseerlebnis, insbesondere bei Newslettern, Zusammenfassungen und inhaltsreichen E-Mails. Wenn Nutzer E-Mails als schwerer lesbar empfinden, wenden sie sich möglicherweise gänzlich ab, was den Wert von E-Mail als Kommunikationskanal mindert.

Design-Teams werden sich gegen Änderungen wehren, die E-Mails objektiv hässlicher und weniger nutzbar machen. Sicherheitsverbesserungen, die die Benutzerfreundlichkeit erheblich beeinträchtigen, haben es bei der Nutzerakzeptanz schwer.

Erfordernis branchenweiter Koordination

E-Mail-Sicherheit hängt von Standards ab, die branchenweit übernommen werden. SPF, DKIM und DMARC waren erfolgreich, weil große Anbieter (Gmail, Outlook, Yahoo) sie alle umsetzten und durchsetzten. Eine ähnlich koordinierte Anstrengung wäre für URL-Anzeigerichtlinien nötig.

Wenn nur ein E-Mail-Anbieter „URL immer anzeigen“ umsetzt, könnten Nutzer einfach zu Anbietern mit besserer Benutzerfreundlichkeit wechseln. Standardisierungsgremien (IETF, Arbeitsgruppen für E-Mail-Programme) müssten Spezifikationen entwickeln, und große Anbieter müssten sie etwa im selben Zeitraum übernehmen.

Das Problem der Abwärtskompatibilität

Milliarden bestehender E-Mails enthalten Links, die für aktuelle Rendering-Engines formatiert sind. Eine Änderung der Linkdarstellung wirkt sich rückwirkend auf archivierte E-Mails, weitergeleitete Nachrichten und Konversationsverläufe aus. Dies sorgt für Verwirrung, wenn ältere E-Mails plötzlich anders dargestellt werden oder wenn Nutzer mit verschiedenen E-Mail-Programmen unterschiedliche Linkdarstellungen im selben Verlauf sehen.

Fazit und Handlungsaufforderung

E-Mail-Authentifizierungsstandards haben Domain-Spoofing erfolgreich adressiert, doch link-basiertes Phishing bleibt eine kritische Schwachstelle. Der SendGrid-Angriff zeigt, dass kompromittierte Konten auf vertrauenswürdigen Plattformen alle Authentifizierungsprüfungen umgehen können und den Nutzern nur die manuelle URL-Prüfung als Verteidigung lassen.

Würde das Linkziel immer angezeigt, ließe sich die Anzeigetext-Diskrepanz als Täuschungstechnik erheblich reduzieren — nicht jedoch Phishing über vertrauenswürdige Domains, QR-Codes oder OAuth-Device-Verfahren. Es lässt sich zum Darstellungszeitpunkt anwenden, geht aber mit echten Einbußen bei der Benutzerfreundlichkeit einher und steht vor erheblichen Einführungshürden.

Vielleicht liegt die Antwort nicht in einer einzelnen Lösung. Auch hier gilt das Prinzip der mehrschichtigen Verteidigung (Defense in Depth): Abgestufte Anzeigerichtlinien geben Nutzern die Wahl, ML-basierte Risikobewertung bietet automatisierte Erkennung, verbesserte mobile UX erleichtert die Prüfung, und branchenweite Standards könnten einen Basisschutz etablieren.

Klar ist: Nichts zu tun ist keine Option. Phishing wächst in Raffinesse und Ausmaß: Credential-Phishing sprang Ende 2024 um 703 %^[2], die Kosten von Datenpannen nähern sich 4,5 Mio. US-Dollar^[3], und Microsoft verzeichnete in einem einzigen Quartal 2026 8,3 Milliarden E-Mail-Phishing-Bedrohungen^[6]. Die Branche muss handeln.

Für Entwickler von E-Mail-Programmen: Erwägen Sie die Umsetzung abgestufter URL-Anzeigerichtlinien und einer verbesserten mobilen Prüf-UX. Diese bieten Sicherheitsgewinne bei konfigurierbarer UX-Auswirkung.

Für Sicherheitsteams: Bewerten Sie ML-basierte Risikobewertung von Links und setzen Sie strikte Link-Rewriting-Richtlinien durch. Schichten Sie Verteidigungen und verlassen Sie sich nicht allein auf das Verhalten der Nutzer.

Für Standardisierungsgremien: Stoßen Sie Diskussionen über URL-Anzeigestandards und Link-Sicherheitsprotokolle an. Die E-Mail-Sicherheit bedarf einer kontinuierlichen Weiterentwicklung.

Für Nutzer: Aktivieren Sie Linkvorschau-Funktionen, prüfen Sie URLs vor dem Klicken und setzen Sie sich für bessere Sicherheits-UX in Ihren E-Mail-Programmen ein.

Die Lücke zwischen Authentifizierung und Linksicherheit schließt sich nicht von selbst. Es ist an der Zeit, dass die Branche dieses Gespräch führt.

Quellen

1. Phishing actors exploit complex routing and misconfigurations to spoof domains. Microsoft Security Blog (Januar 2026). Microsoft Defender for Office 365 blockierte im Oktober 2025 über 13 Millionen schädliche E-Mails mit Bezug zu Tycoon2FA.
2. SlashNext 2024 Phishing Intelligence Report (PRNewswire). Credential-Phishing-Angriffe stiegen in der zweiten Jahreshälfte 2024 um 703 %.
3. IBM Cost of a Data Breach Report 2025. Weltweite durchschnittliche Kosten einer Datenpanne: 4,44 Millionen US-Dollar.
4. Complete Safe Links overview for Microsoft Defender for Office 365. Microsoft Learn. Dokumentation zur URL-Prüfung und -Umschreibung durch Safe Links, einschließlich der Grenzen hinsichtlich des Ablaufs von URLs und einmalig verwendbarer Links.
5. New Outlook not showing link URLs. Microsoft Tech Community. Nutzerdiskussionen über die fehlende URL-Hover-Vorschau in New Outlook, mit Sicherheitsbedenken zur Überprüfung von Links vor dem Klicken.
6. Email threat landscape: Q1 2026 trends and insights. Microsoft Security Blog (April 2026). 8,3 Milliarden E-Mail-basierte Phishing-Bedrohungen im 1. Quartal 2026 erkannt, davon 78 % link-basiert; QR-Code-Phishing stieg im Quartal um 146 %.
7. Phishing campaigns and BEC attacks through Amazon SES. Securelist (Kaspersky), 2026. Angreifer missbrauchen durchgesickerte AWS-Zugangsschlüssel, um vollständig authentifizierte Phishing- und BEC-Nachrichten über Amazon SES zu versenden, mit Seiten zum Abgreifen von Zugangsdaten, die auf amazonaws.com gehostet werden.
8. Tycoon2FA phishing-as-a-service platform persists following takedown. CrowdStrike (März 2026). Microsoft, Europol und Partner zerschlugen am 4. März 2026 330 aktive Tycoon2FA-Domains, doch das Kampagnenvolumen kehrte innerhalb weniger Tage auf das Niveau vor der Zerschlagung zurück.
9. Tycoon 2FA operators use OAuth device code phishing to bypass MFA. GBHackers (April 2026). Kampagne von Ende April 2026, die microsoft.com/devicelogin missbraucht, um OAuth-Token abzufangen, ohne eine gefälschte Login-Seite zu präsentieren.