Die Migration schien unkompliziert. DNS zu einem neuen Anbieter verschieben, Nameserver aktualisieren, fertig. Nur hat jemand vergessen, den SPF-Record neu anzulegen. Drei Tage lang scheiterte die Authentifizierung jeder E-Mail des Unternehmens. Die Zustellbarkeit stürzte ab. Kundenbeschwerden häuften sich. Alles wegen eines fehlenden TXT-Records.
E-Mail und DNS sind eng miteinander verknüpft. MX-Records sagen der Welt, wohin deine Mails zugestellt werden sollen. TXT-Records übernehmen die Authentifizierung. CNAME-Records ermöglichen Tracking und benutzerdefinierte Domains. Fehlt einer davon, bricht E-Mail auf nicht immer offensichtliche Weise.
Diese Checkliste deckt jeden DNS-Record ab, der E-Mail betrifft – von unverzichtbar bis optional, aber empfehlenswert.
Wesentliche Records
MX-Records. Mail Exchanger Records teilen sendenden Servern mit, wohin E-Mails für deine Domain zugestellt werden sollen. Ohne MX-Records kannst du keine E-Mails empfangen. Die meisten Setups haben mehrere MX-Records mit unterschiedlichen Prioritäten für Redundanz.
example.com. MX 10 mail1.example.com.
example.com. MX 20 mail2.example.com.
Die Zahl ist die Priorität – niedrigere Werte werden zuerst versucht. Ist mail1 nicht erreichbar, versuchen Absender mail2.
SPF-Record (TXT). Sender Policy Framework legt fest, welche Server E-Mails im Namen deiner Domain senden dürfen. Es ist ein TXT-Record, der autorisierte IP-Adressen sowie Includes für Drittanbieter-Dienste auflistet.
example.com. TXT "v=spf1 include:_spf.google.com include:amazonses.com -all"
Das -all am Ende bedeutet "alles, was nicht aufgeführt ist, ablehnen". Verwende ~all (Soft Fail) nur während der anfänglichen Einrichtung.
DKIM-Records (TXT oder CNAME). DomainKeys Identified Mail verwendet Public-Key-Kryptographie, um E-Mails zu signieren. Der öffentliche Schlüssel wird in DNS veröffentlicht, damit Empfänger die Signaturen prüfen können. Der Record-Name enthält einen Selector, der angibt, welcher Schlüssel verwendet werden soll.
selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
Einige Anbieter verwenden CNAME-Records, die auf ihre gehosteten Schlüssel zeigen, statt den Schlüssel direkt zu veröffentlichen.
DMARC-Record (TXT). Domain-based Message Authentication, Reporting, and Conformance verknüpft SPF und DKIM und weist Empfänger an, wie mit Fehlern umzugehen ist.
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
Der p=-Wert ist deine Policy: none (nur beobachten), quarantine (in Spam einsortieren) oder reject (komplett blockieren).
Empfohlene Records
Reverse DNS (PTR). PTR-Records ordnen IP-Adressen Hostnamen zu. Viele empfangende Server prüfen, ob deine sendende IP einen PTR-Record hat und ob dieser wieder zur IP auflöst. Ohne korrektes Reverse DNS können deine E-Mails abgelehnt oder als Spam markiert werden.
PTR-Records werden von demjenigen gesetzt, der die IP-Adresse kontrolliert – in der Regel dein Hosting-Provider oder ISP, nicht in der DNS-Zone deiner Domain.
MTA-STS-Records. Mail Transfer Agent Strict Transport Security weist sendende Server an, TLS bei der Zustellung an deine Domain zu erzwingen. Es verhindert Downgrade-Angriffe, bei denen Angreifer unverschlüsselte Zustellung erzwingen.
_mta-sts.example.com. TXT "v=STSv1; id=20240115"
Außerdem musst du eine Policy-Datei unter https://mta-sts.example.com/.well-known/mta-sts.txt bereitstellen.
TLS-RPT-Record (TXT). TLS Reporting teilt Absendern mit, wohin Berichte über TLS-Verbindungsfehler gesendet werden sollen. So erkennst du Zustellprobleme, die durch TLS-Probleme verursacht werden.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"
BIMI-Record (TXT). Brand Indicators for Message Identification zeigt dein Logo in unterstützenden E-Mail-Clients an. Es erfordert DMARC-Enforcement und, für vollständige Unterstützung, ein Verified Mark Certificate.
default._bimi.example.com. TXT "v=BIMI1; l=https://example.com/logo.svg"
Dienstspezifische Records
E-Mail-Provider-Verifizierung. Die meisten E-Mail-Anbieter verlangen TXT- oder CNAME-Records, um den Besitz der Domain zu verifizieren. Google Workspace, Microsoft 365 und andere haben jeweils eigene Verifizierungs-Records.
Tracking-Domain-CNAMEs. E-Mail-Dienste, die Öffnungen und Klicks verfolgen, verwenden häufig CNAME-Records, um eigene Tracking-Domains zu ermöglichen. Statt Links auf track.emailprovider.com zeigen sie auf click.yourdomain.com.
click.example.com. CNAME track.emailprovider.com.
Custom Return-Path. Manche Anbieter verwenden CNAME-Records für benutzerdefinierte Return-Path-Domains, was bei SPF-Alignment und Zustellbarkeit hilft.
Sicherheits-Records
DANE-Records (TLSA). DNS-based Authentication of Named Entities bietet Certificate Pinning für E-Mail. Es ist komplexer als MTA-STS, liefert aber stärkere Sicherheitsgarantien. Erfordert DNSSEC.
_25._tcp.mail.example.com. TLSA 3 1 1 abc123...
CAA-Records. Certificate Authority Authorization legt fest, welche CAs Zertifikate für deine Domain ausstellen dürfen. Zwar nicht spezifisch für E-Mail, aber es schützt die Zertifikate, die deine Mailserver verwenden.
example.com. CAA 0 issue "letsencrypt.org"
Verifizierungs-Checkliste
Nachdem du DNS-Records eingerichtet oder geändert hast, überprüfe, ob alles funktioniert:
MX-Records lösen auf. Verwende dig MX example.com oder MXToolbox, um zu prüfen, dass MX-Records existieren und auf gültige, erreichbare Server zeigen.
SPF ist gültig. Nutze einen SPF-Checker, um Syntax, Lookup-Anzahl und die vollständige Abdeckung deiner Absender zu prüfen. Sende eine Testmail und kontrolliere den Authentication-Results-Header.
DKIM-Schlüssel sind veröffentlicht. Nutze einen DKIM-Checker mit deinem Selector, um zu prüfen, dass der öffentliche Schlüssel erreichbar ist. Sende eine Testmail und verifiziere, dass die DKIM-Signatur validiert.
DMARC ist veröffentlicht. Nutze einen DMARC-Checker, um zu prüfen, dass der Record existiert und syntaktisch gültig ist. Stelle sicher, dass du Aggregatberichte an der angegebenen Adresse erhältst.
Reverse DNS ist konfiguriert. Verwende dig -x [your-ip], um PTR-Records zu prüfen. Verifiziere, dass der zurückgegebene Hostname wieder auf deine IP auflöst.
TLS funktioniert. Verwende CheckTLS oder ähnliche Tools, um zu prüfen, dass dein Mailserver TLS-Verbindungen akzeptiert und ein gültiges Zertifikat hat.
Häufige Fehler
TTL zu hoch während Änderungen. Wenn du DNS-Änderungen vornimmst, senke zunächst die TTL (auf 300 Sekunden oder weniger), warte, bis die alte TTL abgelaufen ist, nimm dann die Änderungen vor und erhöhe die TTL anschließend wieder. Hohe TTL während Änderungen bedeutet lange Propagationszeiten.
Fehlende abschließende Punkte. In Zonendateien sollten Hostnamen mit einem Punkt enden (z. B. mail.example.com.). Ohne den Punkt wird der Zonenname angehängt, was ungültige Records erzeugt.
Widersprüchliche Records. Pro Domain darf es nur einen SPF-Record geben. Mehrere SPF-Records führen zu Fehlern. Wenn du mehrere Dienste autorisieren musst, kombiniere sie in einem einzigen Record.
Veraltete Records nach Migrationen. Beim Wechsel des E-Mail-Anbieters müssen alte Records (MX, SPF-Includes, DKIM-Schlüssel) entfernt werden. Veraltete Records führen zu Authentifizierungsfehlern oder leiten E-Mails an ausgemusterte Server.
Frequently asked questions
Wie lange brauchen DNS-Änderungen, um sich zu propagieren?
Das hängt von der TTL (Time To Live) ab. Records werden für die Dauer ihrer TTL gecacht. Wenn TTL 3600 (1 Stunde) ist, können Änderungen bis zu einer Stunde benötigen, um weltweit zu propagieren. Senke die TTL vor Änderungen, um die Propagation zu beschleunigen.
Brauche ich all diese Records?
MX, SPF, DKIM und DMARC sind essenziell für moderne E-Mail. MTA-STS und BIMI sind empfohlen, aber nicht zwingend. DANE ist optional und erfordert DNSSEC. Dienstspezifische Records hängen davon ab, welche Dienste du nutzt.
Was passiert, wenn ich einen DNS-Record falsch setze?
Es hängt vom Record ab. Falsche MX-Records bedeuten, dass du keine E-Mails empfangen kannst. Falsches SPF/DKIM führt zu Authentifizierungsfehlern und möglicher Spam-Filterung. Teste Änderungen immer in einer Staging-Umgebung oder mit niedriger TTL, damit du schnell zurückrollen kannst.
Sollte ich das DNS meines Registrars oder einen dedizierten DNS-Provider nutzen?
Dedizierte DNS-Provider (Cloudflare, Route 53, etc.) bieten in der Regel bessere Performance, mehr Features und bessere Verwaltungsoberflächen. Für kritische E-Mail-Infrastruktur sind die Zuverlässigkeit und die Funktionen dedizierter DNS den zusätzlichen Aufwand wert.