Domain und E-Mail: die Technik unter der Website

Worum es geht

Unter jeder Website liegt eine Domain, und an dieser Domain hängen Einträge, die nichts mit der Website zu tun haben — aber sehr viel damit, ob deine E-Mails ankommen und ob jemand in deinem Namen schreiben kann.

Drei DNS-Einträge sind dabei zentral: SPF legt fest, welche Server für deine Domain Mails verschicken dürfen. DKIM signiert ausgehende Mails kryptografisch. DMARC verbindet beides und sagt Empfängern, was mit Mails geschehen soll, die durchfallen.

Dazu kommt die Domain selbst: Wann läuft sie ab? Ist sie gegen Umzug gesperrt? Und sind mehr als ein Nameserver eingetragen?

Warum das zählt

Ohne diese Einträge kann jeder eine E-Mail verschicken, die aussieht, als käme sie von deiner Adresse. Das ist die Grundlage der meisten Betrugsmails im Geschäftsverkehr — eine Rechnung mit geänderter Kontonummer, angeblich von dir. Und in der Gegenrichtung landen deine eigenen Mails im Spam, weil der Empfänger nicht prüfen kann, ob sie echt sind.

Der häufigste Befund in der Praxis ist ein DMARC-Eintrag mit p=none. Der sieht konfiguriert aus und verhindert nichts. Er sagt Empfängern nur: Beobachte und melde. Ohne dass jemand die Berichte tatsächlich liest, ist das reine Kulisse.

Der Weg dahin ist trotzdem richtig: Erst p=none, dann vier bis zwölf Wochen die Berichte auswerten, jede legitime Fehlkonfiguration beheben, dann auf p=quarantine und schließlich auf p=reject stellen. Der Fehler ist nicht der Start bei p=none, sondern das Steckenbleiben dort.

Ein Fehler, den man dem SPF-Eintrag nicht ansieht: Die Auswertung darf höchstens zehn DNS-Abfragen verbrauchen — so schreibt es RFC 7208 vor. Jedes include zählt, und zwar rekursiv: include:_spf.google.com allein löst intern drei weitere Abfragen aus. Wird die Grenze überschritten, liefert die Prüfung einen dauerhaften Fehler, und DMARC behandelt das wie ein hartes Durchfallen. Das heißt: Eine sorgfältig gepflegte Domain ist dann exakt so gut geschützt wie eine ohne Eintrag. Der Eintrag liest sich dabei völlig in Ordnung, und die Grenze wird überschritten, indem man einen weiteren Dienst zu einem schon vollen Eintrag hinzufügt.

Zwei Nebenbemerkungen zur Einordnung:

DKIM lässt sich von außen nicht prüfen. Der Schlüssel liegt unter einem Namen, den niemand erraten kann. Wenn ein Bericht dazu nichts sagt, heißt das „nicht geprüft" — nicht „fehlt".

Und für deutsche und österreichische Domains gilt: DENIC und nic.at veröffentlichen kein Ablaufdatum. Für die meisten Kundendomains lässt sich die Frage nach dem Ablauf von außen also gar nicht beantworten.

Es gibt außerdem eine Reihe weiterführender Mechanismen — DANE, MTA-STS, TLS-Reporting —, die in Prüfungen gern rot erscheinen. Sie hängen an DNSSEC und an Einträgen, die der Mail-Anbieter veröffentlichen muss. Das sind Eigenschaften des Hostings, keine Versäumnisse der Website. Sie als Fehler zu melden, hätte einen unangenehmen Nebeneffekt: Eine Kategorie, die in jedem Bericht rot ist, lernt der Leser zu überspringen — und nimmt dabei die echten Befunde daneben mit.

Wie du das selbst prüfst

Der einfachste Weg führt über MXToolbox (mxtoolbox.com). Gib deine Domain ein und ruf nacheinander die Prüfungen für SPF und DMARC auf. Beim SPF zeigt das Werkzeug direkt die verbrauchte Anzahl DNS-Abfragen — genau die Zahl, die unter zehn bleiben muss.

Für DMARC schaust du dir den p=-Wert an: Steht dort none, ist der Eintrag da, aber wirkungslos.

Auf der Kommandozeile geht dasselbe schneller:

dig +short txt deinedomain.de
dig +short txt _dmarc.deinedomain.de

