DNS & E-Mail erklärt

Zwei Fragen beim Mailverkehr

Prüfen: E-Mail-Sicherheit (Einträge der Domain), Mailserver (STARTTLS, offenes Relay) und E-Mail-Header (was beim Empfänger tatsächlich herauskam).

SPF – erlaubte Absender-Server

Ein TXT-Eintrag an der Domain listet, welche Server Mails mit dieser Absenderadresse verschicken dürfen.

example.com.  TXT  "v=spf1 mx include:_spf.mailanbieter.example -all"

• mx, a, ip4:, ip6: und include: nennen erlaubte Server; -all lehnt alle anderen ab, ~all markiert sie nur (üblich zusammen mit DMARC).
• Höchstens 10 DNS-Abfragen (jedes include, a, mx, exists, redirect – auch verschachtelt). Darüber ignorieren Empfänger den Eintrag.
• Genau ein SPF-Eintrag pro Domain. +all erlaubt jedem Server der Welt das Senden.

DKIM – signierte Mails

Der Mailserver signiert jede Mail; den öffentlichen Schlüssel findet der Empfänger unter <selector>._domainkey.example.com. Den Selector zeigt der Header DKIM-Signature: … s=… einer gesendeten Mail.

mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"

• RSA mit mindestens 2048 Bit; unter 1024 Bit wird die Signatur ignoriert.
• Schlüssel erzeugt in der Regel der Mailanbieter oder die Mailserver-Software – der Eintrag wird nur übernommen.
• t=y ist der Testmodus; ein leeres p= widerruft den Schlüssel.

DMARC – was mit gefälschten Mails passieren soll

DMARC verbindet SPF und DKIM mit der sichtbaren Absenderadresse und sagt Empfängern, was sie bei Fälschungen tun sollen – und wohin sie Berichte schicken.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

1. Mit p=none beginnen und einige Wochen die Berichte (rua) auswerten: Welche Dienste senden im Namen der Domain?
2. Alle legitimen Absender per SPF/DKIM eintragen, dann auf p=quarantine (Spam-Ordner) und schließlich p=reject (Ablehnung) erhöhen.

Gehen die Berichte an eine fremde Domain (z. B. einen Auswertungsdienst), muss diese zustimmen: example.com._report._dmarc.dienst.example mit "v=DMARC1". Subdomains ohne eigenen Eintrag erben den der Hauptdomain (sp= gilt für sie).

Domain ohne E-Mail absichern

Auch Domains, die keine Mails senden oder empfangen, werden für Fälschungen missbraucht. Diese vier Einträge schließen das aus:

example.com.               MX   0 .
example.com.               TXT  "v=spf1 -all"
_dmarc.example.com.        TXT  "v=DMARC1; p=reject"
*._domainkey.example.com.  TXT  "v=DKIM1; p="

MX 0 . ist der Null-MX (RFC 7505): „diese Domain empfängt keine Mails“.

MTA-STS – Verschlüsselung erzwingen

Ohne MTA-STS oder DANE liefern sendende Server eine Mail auch unverschlüsselt aus, wenn ein Angreifer STARTTLS unterdrückt. MTA-STS besteht aus einem DNS-Eintrag und einer Datei auf einem Webserver mit gültigem Zertifikat:

_mta-sts.example.com.  TXT  "v=STSv1; id=20261020"

https://mta-sts.example.com/.well-known/mta-sts.txt:
version: STSv1
mode: testing
mx: mail.example.com
max_age: 604800

• Mit mode: testing starten (Fehler werden nur gemeldet), danach enforce.
• Jeder MX muss in einer mx:-Zeile stehen (*.example.com deckt eine Ebene ab).
• Bei jeder Änderung der Datei die id im DNS-Eintrag ändern; die Datei darf nicht weitergeleitet werden.

TLS-RPT – Berichte über Verschlüsselungsfehler

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Sendende Server melden täglich, ob die verschlüsselte Zustellung geklappt hat – besonders nützlich während mode: testing.

DANE / TLSA – Zertifikat im DNS festlegen

Ein TLSA-Eintrag nennt den Schlüssel, den ein Server verwenden muss. Clients beachten ihn nur, wenn die Zone per DNSSEC signiert ist. Für Mailserver (Port 25):

_25._tcp.mail.example.com.  TLSA  3 1 1 <SHA-256 des öffentlichen Schlüssels>

Den Wert berechnet:

openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256

• 3 1 1 (DANE-EE, öffentlicher Schlüssel, SHA-256) bleibt bei einer Zertifikatsverlängerung gleich, solange der Schlüssel bleibt – bei Let's Encrypt z. B. mit --reuse-key.
• Vor einem Schlüsselwechsel den neuen Eintrag zusätzlich veröffentlichen und die TTL abwarten – sonst lehnen DANE-fähige Server die Zustellung ab.
• Das Werkzeug DANE / TLSA zeigt den passenden Eintrag für das aktuell ausgelieferte Zertifikat an.

DNSSEC – signierte DNS-Antworten

DNSSEC schützt vor gefälschten DNS-Antworten. Die Zone wird signiert (meist schaltet das der DNS-Anbieter ein), und beim Registrar wird ein DS-Eintrag hinterlegt, der auf den Schlüssel der Zone verweist. So entsteht eine Kette von der Root-Zone bis zur Domain.

• Empfohlen: Algorithmus 13 (ECDSAP256SHA256). RSASHA1 (5, 7) ist veraltet.
• Häufigster Fehler: Beim Wechsel des DNS-Anbieters bleibt der alte DS-Eintrag beim Registrar stehen. Validierende Resolver liefern dann SERVFAIL – die Domain ist für sie nicht mehr erreichbar.
• Signiert, aber ohne DS-Eintrag: DNSSEC wirkt nicht.

Prüfen: Domain prüfen zeigt die Kette Zone für Zone; DS-Eintrag erzeugen berechnet den Eintrag für den Registrar.

CAA – wer Zertifikate ausstellen darf

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild ";"
example.com.  CAA  0 iodef "mailto:security@example.com"

Zertifizierungsstellen müssen den Eintrag vor jeder Ausstellung prüfen. issuewild ";" verbietet Wildcard-Zertifikate. Der Server-Check zeigt, ob die aktuelle CA erlaubt ist.

Nameserver, TTL und „Propagation“

• Mindestens zwei Nameserver, möglichst in verschiedenen Netzen; alle müssen autoritativ antworten und dieselbe SOA-Seriennummer haben.
• Die Nameserver beim Registrar (Delegation) und die NS-Einträge in der Zone sollten übereinstimmen.
• Änderungen sind auf den eigenen Nameservern sofort sichtbar. Andere DNS-Server behalten die alte Antwort bis zum Ablauf ihrer TTL – daher „dauert“ eine Änderung. Vor geplanten Umzügen die TTL einige Zeit vorher senken.

Prüfen: Zonen-Überblick (TTL, SOA, Wildcards), Domain prüfen (Nameserver, Seriennummern) und DNS-Abfrage mit „Bei mehreren DNS-Servern vergleichen“.

Reverse-DNS (PTR) für Mailserver

Wer Mails versendet, braucht zur IP-Adresse einen PTR-Eintrag, dessen Name wieder auf dieselbe Adresse zeigt (z. B. 203.0.113.25 → mail.example.com → 203.0.113.25). Viele Empfänger lehnen Mails ohne passendes Reverse-DNS ab. Den PTR-Eintrag setzt der Anbieter der IP-Adresse (Hoster, Provider), nicht der DNS-Anbieter der Domain.

Prüfen: IP-Adresse.