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 9989)

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

Seit Mai 2026 ist DMARC ein IETF-Standard: RFC 9989 (Protokoll) ersetzt die bisherige RFC 7489, die Berichte sind in RFC 9990 (Sammelberichte, rua) und RFC 9991 (Fehlerberichte, ruf) beschrieben. Bestehende Einträge bleiben gültig. Entfallen ist pct=; für einen Testbetrieb gibt es jetzt t=y. Neu ist np= für nicht existierende Subdomains.

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.

Abfragen per dig

So liest du die drei Einträge einer Domain auf der Kommandozeile aus:

$ dig +short TXT example.de
"v=spf1 include:spf.protection.outlook.com -all"

$ dig +short TXT _dmarc.example.de
"v=DMARC1; p=reject; rua=mailto:dmarc@example.de; fo=1"

$ dig +short TXT selector1._domainkey.example.de
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC…"

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.

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.

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:

Quelle zur Ghost-Sender-Schwachstelle: InfoGuard Labs, „Ghost-Sender – Universal Email Spoofing against Exchange Online“ (09.06.2026). RFC-Referenzen: 7208 (SPF), 6376 (DKIM), 9989 (DMARC), 9990 und 9991 (DMARC-Berichte; Vorgänger: 7489).