Raten Sie nicht bei Ihrem DNS: eine entwicklerfreundliche Tour durch MX, SPF, DKIM und DMARC

Warum DNS-Einträge für E-Mail heute wichtig sind

E-Mail-Authentifizierung war früher optional. 2026 gehört sie zur Grundausstattung. Gmail und Outlook erzwingen beide SPF und DKIM für Massenversender, und DMARC wird für jede Domain, die Transaktions-E-Mails versendet, schnell zur Pflicht. Wenn Ihre DNS-Einträge falsch sind, kommen Ihre E-Mails nicht an – kein Bounce, keine Warnung, nur Stille.

Das Problem ist, dass diese Einträge wie RFCs dokumentiert sind, nicht wie Werkzeuge. Die meisten Entwickler kopieren Beispiele aus der Einrichtungsanleitung ihres E-Mail-Anbieters und hoffen das Beste. Das funktioniert, bis Sie einen Fehler beheben, einen zweiten Versanddienst hinzufügen oder einem Kunden erklären müssen, warum die E-Mails seines Kontaktformulars im Spam landen.

Dieser Leitfaden führt durch MX, SPF, DKIM und DMARC in der Reihenfolge, in der Sie ihnen tatsächlich begegnen werden – mit genug Detail, um sie korrekt zu konfigurieren, und genug Kontext, um sie zu debuggen, wenn sie nicht funktionieren.

MX records: wohin eingehende E-Mails gehen

MX records sagen dem Internet, welche Mailserver E-Mails für Ihre Domain annehmen. Sie sind die einfachsten der vier, aber auch am leichtesten falsch zu konfigurieren.

Ein MX record besteht aus zwei Teilen: einer Prioritätszahl und einem Hostnamen. Niedrigere Prioritätszahlen werden zuerst ausprobiert. Wenn Sie Google Workspace verwenden, könnten Ihre MX records so aussehen:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Die abschließenden Punkte sind wichtig – sie signalisieren, dass der Hostname vollständig qualifiziert ist. Die meisten DNS-Anbieter fügen sie automatisch hinzu, aber nicht alle.

Häufige Fehler: MX records auf einen A record statt auf einen Hostnamen zeigen lassen, alle Prioritäten auf dieselbe Zahl setzen (was den Zweck von Backups zunichtemacht) oder vergessen, alte MX records zu entfernen, wenn Sie den Anbieter wechseln. Veraltete MX records liegen dort nicht einfach harmlos herum – sie können Mail-Loops verursachen oder die Zustellung auf zwei Postfächer aufteilen.

Wenn Sie Ihr eigenes Kontaktformular betreiben und Spam vermeiden möchten, ohne sich auf Drittanbieter zu verlassen, ist zu verstehen, wie Formulare zu Spam-Vektoren werden ein nützlicher Ausgangspunkt.

SPF: welche Server in Ihrem Namen senden dürfen

SPF (Sender Policy Framework) ist ein TXT record, der die IP-Adressen und Domains auflistet, die berechtigt sind, E-Mails im Namen Ihrer Domain zu senden. Es ist die erste Prüfung, die die meisten Mailserver durchführen, wenn sie eine Nachricht erhalten, die vorgibt, von Ihnen zu stammen.

Ein einfacher SPF record sieht so aus:

v=spf1 include:_spf.google.com ~all

Aufgeschlüsselt:

• v=spf1 deklariert die SPF-Version
• include:_spf.google.com delegiert an Googles SPF record
• ~all ist ein Soft Fail – E-Mails aus nicht gelisteten Quellen ablehnen, aber nicht zu strikt sein

Sie können auch ip4: oder ip6: verwenden, um bestimmte Adressen auf eine Whitelist zu setzen, oder a und mx, um auf die A- und MX records Ihrer Domain zu verweisen. Der all-Mechanismus am Ende steuert, was mit E-Mails aus Quellen passiert, die Sie nicht aufgeführt haben: -all ist ein Hard Fail (ablehnen), ~all ist ein Soft Fail (als verdächtig markieren), ?all ist neutral (keine Aussage), und +all ist ein Freibrief (nicht verwenden).

