FAQ & Hintergrund
Erklärungen zu E-Mail-Authentifizierung, den zugrundeliegenden Standards und warum das alles wichtig ist.
Was ist maildiag.de?
maildiag.de ist ein kostenloses, deutsches Diagnose-Tool für E-Mail-Infrastruktur. Es prüft die DNS-Konfiguration einer Domain auf korrekte E-Mail-Authentifizierung (SPF, DKIM, DMARC), analysiert E-Mail-Header auf Zustellprobleme und überprüft IP-Adressen gegen bekannte Blacklists.
Alle Abfragen werden direkt gegen die öffentlichen DNS-Server durchgeführt. Es werden keine E-Mails gespeichert oder weitergegeben. Der Dienst entspricht den Anforderungen der DSGVO und wird auf Servern in Deutschland betrieben.
Warum sind SPF, DKIM und DMARC wichtig?
Phishing & Spoofing
Ohne E-Mail-Authentifizierung kann jeder beliebige Absender eine E-Mail mit deiner Domain versenden. Angreifer nutzen das für Phishing-Angriffe, bei denen sie sich als dein Unternehmen ausgeben.
Zustellbarkeit
Große E-Mail-Anbieter wie Gmail, Microsoft und Yahoo lehnen seit 2024 E-Mails von Domains ohne korrekte SPF/DKIM/DMARC-Konfiguration ab oder stufen sie als Spam ein.
Compliance
Viele Compliance-Frameworks (ISO 27001, BSI IT-Grundschutz) und Versicherungsbedingungen für Cyber-Policen setzen eine korrekte E-Mail-Authentifizierung voraus.
SPF erlaubt dem Domaininhaber, in einem DNS-TXT-Record festzulegen, welche Mailserver berechtigt sind, E-Mails im Namen dieser Domain zu versenden. Empfangende Mailserver prüfen beim Eingang einer E-Mail, ob der sendende Server in diesem Record aufgeführt ist.
Ein typischer SPF-Record sieht so aus:
Das -all am Ende bedeutet: Alle nicht aufgeführten Server sollen abgelehnt werden (Hard Fail). ~all bedeutet Soft Fail (als Spam markieren), ?all ist neutral.
SPF ist in RFC 7208 definiert (April 2014). Der Vorgänger war RFC 4408 (2006, veraltet).
SPF prüft nur den technischen Absender (Envelope-From / Return-Path), nicht den sichtbaren Absender im E-Mail-Client (Header-From). Dafür ist DMARC notwendig.
DKIM fügt jeder ausgehenden E-Mail eine kryptografische Signatur hinzu. Der öffentliche Schlüssel wird im DNS der sendenden Domain veröffentlicht. Der empfangende Mailserver kann damit verifizieren, dass die E-Mail tatsächlich von der angegebenen Domain stammt und unterwegs nicht manipuliert wurde.
Die Signatur wird im E-Mail-Header als DKIM-Signature-Feld übertragen. Sie bezieht sich auf ausgewählte Header-Felder und den Body der E-Mail.
Der DNS-Record für einen DKIM-Schlüssel liegt unter [selector]._domainkey.[domain], z.B.:
DMARC baut auf SPF und DKIM auf und erlaubt dem Domaininhaber, eine Richtlinie (Policy) zu definieren, was mit E-Mails passieren soll, die die SPF- oder DKIM-Prüfung nicht bestehen. Außerdem ermöglicht DMARC das Empfangen von Berichten über fehlgeschlagene Authentifizierungen.
DMARC führt das Konzept der Alignment ein: Die Domain im sichtbaren Absender (Header-From) muss mit der SPF- oder DKIM-Domain übereinstimmen. Damit schließt DMARC die Lücke, die SPF allein lässt.
Ein typischer DMARC-Record:
Nur Monitoring. E-Mails werden nicht beeinflusst. Empfohlen als erster Schritt.
Fehlschlagende E-Mails werden in den Spam-Ordner verschoben.
Fehlschlagende E-Mails werden vollständig abgelehnt. Maximaler Schutz.
DMARC kennt zwei Arten von Berichten, die an den Domaininhaber gesendet werden können:
Tägliche Zusammenfassungen: Welche Server haben E-Mails im Namen deiner Domain verschickt? Enthält keine personenbezogenen Daten — nur IP-Adressen und Statistiken. Empfehlenswert für die Überwachung der eigenen E-Mail-Infrastruktur.
Einzelberichte bei fehlgeschlagener Authentifizierung. Können Kopien des E-Mail-Headers oder sogar des Inhalts enthalten — und damit personenbezogene Daten (z. B. Absender, Betreff).
Da Forensic Reports personenbezogene Daten enthalten können, ist es aus datenschutzrechtlicher Sicht (DSGVO) empfehlenswert, ruf= wegzulassen. Viele große Provider (z. B. Google, Microsoft) senden ohnehin keine Forensic Reports mehr. maildiag.de bewertet ein fehlendes ruf= daher positiv.
rua= setzen für Aggregate Reports, ruf= weglassen für maximalen Datenschutz.
MX-Records (Mail Exchanger) sind DNS-Einträge, die festlegen, welche Mailserver für den Empfang von E-Mails einer Domain zuständig sind. Jeder MX-Record hat eine Priorität — bei mehreren Einträgen wird zuerst der mit der niedrigsten Prioritätsnummer verwendet.
example.com. MX 20 mail2.example.com.
Der Return-Path (auch Envelope-From oder MAIL FROM genannt) ist die technische Absenderadresse einer E-Mail. An sie werden Unzustellbarkeitsmeldungen (Bounces) zurückgeschickt, wenn die E-Mail nicht zugestellt werden kann. Er wird beim Versand auf SMTP-Ebene gesetzt und ist nicht zu verwechseln mit dem From-Header, den der Empfänger im Mailprogramm sieht.
Eine E-Mail hat also zwei Absenderangaben:
- Envelope-From / Return-Path — technisch, für Bounces und für die SPF-Prüfung relevant. Der Empfänger sieht ihn normalerweise nicht.
- Header-From (das
From-Feld) — der sichtbare Absender im Mailclient.
Versanddienstleister (z.B. Brevo, Mailchimp, sender.net) setzen den Return-Path bewusst auf eine eigene Domain, um Bounces zentral zu verarbeiten und die Zustellbarkeit zu überwachen. Beispiel: From: [email protected] bei Return-Path: bounces-…@gh.d.sender-sib.com. Das ist beabsichtigt und kein Sicherheitsproblem — entscheidend ist, dass SPF, DKIM und DMARC korrekt ausgerichtet sind.
Eine Abweichung kann ein Warnsignal sein, wenn sie nicht von einem bekannten Versanddienst stammt — etwa bei Phishing oder Spoofing, wo der sichtbare Absender gefälscht ist, der Return-Path aber auf eine fremde Domain zeigt. Maßgeblich ist deshalb nicht die Abweichung allein, sondern ob die E-Mail DMARC-konform ist: DMARC verlangt, dass entweder SPF (über den Return-Path) oder DKIM (über die From-Domain) passt und zur sichtbaren Absenderdomain ausgerichtet ist (Alignment). Schlägt DMARC fehl und weicht der Return-Path ab, ist erhöhte Vorsicht geboten.
Exchange Server und Exchange Online verwenden intern sogenannte LegacyExchangeDN-Adressen im X.500-Format, um Postfächer eindeutig zu identifizieren. Outlook und OWA cachen diese Adressen im Autovervollständigen-Cache.
Wenn sich das LegacyExchangeDN-Attribut eines Postfachs ändert — zum Beispiel bei einer Migration, einem Umzug zwischen Exchange-Organisationen oder einer Umbenennung — kann Outlook den Empfänger nicht mehr auflösen. Das Ergebnis ist ein 5.1.1 Non-Delivery Report (NDR) mit einer Fehleradresse, die mit IMCEAEX- beginnt.
Die IMCEAEX-Adresse ist die alte LegacyExchangeDN-Adresse in kodierter Form:
- Schrägstriche (
/) wurden durch Unterstriche (_) ersetzt - Sonderzeichen wurden als Hex-Codes kodiert (
+20= Leerzeichen,+28=(,+29=)usw.) - Das Präfix
IMCEAEX-und das Suffix@domain.comwurden hinzugefügt
Lösung: Die ursprüngliche X500-Adresse rekonstruieren und als zusätzliche Proxyadresse vom Typ X500 am betroffenen Postfach eintragen. Danach den Autovervollständigen-Cache in Outlook löschen.
→
X500:/O=MMS/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=User123
maildiag.de bietet einen X500-Adress-Konverter, der die IMCEAEX-Adresse aus dem NDR automatisch in die korrekte X500-Proxyadresse umwandelt — inklusive fertigem PowerShell-Befehl.
Beschrieben in Microsoft Learn: IMCEAEX NDR. Das X.500-Adressformat ist in ITU-T X.500 definiert.
MTA-STS (Mail Transfer Agent Strict Transport Security) erlaubt Domaininhabern, sendende Mailserver anzuweisen, TLS-Verschlüsselung beim E-Mail-Empfang zu erzwingen. Ohne MTA-STS könnten Angreifer TLS durch einen Man-in-the-Middle-Angriff deaktivieren — der sendende Server würde die E-Mail dann unverschlüsselt zustellen, ohne es zu merken.
MTA-STS besteht aus zwei Komponenten: einem DNS-TXT-Record und einer Policy-Datei, die per HTTPS abgerufen wird.
mode: enforce
mx: mail.example.com
max_age: 604800
Nur Monitoring. Verstöße werden per TLS-RPT gemeldet, E-Mails nicht blockiert. Empfohlen als erster Schritt.
TLS wird erzwungen. E-Mails ohne gültiges TLS werden abgelehnt. Maximaler Schutz.
Policy deaktiviert. Wird verwendet um MTA-STS abzuschalten.
Die ID im DNS-Record muss bei jeder Änderung der Policy-Datei geändert werden — nur dann laden sendende Server die neue Policy neu.
TLS-RPT (RFC 8460) ergänzt MTA-STS um ein Reporting-System: Sendende Mailserver schicken Berichte über TLS-Verbindungsfehler an eine konfigurierte Adresse.
Damit eine Domain mit Microsoft 365 (Exchange Online, Teams) funktioniert, müssen mehrere DNS-Einträge gesetzt sein. Der Microsoft 365 DNS-Check prüft diese automatisch und erkennt den Tenant aus dem DKIM-Eintrag.
| Eintrag | Soll-Wert | Zweck |
|---|---|---|
| MX | <token>.mail.protection.outlook.com oder <token>.mx.microsoft |
Eingehende E-Mails an Exchange Online routen. (Beide Formate sind gültig.) |
| SPF (TXT) | v=spf1 include:spf.protection.outlook.com -all | Autorisiert die M365-Server als Absender. Nur EIN SPF-Record pro Domain. |
| Autodiscover (CNAME) | autodiscover → autodiscover.outlook.com | Automatische Outlook-Konfiguration für Nutzer. |
| DKIM (2× CNAME) | selector1/2._domainkey → ...<tenant>.onmicrosoft.com | Signiert ausgehende E-Mails. Muss im Defender-Portal aktiviert werden. |
| Teams (SRV, optional) | _sipfederationtls._tcp → sipfed.online.lync.com:5061 | Nur für Teams/Skype-Föderation mit externen Organisationen. M365 funktioniert auch ohne. |
| Teams/SfB Legacy (optional) | sip → sipdir.online.lync.com lyncdiscover → webdir.online.lync.com _sip._tls → sipdir.online.lync.com:443 |
Aus der Skype-for-Business-Ära. Für reine Teams-only-Tenants nicht mehr erforderlich (SfB-Abschaltung 2021). Schaden aber nicht, wenn vorhanden. |
| Intune / MDM (optional) | enterpriseregistration → enterpriseregistration.windows.net enterpriseenrollment → enterpriseenrollment-s.manage.microsoft.com |
Nur nötig, wenn Windows-Geräte automatisch über Intune / Entra verwaltet werden (Autopilot, MDM-Enrollment). Ohne Geräteverwaltung nicht erforderlich. |
MX und DKIM enthalten den tenantspezifischen Namen (<tenant>.onmicrosoft.com). Die exakten Werte stehen im Microsoft 365 Admin Center unter Einstellungen → Domains. Der DNS-Check leitet den Tenant automatisch aus dem DKIM-Eintrag ab, sofern vorhanden.
Fehlt der DKIM-Eintrag, kann der Tenant über die Option „Tenant über Microsoft ermitteln" bestimmt werden — sie liefert Tenant-Anzeigename, Tenant-ID und Typ (Managed/Federated). Hinweis: Diese optionale Abfrage kontaktiert öffentliche Microsoft-Login-Endpoints (USA) mit dem Domainnamen. Es wird kein echter Nutzer und kein personenbezogenes Login übertragen (fester Platzhalter user@). Standardmäßig ist die Option deaktiviert — der normale DNS-Check kommt ohne Drittanbieter aus.
Microsoft Learn: External DNS records required for Microsoft 365.
DNSSEC (DNS Security Extensions) signiert DNS-Einträge kryptografisch. Ein validierender Resolver kann so prüfen, ob eine DNS-Antwort wirklich vom autoritativen Nameserver stammt und unterwegs nicht verändert wurde. Ohne DNSSEC könnte ein Angreifer per DNS-Spoofing gefälschte Antworten einschleusen — etwa um MX-, SPF- oder TLSA-Records zu manipulieren.
maildiag.de zeigt an, ob die geprüfte Domain DNSSEC-signiert ist (anhand des AD-Flags eines validierenden Resolvers und vorhandener DS-Records in der übergeordneten Zone).
Die Felder eines DS-Records: Key-Tag (Verweis auf den Schlüssel), Algorithmus (z. B. 13 = ECDSAP256SHA256), Digest-Typ (z. B. 2 = SHA-256) und der Digest selbst.
DNSSEC ist in RFC 4033–4035 definiert. DNSSEC ist Voraussetzung dafür, dass DANE (siehe unten) verlässlich funktioniert.
DANE (DNS-based Authentication of Named Entities) hinterlegt im DNS einen Fingerabdruck des TLS-Zertifikats eines Mailservers — als TLSA-Record unter _25._tcp.<mailserver>. Sendende Server prüfen beim Verbindungsaufbau, ob das präsentierte Zertifikat zum hinterlegten Fingerabdruck passt. Das verhindert Man-in-the-Middle-Angriffe mit gefälschten Zertifikaten und erzwingt verschlüsselte Zustellung.
Die drei Zahlen: Usage (3 = DANE-EE, domaineigenes Zertifikat), Selector (1 = nur der öffentliche Schlüssel) und Matching-Type (1 = SHA-256). maildiag.de prüft die TLSA-Records für jeden MX-Server der Domain.
DANE ist nur vertrauenswürdig, wenn die Domain auch DNSSEC-signiert ist — sonst könnten die TLSA-Records selbst gefälscht werden. maildiag.de warnt, wenn DANE-Records ohne DNSSEC gefunden werden.
| RFC | Titel | Standard | Jahr |
|---|---|---|---|
| RFC 7208 | Sender Policy Framework (SPF) | SPF | 2014 |
| RFC 6376 | DomainKeys Identified Mail (DKIM) Signatures | DKIM | 2011 |
| RFC 8301 | DKIM Cryptographic Algorithm and Key Usage Update | DKIM | 2018 |
| RFC 8463 | A New Cryptographic Signature Method for DKIM (Ed25519) | DKIM | 2018 |
| RFC 7489 | Domain-based Message Authentication, Reporting, and Conformance (DMARC) | DMARC | 2015 |
| RFC 1035 | Domain Names — Implementation and Specification (inkl. MX) | DNS/MX | 1987 |
| RFC 7505 | A "Null MX" No Delivery Resource Record | DNS/MX | 2015 |
| RFC 8461 | SMTP MTA Strict Transport Security (MTA-STS) | MTA-STS | 2018 |
| RFC 8460 | SMTP TLS Reporting (TLS-RPT) | MTA-STS | 2018 |
maildiag.de prüft IP-Adressen aus dem E-Mail-Pfad gegen folgende 22 DNS-basierte Blacklists (DNSBLs / RBLs). Eine Listung bedeutet nicht zwingend, dass E-Mails abgelehnt werden — das hängt von der Konfiguration des empfangenden Mailservers ab.
Hinweis: Die Spamhaus-Listen (ZEN, SBL, XBL, PBL) werden derzeit nicht geprüft. Die Abfrage über den kostenlosen Spamhaus-Dienst ist auf nicht-kommerzielle Eigen-Mailserver beschränkt; der Einsatz in einem öffentlichen Diagnose-Tool wie maildiag erfordert aus lizenzrechtlichen Gründen eine kommerzielle Spamhaus-DQS-Lizenz. Den Spamhaus-Status einer IP können Sie kostenlos direkt bei Spamhaus prüfen: check.spamhaus.org.
| Name | Zone | Beschreibung |
|---|---|---|
| Barracuda BRBL | b.barracudacentral.org | Weit eingesetzte Liste von Barracuda Networks. Wird von vielen Firmen-Mailgateways genutzt. |
| SpamCop BL | bl.spamcop.net | Listung basiert auf Nutzer-Spam-Reports. Listings verfallen automatisch nach kurzer Zeit (Stunden bis Tage). |
| CBL (Composite Blocking List) | cbl.abuseat.org | Listet ausschließlich IPs mit Botnet-/Malware-Aktivität. Sehr präzise, kaum False Positives. |
| UCEPROTECT Level 1 | dnsbl-1.uceprotect.net | Listet einzelne IPs, die direkt Spam versenden. Automatisches Delisting nach 7 Tagen ohne Spam-Aktivität. |
| UCEPROTECT Level 2 | dnsbl-2.uceprotect.net | Listet ganze IP-Ranges (/24) wenn mehrere IPs im Subnet Spam senden. Kann zu False Positives bei Shared Hosting führen. |
| UCEPROTECT Level 3 | dnsbl-3.uceprotect.net | Listet ganze ASNs (Autonome Systeme / Provider). Hohe False-Positive-Rate — nur als Hinweis zu werten. |
| SORBS SPAM | spam.sorbs.net | Spam and Open Relay Blocking System — allgemeine Spam-Liste. |
| SORBS HTTP | http.dnsbl.sorbs.net | Offene HTTP-Proxies, die für Spam missbraucht werden. |
| SORBS SOCKS | socks.dnsbl.sorbs.net | Offene SOCKS-Proxies. |
| SORBS SMTP | smtp.dnsbl.sorbs.net | Offene SMTP-Relays. |
| Mailspike BL | bl.mailspike.net | Reputation-basierte Liste von Mailspike. Wird u.a. von SpamAssassin verwendet. |
| Mailspike Z | z.mailspike.net | Zero Reputation — IPs ohne bekannte Reputation (kein aktives Listing, eher Hinweis). |
| PSBL (Passive Spam Block List) | psbl.surriel.com | Einfache, gut gepflegte Liste. Automatisches Delisting nach Inaktivität. |
| WPBL (Weighted Private BL) | db.wpbl.info | Kollaborative Liste auf Basis von Nutzer-Reports. Gut gepflegt, moderate Verbreitung. |
| GBUdb Truncate | truncate.gbudb.net | Reputationsdatenbank für Spam-Filter — enthält die schlechtesten IPs. |
| DroneBL | dnsbl.dronebl.org | Spezialisiert auf kompromittierte Systeme, Drohnen und Botnetze. |
| HostKarma Blacklist | hostkarma.junkemailfilter.com | Kollaborative Reputationsliste von JunkEmailFilter. |
| Invaluement ivmSIP | sip.invaluement.com | Fokussiert auf schwer erkennbaren Spam (Low-volume, High-precision). |
| SpamRats NOPTR | noptr.spamrats.com | IPs ohne Reverse-DNS (PTR-Record). Viele Mailserver lehnen solche IPs grundsätzlich ab. |
| SpamRats DYNA | dyna.spamrats.com | Dynamische/residentielle IPs, die vermutlich keine Mailserver sind. |
| SpamRats SPAM | spam.spamrats.com | IPs, die aktiv Spam senden. |
| Lashback UBL | ubl.unsubscore.com | Listet IPs, die E-Mails an abgemeldete Adressen senden (Unsubscribe-Missachtung). |
Der Score beim Blacklist-Check ist eine gewichtete Summe aller Blacklist-Einträge einer IP-Adresse. Jede Liste hat je nach Bedeutung und Reichweite eine Gewichtung — Listen, die von vielen großen Providern verwendet werden, fließen stärker ein als weniger verbreitete.
| Gewichtung | Punkte pro Eintrag | Bedeutung | Beispiele |
|---|---|---|---|
| Kritisch | 40 | Weitverbreitete Listen — Listung führt bei den meisten Providern zur Ablehnung | CBL, Barracuda BRBL |
| Hoch | 20 | Häufig genutzte Listen — Zustellung kann bei einigen Empfängern scheitern | SpamCop, Mailspike Z |
| Mittel | 10 | Selektiv eingesetzte Listen — Auswirkungen auf Zustellung sind variabel | SORBS, UCEPROTECT L2, Mailspike |
| Niedrig | 5 | Kaum genutzte Listen — in der Praxis selten ein Problem | UCEPROTECT L3, PSBL, Lashback |
Der Score ist die Summe der Punkte aller gelisteten Einträge. Bei 22 Einträgen mit kritischer Gewichtung würde der theoretische Maximalwert deutlich über 400 liegen. Ein Score über 100 gilt als kritisch für die E-Mail-Zustellbarkeit.
Hinweis: Der Score dient zur Orientierung, ersetzt aber keine manuelle Einschätzung. Manche Listen wie UCEPROTECT Level 3 listen absichtlich ganze Provider-Netze (ASNs) — ein Treffer dort ist daher mit Vorsicht zu bewerten und oft kein echtes Reputationsproblem der einzelnen IP.
Der Domain-Score bewertet die E-Mail-Sicherheitskonfiguration einer Domain. Die Grundbewertung umfasst 100 Punkte (MX, SPF, DKIM, DMARC). Für moderne Transportsicherheit (MTA-STS, DNSSEC, DANE) gibt es Bonuspunkte — der Score kann daher bis zu 115 Punkte erreichen.
| Kategorie | Punkte | Vergabe |
|---|---|---|
| MX | 10 | 10 Punkte, wenn mindestens ein MX-Record vorhanden ist. |
| SPF | bis 25 | pass/neutral +20, softfail +10. Zusätzlich +5, wenn der Record auf -all endet (Hard Fail). |
| DKIM | 20 | 20 Punkte, wenn mindestens ein gültiger DKIM-Selektor gefunden wird. |
| DMARC | bis 35 | p=reject +30, p=quarantine +20, p=none +5. Zusätzlich +5 für rua= (Reporting), −5 für ruf= (forensische Reports, Datenschutzrisiko). |
| MTA-STS (Bonus) | +10 | +10 Punkte, wenn eine MTA-STS-Policy im Modus enforce aktiv ist. |
| DNSSEC (Bonus) | +10 | +10 Punkte, wenn die Zone DNSSEC-signiert ist. |
| DANE (Bonus) | +5 | +5 Punkte, wenn mindestens ein MX TLSA-Records hat und DNSSEC aktiv ist. DANE ohne DNSSEC gibt keine Punkte (es wäre wirkungslos). |
A+ ab 100 · A ab 90 · B ab 75 · C ab 50 · D ab 25 · darunter F. Die Bonuspunkte (MTA-STS, DNSSEC, DANE) helfen, ein A+ auch dann sicher zu erreichen, wenn an anderer Stelle wenige Punkte fehlen.
Hinweis: Der Score ist eine Orientierungshilfe für die E-Mail-Sicherheit. Er bewertet die DNS-Konfiguration, nicht den tatsächlichen Versand. Bonus-Mechanismen wie DANE werden nur gewertet, wenn ihre Voraussetzung (DNSSEC) erfüllt ist.
Der Spam-Score im Header-Analyzer bewertet eine E-Mail anhand mehrerer Signale aus den Mail-Headern. Jedes Signal addiert Punkte — je mehr Punkte, desto verdächtiger die Nachricht. Der Score wird auf maximal 100 begrenzt.
| Signal | Punkte | Erklärung |
|---|---|---|
| X-Spam-Status: Yes | +40 | Empfangs-MTA hat die Nachricht bereits als Spam klassifiziert |
| X-Spam-Score ≥ 10 | +30 | Sehr hoher Spam-Score des Empfangs-MTA |
| X-Spam-Score ≥ 5 | +15 | Erhöhter Spam-Score des Empfangs-MTA |
| DMARC: fail | +25 | DMARC-Richtlinie ist fehlgeschlagen — Absender nicht autorisiert |
| SPF: fail | +20 | SPF-Prüfung fehlgeschlagen — IP nicht im SPF-Record autorisiert |
| Verdächtiger Header | +10–30 | Header typisch für Spam-Tools oder Massenversand-Software |
| X-Mailer: PHP/Perl/Bulk… | +20 | Massenversand-Software erkannt |
| DKIM: fail/permerror | +15 | DKIM-Signatur ungültig oder fehlerhaft |
| Message-ID fehlt | +10 | Spam-Sender lassen Message-ID häufig weg |
| SPF: softfail | +10 | IP liegt im ~all-Bereich (SoftFail) |
| Precedence: bulk/junk | +5 | Header kennzeichnet Massenversand |
| Score | Bewertung |
|---|---|
| 0–9 | Unauffällig |
| 10–24 | Wahrscheinlich legitim |
| 25–44 | Verdächtig |
| 45–69 | Wahrscheinlich Spam |
| 70–100 | Sehr wahrscheinlich Spam |
Der Score ist ein Hinweis, kein endgültiges Urteil. Eine legitime Marketing-E-Mail mit
Precedence: bulk bekommt automatisch +5 Punkte —
das ist kein Fehler, sondern erwartetes Verhalten.
„Ghost-Sender" ist eine im Juni 2026 von InfoGuard Labs veröffentlichte Fehlkonfiguration in Exchange Online. Nutzt eine Domain Microsoft 365 und ist zugleich ein externer Filter- oder Mail-Dienst davorgeschaltet (der MX-Eintrag zeigt also nicht direkt auf Microsoft), kann ein Angreifer E-Mails direkt an Exchange Online zustellen und damit den vorgeschalteten Filter umgehen.
Das Tückische: SPF, DKIM und DMARC schlagen dabei zwar fehl (die Prüfung meldet „Absender gefälscht"), die Nachricht wird aber trotzdem ohne Warnung im Posteingang zugestellt. So lassen sich beliebige Absender fälschen — interne Kollegen, die Geschäftsführung (CEO-Fraud) oder bekannte Firmen wie Microsoft.
Die üblichen Microsoft-365-Schutzeinstellungen (Standard-/Strict-Presets, Anti-Phishing-Richtlinien mit „DMARC beachten", einfacher Filter-Connector) verhindern Ghost-Sender nicht. Auch der Configuration Analyzer warnt nicht. Eine betroffene Organisation merkt von sich aus nichts.
Sind wir betroffen? Grundvoraussetzung sind zwei Punkte gleichzeitig: (1) E-Mail über Microsoft 365 / Exchange Online und (2) ein externer MX davor. Zeigt der MX direkt auf Microsoft (*.mail.protection.outlook.com), liegt die Grundvoraussetzung nicht vor.
Schutz: Eine der beiden von Microsoft empfohlenen Mitigationen einrichten — entweder ein Partner-Connector mit Wildcard und Ablehnung per IP/Zertifikat, oder eine Mailflow-Regel, die Nachrichten ohne den Header X-MS-Exchange-Organization-AuthAs: Internal bzw. aus nicht erlaubten IP-Ranges in Quarantäne legt. Zusätzlich Direct Send deaktivieren.
Mit dem Ghost-Sender-Test von maildiag.de lässt sich das Risikoprofil einer Domain einstufen und – mit Berechtigung – read-only prüfen, ob ein absichernder Connector aktiv ist.
Der Ghost-Sender-Test darf ausschließlich für Domains genutzt werden, für die eine ausdrückliche Beauftragung oder schriftliche Einwilligung des Domain-Inhabers vorliegt. Die aktive Prüfung erfolgt rein read-only — es wird zu keinem Zeitpunkt eine E-Mail versendet.
InfoGuard Labs: Ghost-Sender — Universal Email Spoofing against Exchange Online (09.06.2026). Test-Werkzeug der Forscher: ghost-sender.com.
Allgemein verständliche Hintergründe zu E-Mail-Spoofing: spoof-check.de.