DNS-Records

Kurz: Einträge in der DNS-Zone einer Domain, die u. a. festlegen, welcher Server für die Domain zuständig ist (A-Record), welche Adresse ein Alias hat (CNAME), oder welche Server E-Mails empfangen dürfen (MX).

Genauer: Wichtige Typen: A (Domain → IP-Adresse), CNAME (Domain → andere Domain), TXT (beliebiger Text, z. B. für Domain-Verifizierung oder SPF/DKIM), MX (Mail-Server-Zuständigkeit). Ein Wildcard-Eintrag (*.domain.de) deckt beliebige Subdomains gleichzeitig ab — bei extern verwalteten DNS-Anbietern (wie hier OVH) lässt sich das nicht mit einzelnen A/CNAME-Records lösen, dafür müsste der Hosting-Anbieter die komplette Nameserver-Verwaltung übernehmen.

Kontext bei uns: In OVH verwaltet — u. a. TXT-Records zur Vercel-Domain-Verifizierung, sowie DKIM/SPF für Resend. Ein Wildcard-Eintrag wird später für das geplante Multi-Tenant-Modell (Subdomains pro Kunde) gebraucht.

Im Detail

SPF und DKIM im Detail

SPF und DKIM (beide über TXT-Records eingerichtet) sind zwei unterschiedliche, sich ergänzende Mechanismen, mit denen E-Mail-Empfänger prüfen, ob eine Mail wirklich von der angegebenen Domain stammt und nicht gefälscht ist:

• SPF (Sender Policy Framework) listet auf, welche Mailserver überhaupt berechtigt sind, im Namen der Domain zu versenden — der Empfänger prüft, ob der tatsächlich sendende Server auf dieser Liste steht. Ein typischer SPF-Record sieht aus wie v=spf1 include:_spf.resend.com ~all — include verweist auf die Serverliste des Mail-Dienstleisters, ~all markiert nicht gelistete Absender als “soft fail” (verdächtig, aber nicht hart abgelehnt).
• DKIM (DomainKeys Identified Mail) signiert jede ausgehende Mail kryptografisch mit einem privaten Schlüssel; der Empfänger prüft die Signatur gegen den öffentlichen Schlüssel, der als TXT-Record veröffentlicht ist — bestätigt, dass die Mail unterwegs nicht verändert wurde. Anders als SPF (das nur den SENDENDEN Server prüft) sichert DKIM zusätzlich die Integrität des Inhalts selbst ab.

Ein dritter, oft übersehener Mechanismus ist DMARC (ebenfalls ein TXT-Record), der festlegt, was mit Mails passieren soll, die SPF und/oder DKIM nicht bestehen (ablehnen, in Spam verschieben, oder nur protokollieren) — und optional eine Adresse für Berichte über fehlgeschlagene Prüfungen angibt. Ohne DMARC-Record entscheidet jeder Empfänger-Mailserver nach eigenem Ermessen, was mit fehlgeschlagenen SPF/DKIM-Prüfungen passiert.

Konsequenzen fehlender Einrichtung

Ohne beide korrekt eingerichtet landen ausgehende Mails bei vielen Empfängern (v. a. Gmail, Outlook) automatisch im Spam-Ordner oder werden ganz abgelehnt — Mail-Dienste wie Resend stellen die nötigen TXT-Record-Werte im Dashboard bereit, die man dann beim eigenen DNS-Anbieter (hier OVH) einträgt. Ein häufiger Stolperstein: DNS-Änderungen brauchen Zeit zur Verbreitung (Propagation) über das globale DNS-System — je nach TTL des vorherigen Eintrags und Zwischenspeicherung bei verschiedenen Resolvern kann das von Minuten bis zu 48 Stunden dauern, weshalb eine frisch eingerichtete Mail-Domain nicht sofort zuverlässig funktioniert.

Record-Typen im Vergleich

Über die im Kurzabschnitt genannten Typen hinaus gibt es u. a. AAAA (wie A, aber für IPv6-Adressen statt IPv4), NS (legt fest, welche Nameserver für die Domain überhaupt autoritativ sind — die “Meta-Ebene” über allen anderen Records), und SRV (für Dienste, die einen bestimmten Host UND Port kombiniert brauchen, z. B. manche VoIP- oder Chat-Protokolle). Jeder Record-Typ hat eine eigene TTL, die unabhängig von anderen Records derselben Domain konfiguriert werden kann — sinnvoll niedrig gesetzt kurz vor einer geplanten Änderung, damit diese schneller wirksam wird.

Siehe auch: Multi-Tenant-Architektur, Resend, TTL, CNAME