SPF hat zwei scharfe Kanten. Erstens bricht es bei weitergeleiteten E-Mails, weil der weiterleitende Server nicht in Ihrem SPF record steht. Zweitens haben SPF records ein Lookup-Limit von zehn DNS-Abfragen. Wenn Sie zu viele Drittanbieterdienste einbinden, überschreiten Sie das Limit und SPF funktioniert nicht mehr. Die Lösung ist, Ihren SPF record zu flatten – include:-Direktiven durch die tatsächlichen IP-Bereiche zu ersetzen –, aber das erfordert Wartung, wenn Anbieter ihre IPs ändern.

DKIM: kryptografischer Nachweis der Absenderidentität

DKIM (DomainKeys Identified Mail) fügt Ihren ausgehenden E-Mails eine digitale Signatur hinzu. Der empfangende Server prüft die Signatur gegen einen öffentlichen Schlüssel, der in Ihrem DNS veröffentlicht ist. Wenn die Signatur gültig ist und die Nachricht nicht manipuliert wurde, besteht DKIM die Prüfung.

Im Gegensatz zu SPF übersteht DKIM Weiterleitungen, weil die Signatur mit der Nachricht reist. Es ist außerdem flexibler – Sie können mehrere DKIM-Schlüssel für verschiedene Versanddienste haben, jeweils mit eigenem Selector.

Ein DKIM-DNS-Eintrag sieht so aus:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Der Selector (default in diesem Beispiel) ist beliebig – Ihr E-Mail-Anbieter wählt ihn. Der p=-Wert ist der öffentliche Schlüssel, normalerweise eine lange base64-kodierte Zeichenkette. Ihr E-Mail-Anbieter erzeugt den privaten Schlüssel und verwendet ihn, um ausgehende Nachrichten zu signieren.

Die DKIM-Einrichtung wird fast immer von Ihrem E-Mail-Anbieter übernommen. Ihre Aufgabe ist es, den TXT record zu kopieren, den er Ihnen gibt, und ihn in Ihr DNS einzufügen. Der knifflige Teil ist, dass einige DNS-Anbieter lange TXT records nicht gut verarbeiten – sie kürzen sie entweder ab oder verlangen, dass Sie den Wert in mehrere in Anführungszeichen gesetzte Zeichenketten aufteilen.

Um zu prüfen, ob DKIM funktioniert, senden Sie eine Test-E-Mail an eine Gmail-Adresse und prüfen Sie die Header. Suchen Sie im Header Authentication-Results nach dkim=pass.

DMARC: Richtliniendurchsetzung und Reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) verbindet SPF und DKIM und teilt empfangenden Servern mit, was sie tun sollen, wenn die Authentifizierung fehlschlägt. Es aktiviert außerdem Reporting, sodass Sie sehen können, wer E-Mails als Ihre Domain versendet – sowohl legitime als auch gefälschte.

Ein minimaler DMARC record sieht so aus:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none bedeutet nur überwachen – fehlgeschlagene Nachrichten nicht ablehnen oder in Quarantäne verschieben
• rua=mailto:[email protected] gibt an, wohin aggregierte Berichte gesendet werden sollen

Sobald Sie sicher sind, dass SPF und DKIM funktionieren, können Sie die Richtlinie auf p=quarantine (Fehler in den Spam senden) oder p=reject (sie direkt bouncen) verschärfen. Sie können außerdem mit sp= eine Subdomain-Richtlinie setzen und mit pct= einen Prozentsatz der Nachrichten festlegen, auf die die Richtlinie angewendet werden soll.

DMARC-Berichte sind XML-Dateien, die täglich von großen Empfängern gesendet werden. Sie sind ausführlich und roh schwer zu lesen, aber sie sagen Ihnen genau, welche Nachrichten die Authentifizierung bestanden oder nicht bestanden haben und warum. Wenn legitime E-Mails abgelehnt werden, zeigen Ihnen die Berichte, welche SPF- oder DKIM-Prüfung fehlschlägt.

Ein Stolperstein: DMARC verlangt Alignment. Bei SPF muss die Domain im Header Return-Path mit der Domain im Header From übereinstimmen (oder eine Subdomain davon sein). Bei DKIM muss die d=-Domain in der DKIM-Signatur mit der From-Domain übereinstimmen. Wenn Sie einen Versanddienst eines Drittanbieters verwenden, muss dieser benutzerdefinierte Return Paths oder DKIM-Signierung mit Ihrer Domain unterstützen, nicht mit seiner.

So auditieren Sie Ihre aktuelle Einrichtung

