Stand: Juli 2026

Zusammenfassung: „E-Mail-Authentifizierung” besteht eigentlich aus zwei Ebenen. Die eine beweist, wer eine Mail gesendet hat — das sind SPF, DKIM und DMARC. Die andere schützt die Mail beim Transport — das sind TLS, MTA-STS, DANE und TLS-RPT. Du brauchst beide. Diese Seite erklärt, wie die Teile zusammenspielen, und verlinkt dich direkt zur Anleitung für deinen Anbieter.

SMTP, das Protokoll, das E-Mails transportiert, stammt aus einer Zeit gegenseitigen Vertrauens. Es hat keinen eingebauten Weg, um zu beweisen, dass ein Absender wirklich der ist, der er vorgibt zu sein — und keine Garantie, dass eine Nachricht verschlüsselt reist. Alles, was wir heute „E-Mail-Authentifizierung” nennen, ist eine Sammlung von Standards, die genau diese zwei Lücken schließen. Zu verstehen, welche Lücke jeder Standard schließt, ist der ganze Trick.

Ebene eins: Wer hat das gesendet? (Identität)

Drei Einträge im DNS deiner Domain lassen einen empfangenden Server beurteilen, ob eine Nachricht wirklich von dir stammt.

SPF — welche Server für dich senden dürfen

SPF (Sender Policy Framework, RFC 7208) ist ein TXT-Record, der die Mailserver auflistet, die mit deiner Domain als Absender senden dürfen. Der Wert beginnt mit v=spf1 und endet mit einer Policy wie ~all oder -all. Ein Empfänger schlägt ihn bei jeder eingehenden Nachricht nach und prüft, ob der einliefernde Server auf deiner Liste steht. Ohne SPF kann jeder deine Domain in den Absender setzen. Es ist der einfachste Einstieg — siehe die SPF-Anleitungen für deinen Hoster.

DKIM — eine kryptografische Signatur

DKIM (DomainKeys Identified Mail, RFC 6376) fügt jeder Nachricht eine digitale Signatur hinzu. Dein Mailserver signiert ausgehende Mail mit einem privaten Schlüssel; der passende öffentliche Schlüssel liegt als v=DKIM1-Eintrag unter einem Selector in deinem DNS. Der Empfänger prüft die Signatur — das beweist zweierlei: Die Nachricht kam wirklich über deine Infrastruktur, und sie wurde unterwegs nicht verändert. Anders als SPF übersteht DKIM Weiterleitungen — die Signatur reist mit der Nachricht mit.

DMARC — die Policy, die alles verbindet

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) macht SPF und DKIM erst nutzbar. Ein v=DMARC1-TXT-Record sagt Empfängern, was sie tun sollen, wenn eine Nachricht beide Prüfungen nicht besteht — p=none (nur beobachten), p=quarantine (Spam-Ordner) oder p=reject (abweisen). Außerdem bittet er Empfänger um Sammelberichte, sodass du sehen kannst, wer in deinem Namen sendet, bevor du die Schrauben anziehst. Der empfohlene Weg ist none → quarantine → reject, immer mit Blick auf die Berichte.

Die drei bauen aufeinander auf: SPF und DKIM sind die Prüfungen, DMARC ist das Urteil. Wie sie ineinandergreifen, vertiefen wir in SPF vs. DKIM vs. DMARC: wie sie zusammenpassen.

Ebene zwei: War sie beim Transport geschützt? (Transport)

Identität zu beweisen ist nur die halbe Miete. Eine Nachricht kann perfekt authentifiziert und trotzdem auf dem Weg mitgelesen oder manipuliert werden, wenn die Verbindung zwischen den Servern nicht verschlüsselt und geprüft ist.

TLS und STARTTLS — opportunistische Verschlüsselung

Moderne Mailserver bieten STARTTLS an und heben eine SMTP-Verbindung auf eine verschlüsselte an. Der Haken: Standardmäßig ist das opportunistisch. Scheitert der Handshake oder streicht ein Angreifer das STARTTLS-Angebot heraus, fällt die Zustellung still auf Klartext zurück. Verschlüsselt wird, wenn es geht — nicht, wenn es muss. Die nächsten zwei Standards machen aus „geht” ein „muss”.

MTA-STS — TLS per HTTPS-Policy erzwingen

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) veröffentlicht eine Policy-Datei über HTTPS, die sendenden Servern sagt: Für meine Domain ist TLS Pflicht und das Zertifikat muss gültig sein. Das schließt die Downgrade-Lücke ohne DNSSEC, weshalb es auf fast jedem Hoster funktioniert. Für die meisten ist es die praktische Wahl — lies MTA-STS bei Shared-Hostern, wer es einsetzen kann und wer nicht.

DANE — TLS per DNSSEC erzwingen

DANE (DNS-Based Authentication of Named Entities, RFC 6698) erreicht dasselbe Ziel — verpflichtendes, authentifiziertes TLS — verankert das Vertrauen aber in DNSSEC und einem TLSA-Eintrag an deinem MX. Es ist stärker, aber nur der Betreiber deines empfangenden Mailservers kann es umsetzen — für die meisten Shared-Hosting-Kunden also außer Reichweite. Wer genau infrage kommt, klären wir in DANE für E-Mail: wer es kann.

TLS-RPT — erfahren, wenn die Zustellung scheitert

TLS-RPT (SMTP TLS Reporting, RFC 8460) ist der Rückkanal. Ein kleiner TXT-Record mit TLSRPTv1 bittet sendende Server, dir täglich Berichte zu mailen, wie die TLS-Zustellung an deine Domain lief — Erfolge und, wichtiger, Fehlschläge. Egal ob du MTA-STS oder DANE fährst: Über TLS-RPT erfährst du, dass etwas kaputt ist — statt es vom verärgerten Kunden zu hören.

Die Belohnung: BIMI

Sobald DMARC durchsetzt (p=quarantine oder p=reject), kannst du BIMI (Brand Indicators for Message Identification) ergänzen. Es zeigt dein Logo neben authentifizierter Mail in unterstützenden Postfächern. BIMI bringt für sich genommen keine Sicherheit — es ist die sichtbare Belohnung für die geleistete Authentifizierungsarbeit. Siehe die BIMI-Anleitungen, sobald dein DMARC durchsetzt. Der Standard wird von der BIMI Group betreut.

Wie du das konkret ausrollst

Eine sinnvolle Reihenfolge:

  1. SPF — Record veröffentlichen oder prüfen. Ein Record, eine Policy.
  2. DKIM — Signierung beim Anbieter einschalten, öffentlichen Schlüssel veröffentlichen.
  3. DMARC — mit p=none starten und ein paar Wochen die Berichte lesen.
  4. DMARC anziehen — auf quarantine, dann reject, sobald die Berichte sauber sind.
  5. Transport — MTA-STS ergänzen (oder DANE, falls du infrage kommst) und TLS-RPT.
  6. BIMI — der letzte Schliff, sobald DMARC durchsetzt.

Jeder Schritt ist im Detail anbieterspezifisch. Wähl deinen Hoster in den Anleitungen nach Anbieter und folge mit.

Ergebnis prüfen

Der kostenlose MXAudit-Scanner prüft das alles in einem Durchgang: SPF-Syntax und Lookup-Zahl, DKIM-Schlüssel, deine DMARC-Policy sowie MTA-STS, DANE, TLS-RPT und BIMI. Der schnellste Weg zu sehen, welche der zwei Ebenen du wirklich abgedeckt hast — und wo die Lücken sind.