DNS und E-Mail: MX, SPF, DKIM, DMARC
Wenn Alice eine Mail an bob@partner.com schickt, fragt Alice's MTA das DNS: „Wer ist für die Mails der Domain partner.com zuständig?" Diese Antwort liefert der MX-Record. Aber DNS macht für E-Mail noch viel mehr – die drei Anti-Phishing-Standards SPF, DKIM und DMARC leben komplett im DNS und entscheiden, ob deine Mail überhaupt im Posteingang ankommt oder im Spam-Ordner landet. Ohne diese drei Records ist deine Domain heute ein Phishing-Risiko und deine Mail-Reputation tendiert gegen null. Diese Lektion zeigt dir die vier wichtigsten Mail-bezogenen DNS-Records (MX, SPF, DKIM, DMARC) mit realistischen Beispielen, wie ein Empfänger-MTA sie zusammen auswertet (DMARC-Alignment), die typischen Fehler beim Einrichten und wie du eigene Records testest. Wer Mail-Server betreibt oder Domain-Admin ist, kommt um diese Lektion nicht herum.
1) Die vier wichtigen DNS-Records für E-Mail
Klick die Records an, um Aufbau, Beispiele und Bedeutung zu sehen:
2) Wie ein Empfänger eine eingehende Mail prüft
Was passiert konkret, wenn mx.partner.com eine Mail von alice@firma.de bekommt?
MAIL FROM: alice@firma.de, IP-Adresse des sendenden Servers: 198.51.100.10.firma.de TXT → SPF-Record. Steht 198.51.100.10 in der erlaubten Liste? Ergebnis: pass / fail / neutral / softfail.DKIM-Signature: d=firma.de; s=selector1; ...; b=<Hash>. Empfänger holt Public Key per DNS aus selector1._domainkey.firma.de, prüft die Signatur. Ergebnis: pass / fail.p=): none (zustellen), quarantine (Spam-Ordner), reject (ablehnen, 5xx Bounce).rua=mailto:dmarc@firma.de) an die Domain-Inhaber – nützlich für die Konfiguration.3) Beispiel-Auswertung – verschiedene Szenarien
Welche Mail kommt durch, welche wird abgelehnt?
4) DMARC-Policies – Stufen-Einführung
DMARC sollte nicht sofort auf reject stehen – das blockt legitime Mails, deren SPF/DKIM nicht sauber sind. Stufen-Plan:
- Stufe 1:
p=none+ Reporting. Keine Sperre, aber Reports kommen → siehst, welche Services in deinem Namen senden. - Auswertung 2-4 Wochen: alle legitimen Sender identifizieren und in SPF/DKIM aufnehmen.
- Stufe 2:
p=quarantine,pct=10. 10 % der nicht-konformen Mails wandern in Spam. Weiter beobachten. - Schrittweise hochfahren:
pct=25,50,100. Restliche Probleme klären. - Stufe 3:
p=reject,pct=100. Volle Schutz-Wirkung. Phishing in deinem Namen wird komplett abgewiesen.
5) Backup-MX – Failover für Mail
Es können mehrere MX-Records mit unterschiedlicher Priorität existieren. Niedrige Zahl = höhere Priorität:
| Priorität | MX-Host | Rolle |
|---|---|---|
| 10 | mx1.firma.de | Primärer Mailserver |
| 20 | mx2.firma.de | Sekundär – springt ein, wenn mx1 nicht antwortet |
| 30 | mx3.firma.de | Tertiär – Notfall-Relay |
Sender-MTA versucht zuerst Prio 10, dann 20, dann 30. Bei gleicher Priorität: Round-Robin.
6) Praktische Tools zum Testen
| Tool | Zweck |
|---|---|
dig MX firma.de | MX-Records einer Domain anzeigen |
dig TXT firma.de | SPF-Record (und andere TXT) |
dig TXT _dmarc.firma.de | DMARC-Record |
dig TXT selector1._domainkey.firma.de | DKIM-Public-Key |
| mxtoolbox.com | Web-Tool für alle Records inkl. Blacklist-Check |
| dmarcian.com | DMARC-Wizard und Report-Auswertung |
| mail-tester.com | Sendet Test-Mail, gibt 0-10-Score mit allen Findings |
| Google Postmaster Tools | Reputation deiner Domain bei Gmail |
7) Zusätzliche Mail-Records
Über die vier Hauptrecords hinaus gibt es noch:
- PTR (Reverse DNS): Pflicht für jeden sendenden Mail-Server. Empfänger prüfen, ob die IP einen passenden Reverse-Record hat. Fehler → Mail wird oft abgewiesen.
- MTA-STS: Erzwingt TLS für eingehende Mails (RFC 8461). TXT-Record
_mta-sts.firma.de+ Policy via HTTPS. - TLS-RPT: Reports über TLS-Fehlschläge (RFC 8460).
- BIMI (Brand Indicators for Message Identification): Logo deiner Marke neben der Mail im Posteingang – Voraussetzung: DMARC
p=quarantineoderreject. Verbreitung wächst. - DANE/TLSA: DNSSEC-basierte TLS-Zertifikats-Prüfung. In manchen Setups Alternative zu MTA-STS.
8) Antipatterns
- Kein SPF-Record gesetzt. Empfänger werten das oft als Spam-Indikator. Mindestens leerer SPF (
v=spf1 -all) oder mit eigenen Servern. - SPF mit zu vielen Includes. Limit: 10 DNS-Lookups.
include:_spf.google.com include:sendgrid.net ...kann das schnell sprengen. - SPF mit
+all. Alles erlauben = Schutz weg.-alloder~allverwenden. - DKIM-Key zu kurz. RSA-512 oder 1024 nicht mehr sicher. Mindestens RSA-2048, Trend zu Ed25519.
- DMARC direkt auf
p=rejectohne Vorlauf. Reißt legitime Mails ab, die du selbst gar nicht kennst (Newsletter, automatisierte Sender). Stufenplan einhalten. - DMARC ohne Reporting.
rua=fehlt → du erfährst nie, was im Hintergrund passiert. Verschwendete Chance. - Mehrere SPF-Records für eine Domain. RFC-Verstoß, viele Resolver werten dann gar keinen aus. Genau ein SPF-Record pro Domain.
- DKIM-Selector vergessen zu rotieren. Selektoren sollten alle 1-2 Jahre wechseln. Alte Selektoren entfernen.
- PTR-Record fehlt. Mail vom eigenen Server an externen Empfänger wird oft abgelehnt.
Zusammenfassung
Vier zentrale E-Mail-DNS-Records: MX (welche Server nehmen Mails für die Domain entgegen, mit Prioritäten), SPF (welche IPs dürfen im Namen der Domain senden, TXT-Record), DKIM (digitale Signatur jeder Mail, Public Key per DNS, Selektor-basiert), DMARC (Policy, was bei SPF/DKIM-Fehlschlag tun: none/quarantine/reject + optional Reports). Empfänger-MTA prüft sequenziell: SPF → DKIM → DMARC-Alignment (From-Header-Domain muss zu SPF- oder DKIM-Domain passen) → DMARC-Policy anwenden. DMARC-Einführung in Stufen: p=none mit Reports → quarantine mit steigendem pct → reject. Backup-MX über mehrere Prioritäten. Zusätzliche Records: PTR (Reverse DNS Pflicht), MTA-STS (TLS-Pflicht), TLS-RPT (TLS-Fehler-Reports), BIMI (Logo im Posteingang), DANE/TLSA. Tools: dig, mxtoolbox.com, mail-tester.com, dmarcian.com, Google Postmaster Tools. Antipatterns: kein SPF, SPF mit +all, DKIM-Key zu kurz, direkt p=reject, DMARC ohne Reporting, mehrere SPF-Records, fehlender PTR.
Verwandte Lektionen: DNS · SMTP-Protokoll · TLS & S/MIME · und mehrWeitere relevante LektionenSpam-SchutzPostfix & DovecotWie E-Mail funktioniertExchange/M365KryptografieSchwachstellenTLS