Für den Praxistest: Schick dir selbst eine Mail von deiner Geschäftsadresse an eine Gmail-Adresse. Öffne dort in den Details „Original anzeigen". Ganz oben steht, ob SPF, DKIM und DMARC bestanden haben.

Und für die Nameserver: Wenn dort nur einer eingetragen ist, hat die Domain keinen Ausfallschutz.

Was zu tun ist, wenn es fehlt

Fang mit DKIM an, nicht mit SPF. DKIM überlebt Weiterleitungen — SPF nicht. Wenn eine Mail über einen Verteiler oder eine Weiterleitung läuft, ändert sich die absendende IP, und SPF fällt durch. Die DKIM-Signatur bleibt intakt. Für einen späteren Umstieg auf p=reject ist DKIM deshalb der verlässlichere Pfad.

Setz einen DMARC-Eintrag mit p=none und einer Berichtsadresse, lies die Berichte, und arbeite dich dann hoch. Vergiss sp= nicht — ohne diese Angabe erben Subdomains die Hauptpolitik, und eine ausdrückliche Regel schließt die Lücke, über die jemand rechnung.deinedomain.de fälschen könnte.

Wenn dein SPF-Eintrag nahe an der Zehnergrenze ist: Wirf die Dienste raus, die gar nicht darin stehen müssen. Viele Marketing-Anbieter versenden über eine eigene Absenderdomain und brauchen keinen Eintrag bei dir — die Zeile ist dann eine verschwendete Abfrage. Der nächste Schritt wäre, Newsletter und Transaktionsmails auf eigene Subdomains zu legen; jede bekommt ihr eigenes Zehner-Budget.

Für die Berichte: Postmark bietet eine kostenlose Auswertung. Wenn Datenresidenz eine Rolle spielt, sind URIports (Niederlande) oder dmarcian-EU (Brüssel) die passenderen Adressen.

Und die Domain selbst: Transfersperre einschalten, Verlängerung automatisieren, mindestens zwei Nameserver eintragen. Das sind drei Klicks beim Registrar und der billigste Ausfallschutz, den es gibt.

Quellen

• SPF nach RFC 7208 mit harter Grenze von 10 DNS-Abfragen je Auswertung; include, a, mx, ptr, exists und redirect zählen, ip4, ip6 und all nicht; verschachtelte includes zählen rekursiv, include:_spf.google.com löst intern drei weitere Abfragen aus; Überschreiten liefert PermError, das DMARC wie ein hartes SPF-Fail behandelt; SPF bricht bei Weiterleitungen, DKIM übersteht sie; nicht benötigte SaaS-Einträge entfernen; Aufteilung auf Subdomains gibt jedem Sendestrom ein eigenes Budget; MXToolbox zeigt die Abfragezahl -- @ctx:atlas-services-email-deliverability-spf@1
• DMARC als DNS-TXT-Eintrag unter _dmarc.; p=none nur beobachtend, p=quarantine, p=reject; empfohlener Ausrollpfad p=none über 4 bis 12 Wochen mit Auswertung der Aggregatberichte, dann Verschärfung; p=none ohne Auswertung der rua-Berichte ist wirkungslos; sp= fehlt häufig und lässt Subdomains als Impersonationsfläche offen; DKIM als primärer Pfad vor der Umstellung auf p=reject wegen Weiterleitungen; Postmark kostenlos, URIports (NL) und dmarcian-EU (Brüssel) für Datenresidenz; ruf-Berichte sind datenschutzsensibel -- @ctx:atlas-services-email-deliverability-dmarc@1
• DENIC und nic.at veröffentlichen kein Ablaufdatum und betreiben kein RDAP, weshalb diese Angabe für die meisten deutschen Kundendomains nicht ermittelbar ist; DKIM sitzt an einem nicht erratbaren Selektor und wird als nicht geprüft statt als fehlend geführt; DANE, MTA-STS und TLS-Reporting hängen an DNSSEC und an Einträgen des Mail-Anbieters und sind Eigenschaften des Hostings; eine in jedem Bericht rote Kategorie lernt der Leser zu überspringen und nimmt die echten Befunde daneben mit; Nameserver-Redundanz und Transfersperre als Prüfpunkte -- @ctx:projects-tools-checky-workbench-docs-tech-specs-probe-catalog-trust@7