Die meisten DNS-Probleme sind unsichtbar, bis sie ein Problem verursachen. So prüfen Sie Ihre Einträge, bevor etwas kaputtgeht:

1. Ihre MX records abfragen: dig MX example.com sollte die Hostnamen und Prioritäten Ihrer Mailserver zurückgeben. Prüfen Sie, ob sie mit der Dokumentation Ihres E-Mail-Anbieters übereinstimmen.

1. SPF-Syntax prüfen: dig TXT example.com und nach dem v=spf1-Eintrag suchen. Lassen Sie ihn durch einen SPF-Validator laufen, um Syntaxfehler und Verstöße gegen das Lookup-Limit zu finden.

1. DKIM-Schlüssel verifizieren: Senden Sie eine Test-E-Mail und prüfen Sie den Header DKIM-Signature. Extrahieren Sie Selector und Domain, und fragen Sie dann dig TXT selector._domainkey.example.com ab, um zu bestätigen, dass der öffentliche Schlüssel existiert.

1. DMARC-Richtlinie validieren: dig TXT _dmarc.example.com sollte Ihren DMARC record zurückgeben. Stellen Sie sicher, dass rua= auf eine Adresse zeigt, die Sie tatsächlich überwachen.

1. End-to-End testen: Verwenden Sie einen Dienst wie mail-tester.com oder senden Sie an eine Gmail-Adresse und prüfen Sie die vollständigen Header. Suchen Sie im Header Authentication-Results nach spf=pass, dkim=pass und dmarc=pass.

Wenn Sie debuggen, warum E-Mails nicht ankommen, sind die Header Ihr bestes Werkzeug. Die meisten Mail-Clients lassen Sie rohe Header anzeigen – öffnen Sie in Gmail die Nachricht, klicken Sie auf die drei Punkte und wählen Sie „Original anzeigen“. Der Header Authentication-Results sagt Ihnen genau, welche Prüfung fehlgeschlagen ist und warum.

Wann Subdomain-Richtlinien sinnvoll sind

Wenn Sie E-Mails von mehreren Subdomains senden – etwa newsletter.example.com für Marketing und app.example.com für Transaktions-E-Mails –, können Sie DMARC-Richtlinien pro Subdomain setzen. So können Sie strikte Richtlinien für Subdomains durchsetzen, die Sie kontrollieren, während Sie auf Ihrer Hauptdomain eine lockerere Richtlinie beibehalten.

Der Nachteil ist Komplexität. Jede Subdomain benötigt eigene SPF-, DKIM- und DMARC records, und Sie müssen nachverfolgen, welche Versanddienste für welche Subdomains autorisiert sind. Für die meisten kleinen Teams ist eine einzelne gut konfigurierte Domain einfacher und genauso sicher.

Was tun, wenn Authentifizierung nicht funktioniert

Der häufigste Fehlermodus ist, einen neuen Versanddienst hinzuzufügen, ohne DNS zu aktualisieren. Wenn Sie einen neuen Anbieter für Transaktions-E-Mails verwenden, müssen Sie dessen SPF include oder IP-Bereich hinzufügen, DKIM-Signierung mit Ihrer Domain konfigurieren und DMARC-Alignment verifizieren.

Das zweithäufigste Problem ist Weiterleitung. Wenn Benutzer Ihre E-Mail an eine andere Adresse weiterleiten, schlägt SPF fehl, weil der weiterleitende Server nicht in Ihrem SPF record steht. DKIM übersteht Weiterleitungen normalerweise. Solange DKIM besteht und Ihre DMARC-Richtlinie teilweises Alignment erlaubt, sollte die Nachricht also weiterhin zugestellt werden. Wenn weitergeleitete E-Mails abgelehnt werden, prüfen Sie Ihre DMARC-Richtlinie – p=reject mit strengem Alignment bricht Weiterleitungen.

Das dritte Problem ist DNS-Propagation. Änderungen an DNS-Einträgen können Stunden brauchen, um sich zu verbreiten, und verschiedene Mailserver cachen Einträge unterschiedlich lange. Wenn Sie gerade einen Eintrag aktualisiert haben und er nicht funktioniert, warten Sie ein paar Stunden und testen Sie erneut. Sie können die Propagation mit einem Tool wie whatsmydns.net prüfen.

Wichtigste Erkenntnisse

