Technische Details — E-Mail-Authentifizierung & Spoofing-Schutz

Die drei Säulen: SPF, DKIM, DMARC

E-Mail wurde ohne Absender-Authentifizierung entworfen – der angezeigte Absender (Header-From) ist frei wählbar. Drei aufeinander aufbauende Standards schließen diese Lücke:

SPF — Sender Policy Framework (RFC 7208)

Ein DNS-TXT-Eintrag legt fest, welche Server für eine Domain senden dürfen. Geprüft wird der technische Absender (Envelope-From), nicht der sichtbare Header-From.

v=spf1 include:spf.protection.outlook.com -all

-all = Hard Fail (alles Übrige ablehnen), ~all = Soft Fail. Pro Domain darf es nur einen SPF-Record geben.

DKIM — DomainKeys Identified Mail (RFC 6376)

Jede ausgehende Mail wird kryptografisch signiert; der öffentliche Schlüssel liegt im DNS unter <selector>._domainkey.<domain>. Der Empfänger verifiziert damit Echtheit und Unverändertheit.

DMARC — Domain-based Message Authentication (RFC 7489)

Verknüpft SPF und DKIM mit dem sichtbaren Absender (Alignment) und legt die Policy fest, was bei Nichtbestehen passiert.

v=DMARC1; p=reject; rua=mailto:dmarc@example.de; fo=1

p=reject ist das Ziel (Fälschungen werden abgewiesen), p=quarantine die Zwischenstufe, p=none nur Beobachtung ohne Schutz.

Typische Fehler

Mehrere SPF-Records – ungültig; alle Mechanismen müssen in einem Record stehen.
SPF mit mehr als 10 DNS-Lookups – führt zu PermError; include: sparsam halten.
DMARC bleibt auf p=none – bietet keinen Schutz, nur Reports.
Fehlendes Alignment – SPF/DKIM bestehen technisch, passen aber nicht zum sichtbaren Absender.
DKIM nicht aktiviert – bei Microsoft 365 muss DKIM bewusst eingeschaltet und per CNAME hinterlegt werden.

Weiterführend: MTA-STS, DANE, BIMI

Diese Mechanismen ergänzen die Authentifizierung um Transportverschlüsselung und Markenvertrauen:

MTA-STS – erzwingt TLS-verschlüsselten Transport zwischen Mailservern und verhindert Downgrade-Angriffe.
DANE (TLSA) – bindet das Server-Zertifikat per DNSSEC an die Domain; Alternative/Ergänzung zu MTA-STS.
BIMI – zeigt bei korrektem DMARC p=quarantine/reject das Markenlogo im Postfach an; setzt strikte Authentifizierung voraus.

Sonderfall: Ghost-Sender (Exchange Online)

Eine 2026 von InfoGuard Labs veröffentlichte Fehlkonfiguration. Tückisch, weil sie greift, obwohl SPF/DKIM/DMARC korrekt gesetzt sind.

Voraussetzung: Die Domain nutzt Microsoft 365 und hat einen externen Mail-/Filterdienst vorgeschaltet (der MX zeigt nicht direkt auf Microsoft). Dann nimmt Exchange Online Mail, die direkt an den Tenant-Endpunkt <tenant>.mail.protection.outlook.com zugestellt wird, standardmäßig an – am Filter vorbei. SPF/DKIM/DMARC schlagen zwar fehl, die Nachricht landet aber ohne Warnung im Postfach.

Warum DMARC hier nicht rettet: Die gefälschte Mail wird direkt an Exchange Online eingeliefert, wo die DMARC-Ablehnung in dieser Konstellation nicht greift. Der Schutz muss in Exchange Online erfolgen, nicht über DNS.

Schutzmaßnahme 1 — Partner-Connector mit IP-Beschränkung (empfohlen)

Ein Inbound-Connector vom Typ „Partner“ mit Wildcard, der nur Mail aus den IP-Bereichen des vorgeschalteten Filters akzeptiert und alles andere abweist:

New-InboundConnector -Name "Reject mail not via filter" `
  -ConnectorType Partner `
  -SenderDomains * `
  -SenderIPAddresses <Filter-IP-Ranges> `
  -RestrictDomainsToIPAddresses $true `
  -RequireTls $true

Robuster Indikator bei aktiver Mitigation: Exchange antwortet auf RCPT TO mit 550 5.7.51 TenantInboundAttribution.

Schutzmaßnahme 2 — Mailflow-Regel (Alternative)

Eine Transportregel (Priorität 0) quarantäniert jede Nachricht, die nicht aus erlaubten IP-Ranges stammt bzw. nicht den Header X-MS-Exchange-Organization-AuthAs: Internal trägt.

Zusätzlich: Direct Send deaktivieren

Set-OrganizationConfig -RejectDirectSend $true

Schließt das Fälschen interner Absender. Achtung: vorher prüfen, ob Geräte/Anwendungen (Drucker mit Scan-to-Mail, Monitoring, Branchensoftware) legitim per Direct Send senden – diese sonst auf authentifizierten Versand umstellen.

Hybrid-Umgebungen: Vor jeder Sperre die legitimen Sendepfade erheben (Filter-IPs, lokaler Exchange-/Hybrid-Connector, Direct-Send-Geräte). Sonst bricht der interne Mailfluss. Empfehlung: zunächst im Quarantäne-/Beobachtungsmodus starten und den Message-Trace kontrollieren.

Was NICHT gegen Ghost-Sender hilft

DMARC p=reject allein (greift bei Direkteinlieferung nicht).
Standard- oder Strict-Schutz-Presets in Microsoft 365.
Anti-Phishing-/Anti-Spam-Richtlinien mit „DMARC beachten“.
Ein einfacher „Your Organization“-Connector ohne IP-/Zertifikats-Restriktion.

Prüf-Tools

Kostenlose Werkzeuge zum Prüfen der eigenen (autorisierten) Domains:

Ghost-Sender-TestPrüft Exchange-Online-Tenants read-only auf die Schwachstelle Microsoft-365-CheckMX, SPF, Autodiscover, DKIM, Teams Domain-CheckSPF, DKIM, DMARC, MX, DNSSEC, DANE, MTA-STS DMARC-AnalyzerAggregate-Reports auswerten

Hinweis: Prüfen Sie ausschließlich Domains, für die Sie autorisiert sind. Aktive Tests dürfen nur mit Beauftragung oder Einwilligung des Domain-Inhabers erfolgen.

Quelle zur Ghost-Sender-Schwachstelle: InfoGuard Labs, „Ghost-Sender – Universal Email Spoofing against Exchange Online“ (09.06.2026). RFC-Referenzen: 7208 (SPF), 6376 (DKIM), 7489 (DMARC).

Technische Details: E-Mail-Authentifizierung & Spoofing-Schutz