Warum E-Mail-Authentifizierung wesentlich ist
Drei Bausteine, die sich ergänzen
SPF gibt an, welche Server für Ihre Domain senden dürfen. Die Regel wird in einem TXT-Eintrag am Apex veröffentlicht. Gut konfiguriert, begrenzt es Spoofing. Zu permissiv, lässt es Missbrauch durch.
DKIM signiert Ihre Nachrichten. Der öffentliche Schlüssel lebt in einem TXT unter selector._domainkey. Eine gültige Signatur beweist, dass die Nachricht nicht verändert wurde und zeigt an, welche Domain sie signiert hat.
DMARC verknüpft die sichtbare Adresse mit SPF und DKIM. Wenn SPF oder DKIM passt und mit der Absenderdomain aligniert ist, gilt die Nachricht als konform. Die Richtlinie entscheidet dann über die Behandlung bei Fehlschlag: Beobachtung, Quarantäne oder Ablehnung.
Was ein Empfängerserver sieht
Beim Empfang liest der Server Ihre DNS-Einträge und fügt einen Authentication-Results-Header hinzu. Sie finden spf=pass oder fail, dkim=pass oder fail, dmarc=pass oder fail, mit der bewerteten Domain. Dieser Header ist Ihre Ground Truth. Er bestätigt die reale Wirkung Ihrer Einstellungen, jenseits der Theorie.
Was BIMI ändert
BIMI ist kein Spamfilter. Es zeigt ein validiertes Logo an, wenn DMARC mit einer durchgesetzten Richtlinie vorhanden ist. Das Logo wird über einen dedizierten DNS-Eintrag und manchmal ein VMC-Zertifikat angefordert. Ergebnis: Der Empfänger identifiziert Ihre Marke besser und erkennt eine Fälschung schneller.
Die häufigsten Fehler
- Zwei SPF mit demselben Namen → In einen einzelnen Wert zusammenführen
- SPF überschreitet 10 Lookups → Includes vereinfachen oder den SPF Flattener verwenden
- Falsch geschriebener DKIM-Selector → Der Schlüssel wird unauffindbar
- Abgeschnittener öffentlicher Schlüssel → Überprüfung schlägt stillschweigend fehl
- DMARC ohne Alignment → Nachricht passiert, schützt aber nicht die Identität
- DMARC-Berichte an unüberwachtes Postfach → Sie verlieren Observability
TTL und DNS-Propagierung
Das Netzwerk "propagiert" nicht im strengen Sinne. Es cached gemäß TTL. Ein kurzer TTL hilft während eines Updates. Ein zu kurzer TTL belastet auf Dauer unnötig. Ein mittlerer TTL (3600-86400s) stabilisiert eine validierte Einstellung. Reduzieren Sie vor einer Änderung, stellen Sie danach wieder her.
So nutzen Sie die CaptainDNS-Toolbox
SPF-, DKIM-, DMARC-Syntax-Validatoren
Validatoren lesen Ihre Roheinträge und erklären jedes Element:
SPF: Mechanismus-Reihenfolge, include, redirect, Vorhandensein von all, DNS-Abfragenzählung, nicht existierende IPs und Domains. Das Ziel ist, unter 10 Lookups zu bleiben und Schleifen zu vermeiden.
DKIM: Lesen der Tags v, k, p, t, s. Schlüssellängenüberprüfung, Erkennung von Abschneidungen, ungültigen Zeichen und Best Practices zur Schlüsselrotation.
DMARC: Lesen der Tags v, p, sp, adkim, aspf, pct, rua, ruf. Überprüfung des gewählten Alignments und der Gültigkeit von Berichtsadressen.
Live-Eintrag-Inspektoren
Inspektoren lösen DNS auf und zeigen die Antwort so an, wie sie aus dem Internet gesehen wird:
- SPF-Inspektor: entfaltet die Include-Kette, zeigt aufgerufene Domains und wo das Limit überschritten würde
- DKIM-Inspektor: löst den Selector auf, extrahiert den öffentlichen Schlüssel und prüft Formatkonsistenz
- DMARC-Inspektor: liest _dmarc.domain, zeigt die aktive Richtlinie, rua/ruf-Adressen und Durchsetzungsprozentsatz
Diese Tools überprüfen die Gegenwart, nicht die Theorie. Ideal für ein Ticket oder Produktionsdeployment.
E-Mail-Zustellbarkeits-Audit
Diese Prüfung analysiert MX, SPF, DKIM und DMARC gleichzeitig, um eine einfache Frage zu beantworten: Ist die Domain sendebereit? Sie zeigt auch die wahrscheinlichste Fehlerursache: SPF zu permissiv, fehlender DKIM-Schlüssel, nicht durchgesetzte DMARC-Richtlinie, striktes Alignment, das bei einer Subdomain fehlschlägt, MX zeigt auf einen CNAME.
DMARC-Eintrag-Generator
Der Generator hilft Ihnen, vollständige, RFC-konforme DMARC-Einträge zu erstellen:
- Domain-Konfiguration: einfache Eingabe mit automatischer _dmarc-Hostname-Generierung
- Flexible Richtlinien: Wahl zwischen none, quarantine und reject mit Subdomain-Handling
- Integrierte Berichterstattung: rua/ruf-Adressen mit Validierung und Implementierungsanleitung
- Erweiterte Optionen: DKIM/SPF-Alignments, Prozentsätze, Intervalle und Fehleroptionen
Das Tool generiert den vollständigen Eintrag, bereit zur Veröffentlichung, und führt zum Inspektor für die Post-Deployment-Überprüfung.
BIMI in Produktion
Der BIMI-Validator prüft die Eintragsstruktur, testet die HTTPS-Logo-URL, verifiziert Tiny-PS-Einschränkungen und lädt das VMC herunter, wenn vorhanden. Kombiniert mit DMARC auf quarantine oder reject durchgesetzt, sichert es die Logo-Anzeige in kompatiblen Webmail-Clients.
MTA-STS für Transportsicherheit
MTA-STS (RFC 8461) fügt eine kritische Schutzschicht hinzu, indem es TLS-Verschlüsselung für eingehende E-Mails erzwingt. Ohne MTA-STS kann opportunistisches TLS von Angreifern herabgestuft werden. Mit MTA-STS müssen sendende Server TLS verwenden oder die Zustellung ablehnen.
MTA-STS-Tools
Syntax-Validator: Fügen Sie Ihren DNS-TXT-Eintrag und Policy-Dateiinhalt ein. Der Validator prüft Version, Modus, MX-Muster und max_age-Direktiven vor der Veröffentlichung.
Eintrag-Inspektor: Geben Sie eine Domain ein, um den Live-MTA-STS-Eintrag und die Policy-Datei abzurufen. Verifiziert TLS-Zertifikate und prüft MX-Muster gegen echte Mailserver.
Generator: Erstellen Sie konforme MTA-STS-Einträge und Policy-Dateien. Konfigurieren Sie Testing- oder Enforce-Modus, fügen Sie MX-Muster hinzu, setzen Sie die Cache-Dauer. Kopierbereite Ausgabe mit Deployment-Anweisungen.
Empfohlenes MTA-STS-Deployment
- Generieren Sie den DNS-TXT-Eintrag und die Policy-Datei
- Hosten Sie die Policy-Datei unter
https://mta-sts.ihredomain.de/.well-known/mta-sts.txt - Veröffentlichen Sie den DNS-TXT-Eintrag unter
_mta-sts.ihredomain.de - Starten Sie im Testing-Modus, um Probleme zu identifizieren, ohne die Zustellung zu unterbrechen
- Wechseln Sie zu Enforce, sobald Sie verifiziert haben, dass alle MX-Server TLS unterstützen
- Überwachen Sie mit TLS-RPT, um Fehlerberichte zu erhalten
Empfohlene Deployment-Methode
- Ausgangszustand dokumentieren: DNS-Captures und Authentication-Results-Beispiele
- TTL reduzieren vor Änderungen (300-600s)
- SPF deployen sauber und einzigartig, mit dem Inspektor verifizieren
- DKIM-Schlüssel veröffentlichen auf einem neuen Selector, Signatur testen
- DMARC aktivieren auf p=none, Berichte analysieren, korrigieren dann durchsetzen
- BIMI hinzufügen wenn DMARC durchgesetzt ist und Logo/VMC die Validierung bestehen
- Komfortablen TTL wiederherstellen (3600-86400s) wenn stabil
Überwachung und täglicher Betrieb
Konfigurationen entwickeln sich mit Anbietern, Subdomains, Microservices und einmaligen Kampagnen. Halten Sie einen einfachen Zyklus ein: regelmäßige Kontrollen, Berichtslektüre, Schlüsselrotation, Bereinigung veralteter Includes und Selektoren. Eine Änderung sollte immer eine Spur hinterlassen: Datum, Autor, vorheriger Wert, neuer Wert, Grund. Dies verkürzt jede Diagnose.
Ergänzende Tools
| Tool | Zweck |
|---|---|
| DNS-Propagierungsprüfer | Bestätigen, dass Ihre DNS-Änderungen weltweit sichtbar sind |
| DNS-Lookup | Jeden DNS-Eintragstyp abfragen |
| IP-Whois | Eigentümer einer IP-Adresse identifizieren |
| IP-Blacklist-Checker | Prüfen, ob Ihre IP auf einer Blacklist steht |
| Domain-Blacklist-Checker | Prüfen, ob Ihre Domain auf einer Blacklist steht |
Nützliche Ressourcen
- RFC 7208 - Sender Policy Framework (SPF) (offizielle Spezifikation)
- RFC 6376 - DomainKeys Identified Mail (DKIM) (offizielle Spezifikation)
- RFC 7489 - Domain-based Message Authentication (DMARC) (offizielle Spezifikation)
- Google - E-Mail-Absenderrichtlinien (Gmail-Anforderungen)
- Microsoft - E-Mail-Authentifizierung in Microsoft 365 (Outlook/M365-Leitfaden)