• MX records routen eingehende E-Mails; SPF, DKIM und DMARC authentifizieren ausgehende E-Mails. Sie lösen unterschiedliche Probleme, und Sie brauchen alle vier.
• SPF bricht bei Weiterleitungen und hat ein Limit von zehn Lookups. DKIM übersteht Weiterleitungen, erfordert aber Konfiguration pro Dienst. DMARC verbindet beide und ermöglicht Reporting.
• Beginnen Sie in DMARC mit p=none, überwachen Sie die Berichte einige Wochen lang und verschärfen Sie dann auf p=quarantine oder p=reject, sobald Sie sicher sind, dass legitime E-Mails bestehen.
• DNS-Fehler sind still. Testen Sie Ihre Konfiguration mit echten E-Mails und prüfen Sie die Header, um zu bestätigen, dass SPF, DKIM und DMARC bestehen.
• Wenn die Authentifizierung nach dem Hinzufügen eines neuen Versanddienstes nicht mehr funktioniert, prüfen Sie SPF includes, DKIM selectors und DMARC alignment. Die Header sagen Ihnen, welche Prüfung fehlgeschlagen ist.

FAQ

Q: Kann ich mehrere SPF records haben?

A: Nein. Mehrere SPF records führen dazu, dass alle ignoriert werden. Wenn Sie mehrere Dienste autorisieren müssen, verwenden Sie include:-Direktiven innerhalb eines einzigen SPF record oder listen Sie IP-Bereiche direkt auf. Beachten Sie das Limit von zehn Lookups.

Q: Brauche ich DMARC, wenn ich nur ein paar E-Mails pro Tag sende?

A: Ja. Bei DMARC geht es nicht um Volumen – es geht darum zu beweisen, dass Sie der sind, der Sie vorgeben zu sein. Selbst kleine Domains profitieren von DMARC, weil es Spoofing verhindert und Ihnen Einblick in Zustellprobleme gibt. Beginnen Sie mit p=none und einer Reporting-Adresse.

Q: Was passiert, wenn DKIM und SPF beide fehlschlagen, die E-Mail aber legitim aussieht?

A: Das hängt von Ihrer DMARC-Richtlinie ab. Bei p=none wird die E-Mail mit einer Warnung zugestellt. Bei p=quarantine landet sie im Spam. Bei p=reject wird sie gebounct. Deshalb sollten Sie DMARC-Berichte überwachen, bevor Sie eine strikte Richtlinie durchsetzen – möglicherweise haben Sie legitime Absender, von denen Sie nichts wussten.

Q: Kann ich denselben DKIM-Schlüssel für mehrere Domains verwenden?

A: Technisch ja, aber tun Sie es nicht. Jede Domain sollte ihr eigenes DKIM-Schlüsselpaar haben. Das Teilen von Schlüsseln erschwert Rotation und vergrößert den Schaden, wenn ein privater Schlüssel kompromittiert wird.

Q: Wie oft sollte ich DKIM-Schlüssel rotieren?

A: Es gibt keine universelle Regel, aber einmal pro Jahr ist für die meisten Domains angemessen. Wenn Sie vermuten, dass ein Schlüssel kompromittiert wurde, rotieren Sie sofort. Stellen Sie sicher, dass Sie den neuen öffentlichen Schlüssel im DNS veröffentlichen, bevor Sie mit dem neuen privaten Schlüssel signieren, und lassen Sie den alten Schlüssel nach der Rotation noch ein paar Tage im DNS, um verzögerte E-Mails abzufangen.

<!-- tool-cta:start -->

💡 Probieren Sie es aus: Überprüfen Sie die veröffentlichte Richtlinie einer beliebigen Domain mit DMARC Lookup, um zu sehen, wie MX-, SPF- und DMARC-Einträge in der Praxis zusammenwirken.

<!-- tool-cta:end -->

Quellen

• RFC 7208: Sender Policy Framework (SPF) — Die SPF-Spezifikation, einschließlich Syntaxregeln und dem Limit von zehn Lookups.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Die DKIM-Spezifikation, die Signaturerzeugung und -verifikation abdeckt.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Die DMARC-Spezifikation, einschließlich Richtliniensyntax und Format für aggregierte Berichte.
• Google Workspace: Prevent spoofing and spam — Praktische Anleitung zur Konfiguration von SPF, DKIM und DMARC für Google Workspace-Domains.