Am 24. Juni landete eine Mail in einem unserer Test-Postfächer. Absender: konto-aktualisierung@amazon.de. Betreff: „Verifizieren Sie Ihr neues Amazon-Konto”. Ein Klick, eine Login-Maske, und die Zugangsdaten wären beim Angreifer gewesen.
Klassische Spam-Filter hätten das durchgewunken: kein „VIAGRA”, keine krude Sprache, saubere Amazon-Absender-Domain im Header. Genau deshalb macht MailGuard etwas anderes — statt einer einzigen Bewertung stapelt es sechs unabhängige Signale und lässt jedes für sich sprechen.
Warum ein einzelnes Signal nicht reicht
Phishing hat sich professionalisiert. Angreifer kopieren Corporate-Design pixelgenau, formulieren korrektes Deutsch, buchen sich TLS-Zertifikate für ihre Fake-Domains. Ein Filter, der nur auf Sprachauffälligkeiten schaut, ist heute zu 90 % blind.
Gleichzeitig ist der umgekehrte Fehler mindestens so schlimm: Wenn dein Filter jede zweite legitime Rechnung als Verdacht markiert, klickst du irgendwann alles weg — und verpasst dann die eine echte Phishing-Mail dazwischen.
Der Ausweg: viele schwache Signale zu einem starken Gesamtbild kombinieren. Kein Einzelsignal darf allein die Entscheidung tragen, aber jedes bringt einen unabhängigen Blickwinkel mit.
Signal 1: Heuristik auf unserem deutschen Server
Bewährtes Handwerk. Ein Regelwerk aus mehreren hundert Mustern, die lokal auf unserem deutschen Server laufen. Was fällt hier auf:
- Brand-Impersonation: „Amazon” im Absendernamen, aber die eTLD+1 stimmt nicht mit den offiziellen Amazon-Domains überein.
- Anti-Detection-Tricks: „E A S Y B A N K” statt „EASYBANK”, um Filterregeln zu umgehen.
- Credential-Keywords im URL-Pfad: „/login”, „/verify”, „/reset-password”.
- Dringlichkeits-Wortlaut: „innerhalb 24 Stunden”, „sofort verifizieren”, „Konto wird gesperrt”.
Diese Stufe verlässt niemals unseren Server — keine externe Übermittlung, kein Cloud-Call.
Signal 2: SPF, DKIM, DMARC
Das eigentliche Killer-Signal gegen Absender-Spoofing. Jede Mail bringt einen Authentication-Results-Header mit, den unser Mailserver bei Empfang setzt. Er dokumentiert drei Prüfungen:
- SPF — hat der einliefernde Mailserver überhaupt das Recht, Mails für die Absender-Domain zu verschicken?
- DKIM — stimmt die kryptografische Signatur der Mail mit dem öffentlichen Schlüssel der Absender-Domain überein?
- DMARC — was sagt der Domain-Inhaber selbst, wenn eine dieser Prüfungen fehlschlägt?
Ein Angreifer, der sich als amazon.de ausgibt, kann SPF und DKIM technisch nicht bestehen — er hat weder die Berechtigung noch den privaten Schlüssel. Amazons DMARC-Policy sagt explizit: „quarantäne oder ablehnen, was nicht von uns kommt”. Wenn hier fail steht, ist die Sache im Grunde entschieden.
MailGuard vergibt für DMARC-Fail +45 Punkte auf einer 0–100-Skala. Zusammen mit auch nur einem weiteren Signal reicht das für „suspicious”.
Signal 3: URLhaus — die Live-Blocklist der Sicherheits-Community
URLs aus dem Mailtext werden gegen die Live-Blocklist von URLhaus (abuse.ch, Berner Fachhochschule) geprüft. URLhaus wird von einer weltweiten Community von Sicherheitsforschern gepflegt — sobald eine neue Phishing-Kampagne beobachtet wird, taucht die URL dort binnen Minuten auf.
Kostenlos, kein API-Schlüssel, in der Schweiz gehostet (EU-Angemessenheitsbeschluss). Ein Match bedeutet in aller Regel: eindeutig bösartig.
Signal 4: Google Safe Browsing
Derselbe Threat-Feed, den auch Chrome nutzt, wenn eine „diese Seite könnte unsicher sein”-Warnung erscheint. Google pflegt eine der größten Threat-Datenbanken der Welt und stellt sie über eine kostenlose API bereit.
Wir übermitteln nur die URL, keinen Betreff, kein Body, keinen Absender. Ein Match ist ein starkes Signal — Chrome-Nutzer würden vor derselben Domain schon vor dem Klick gewarnt.
Signal 5: AbuseIPDB — Reputation der Origin-IP
Der Mailserver, der uns eine Mail einliefert, hinterlässt seine IP im Received-Header. Diese IP prüfen wir gegen AbuseIPDB, eine Community-Datenbank, in der Netzwerkbetreiber weltweit Angriffe melden.
- Confidence-Score 85–100: der Server ist bekannt für Phishing, Brute-Force, Spam — +60 Punkte.
- 50–84: verdächtig, aber nicht bewiesen — +40 Punkte.
- Unter 50: normales Hintergrundrauschen, kein Score-Beitrag.
Signal 6: Die !tdatex KI
Wenn die ersten fünf Signale zusammen im Graubereich landen (Score 30–69), aktivieren wir zusätzlich die !tdatex KI. Sie bewertet Betreff und Body im Kontext, erkennt subtile Sprachauffälligkeiten und Marken-Imitation, die keine Regel je vollständig abdecken könnte.
Die KI ist bewusst konservativ kalibriert. Sie sagt nicht: „Alles, was ‘Rechnung’ im Betreff hat, ist Phishing.” Sie sagt: „Wenn die Absender-Domain nicht zur behaupteten Marke passt, wenn Credential-Aufforderung mit URL-Spoofing kombiniert wird, wenn Dringlichkeit und finanzieller Kontext zusammenkommen — dann ist das verdächtig.”
Der KI-Deep-Scan läuft nur bei den 5–10 % aller Mails, die im Graubereich liegen. Damit bleiben die Kosten überschaubar und der Datenschutz-Fußabdruck klein.
Wie werden die Signale kombiniert?
Additiv, mit Kappung bei 100. Ein einzelnes Signal reicht selten für eine harte Entscheidung — aber DMARC-Fail + URLhaus-Hit sind zusammen bereits 100 Punkte, also „dangerous”. Die Verdict-Schwellen sind bewusst großzügig:
- 0–49 Punkte: clean.
- 50–69: suspicious (Warnhinweis in der Inbox, Mail bleibt zustellbar).
- 70–100: dangerous (Quarantäne mit 7-Tage-Undo).
Zurück zur Amazon-Mail vom 24. Juni
- Heuristik erkannte „verifizieren” im Betreff → +15
- Der DMARC-Header sagte
fail action=none→ +45 - Google Safe Browsing kannte die Verifikations-URL noch nicht (frisch registrierte Domain) → +0
- URLhaus auch nicht → +0
- AbuseIPDB flaggte die Origin-IP nicht → +0
- Die !tdatex KI erkannte „Marken-Imitation Amazon mit URL-Spoofing” → +98
Endverdict: dangerous, 100 von 100. Die Mail landete in der Quarantäne — bevor der Empfänger sie überhaupt gesehen hat.
Fazit
Kein einzelnes Signal ist perfekt. SPF/DMARC lässt sich manchmal aus wilder Konfiguration heraus austricksen. URL-Blocklisten hinken frisch registrierten Domains hinterher. Auch die beste KI hat Fehlerraten. Aber sechs unabhängige Signale zusammen fangen fast alles ab — und lassen legitime Mails in Ruhe.
MailGuard bringt genau diesen Stack in dein WordPress-Backend. Free-Plan: Heuristik + SPF/DKIM/DMARC + URLhaus. Bezahlte Pläne: zusätzlich Google Safe Browsing + AbuseIPDB + !tdatex KI-Deep-Scan.
MailGuard im itdatex-Shop ansehen · MailGuard SaaS auf guard.itdatex.support