E-Mail-Authentifizierung

Ausführliche Erklärung

E-Mail-Authentifizierung schützt Unternehmen davor, dass Fremde im Namen der eigenen Domain schreiben (Domain-Spoofing), und sorgt gleichzeitig dafür, dass legitime Nachrichten beim Empfänger ankommen. Drei Verfahren bilden das Fundament: SPF (Sender Policy Framework) legt über einen DNS-Eintrag fest, welche Mailserver im Namen einer Domain senden dürfen. DKIM (DomainKeys Identified Mail) signiert ausgehende Nachrichten kryptografisch, sodass Empfänger Veränderungen erkennen und die signierende Domain verifizieren können. DMARC (Domain-based Message Authentication, Reporting & Conformance) baut auf beiden auf, verlangt die Übereinstimmung mit der sichtbaren Absenderadresse („Alignment“) und legt fest, wie empfangende Server mit nicht authentifizierten Nachrichten umgehen sollen: annehmen (p=none), in Quarantäne verschieben (p=quarantine) oder abweisen (p=reject).

Seit 2024 ist das keine Kür mehr. Google und Yahoo verlangen seit Februar 2024 von Massenversendern ab rund 5.000 Nachrichten pro Tag SPF, DKIM und eine gültige DMARC-Richtlinie. Microsoft hat am 5. Mai 2025 mit derselben Schwelle für Outlook.com, Hotmail.com und Live.com nachgezogen und stellt nicht konforme Massensendungen nicht mehr zu. Unabhängig von diesen Schwellenwerten bewerten Spamfilter fehlende Authentifizierung negativ: Ohne SPF, DKIM und DMARC landen Rechnungen und Angebote häufiger im Spam-Ordner, und die eigene Domain lässt sich leichter für Phishing gegen Kunden und Lieferanten missbrauchen.

Eingerichtet wird alles über DNS-TXT-Einträge, die der Domain-Verwalter oder IT-Dienstleister setzt. Bewährt hat sich ein schrittweises Vorgehen: zuerst SPF und DKIM für sämtliche Versandquellen einrichten, dann DMARC mit p=none im reinen Berichtsmodus veröffentlichen, die Aggregat-Berichte einige Wochen auswerten und die Richtlinie erst danach auf quarantine und schließlich reject verschärfen. Achten Sie auf die Grenze von zehn DNS-Abfragen, die der SPF-Standard (RFC 7208, Abschnitt 4.6.4) pro Prüfung erlaubt: Unternehmen mit mehreren Marketing- und Fachanwendungen erreichen sie schnell, und darüber hinaus liefert die SPF-Prüfung nur noch einen Fehler statt eines Ergebnisses.

Der DMARC-Standard wurde im Mai 2026 überarbeitet. Die RFCs 9989, 9990 und 9991 ersetzen das bisherige RFC 7489 und heben DMARC auf den IETF-Standards-Track. Bestehende Einträge bleiben gültig und beginnen weiterhin mit v=DMARC1. Neu sind unter anderem das Tag np für nicht existierende Subdomains und ein Test-Tag t; das frühere Tag pct ist entfallen und sollte aus bestehenden Einträgen entfernt werden. (Stand: September 2026.)

E-Mail-Authentifizierung ist keine einmalige Konfiguration, sondern eine Daueraufgabe. Jede neue Versandquelle — Newsletter-Werkzeug, CRM, Buchhaltungs- oder Branchensoftware, Ticketsystem, Webshop — muss in SPF aufgenommen und mit DKIM signiert werden, sonst scheitert ihre Post an der eigenen Richtlinie. Die DMARC-Berichte zeigen fortlaufend, wer im Namen Ihrer Domain sendet, und decken dabei auch unbefugte Absender auf.

Code-Beispiel

// Beispiel: DNS-TXT-Records für E-Mail-Authentifizierung
// Domain: beispiel.at

// SPF-Record (erlaubt nur Microsoft 365)
beispiel.at. IN TXT "v=spf1 include:spf.protection.outlook.com -all"

// DKIM-Record (Selector: s1)
s1._domainkey.beispiel.at. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

// DMARC-Record (Berichtsmodus; sp = Subdomains, np = nicht existierende Subdomains)
_dmarc.beispiel.at. IN TXT "v=DMARC1; p=none; sp=none; np=reject; rua=mailto:[email protected]"

// Nach Auswertung der Berichte: Policy schrittweise verschärfen
// _dmarc.beispiel.at. IN TXT "v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]"
// _dmarc.beispiel.at. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]"

// Hinweis: Das Tag pct wurde mit RFC 9989 (Mai 2026) abgeschafft;
// für gestaffelte Einführungen dient nun das Tag t=y.