Die 7 DNS-Einträge, die jeder Self-Hosted-E-Mail-Absender braucht

E-Mail ist ungewöhnlich: Ein vollständiges Absender-Setup hat sieben unterschiedliche DNS-Einträge, verteilt über drei oder vier Eintragstypen. Vergessen Sie einen, und Nachrichten bewegen sich weiterhin auf der Leitung — aber Mailbox-Anbieter werden Sie stillschweigend in den Spam-Ordner abstufen. Veröffentlichen Sie alle sieben, und Sie überschreiten die „alles, was Google verlangt"-Schwelle aus /guide/email-deliverability.

Die Reihenfolge zählt: SPF und DKIM sollten stehen, bevor DMARC beginnt, die Ausrichtung zu erzwingen, sonst wird legitime Mail in die Quarantäne geschickt. Die stehende Regel über Anbieter hinweg lautet außerdem „Wartet auf die DNS-Propagation" — lassen Sie mindestens 30 Minuten zwischen dem Veröffentlichen eines Eintrags und der Bitte an den Mailbox-Anbieter, erneut zu prüfen.

MX-Einträge (RFC 1035 §3.3.9) sagen der Welt, wohin eingehende Mail für Ihre Domain zuzustellen ist. Selbst wenn Ihre Absenderdomain „nur ausgehend" ist (Sie lesen darauf keine Antworten), ist ein MX-Eintrag dennoch erforderlich — viele Mailbox-Anbieter stufen die Reputation für Domains ohne MX herab, mit der Annahme, dass legitime Absender Antworten akzeptieren. Ein einzelner Eintrag, der auf einen beliebigen erreichbaren Mailserver zeigt, genügt, selbst wenn dieser Server nur an ein Postmaster-Postfach zustellt.

SPF (RFC 7208) ist ein einzelner TXT-Eintrag, der die für die Domain autorisierten IPs auflistet. Die harte Regel: Die rekursiven DNS-Lookups insgesamt müssen unter 10 bleiben (RFC 7208 §4.6.4). Jeder include: verbraucht einen; verschachtelte Includes zählen kumulativ. ip4:- / ip6:-Mechanismen kosten keine Lookups, also fassen Sie alte Includes in explizite IP-Bereiche zusammen, wenn Ihr Count hochkriecht.

Schließen Sie mit -all (Hard-Fail) ab, sobald Sie verifiziert haben, dass alle legitimen Sendequellen abgedeckt sind. Wenn Sie noch unsicher sind, beginnen Sie mit ~all (Soft-Fail) und ziehen Sie nach zwei Wochen sauberer DMARC-Reports auf -all nach.

DKIM (RFC 6376) veröffentlicht die öffentliche Hälfte eines Signatur-Schlüsselpaares als TXT-Eintrag unter {selector}._domainkey.{domain}. Der „Selector" ist ein Bezeichner, den Sie wählen — vendor-spezifisch oder beliebig. Für SES gibt AWS Ihnen drei CNAMEs, die auf AWS-verwaltete TXT-Einträge auflösen (damit AWS Schlüssel rotieren kann, ohne dass Sie DNS anfassen):

Für Self-Hosted Postal oder Postfix+OpenDKIM erzeugen Sie das Schlüsselpaar lokal, konfigurieren die MTA zum Signieren und veröffentlichen die öffentliche Hälfte als TXT:

Welchen Weg Sie auch gehen: Verifizieren Sie mit dig TXT {selector}._domainkey.{domain}, bevor Sie DKIM für erledigt erklären.

DMARC (RFC 7489) liegt unter _dmarc.{domain}. Die Rampe über p=none zu überspringen, ist der häufigste Fehler — direkt auf p=reject gegen eine Domain zu springen, deren Mail-Flows Sie noch nicht vollständig verstehen, lässt legitime Mail still verschwinden (Forwarder, Mailing-Listen, Drittanbieter-CRM-Absender).

Lesen Sie die täglichen Aggregate-XML-Reports, die in Ihrem rua-Postfach landen, zwischen den Phasen. Tools wie der DMARC-Analyzer von Postmark oder das Self-Hosted-Parsedmarc visualisieren sie; das nackte XML ist dicht, aber lesbar.

Standardmäßig kommen die Open-Pixel- und Click-Tracking-URLs von AcelleMail aus der Hauptdomain Ihrer Installation. Mailbox-Anbieter sehen es gerne, wenn From, Klick-Links und Abmelde-URL über konsistente Root-Domains laufen — alle auf derselben registrierten Domain. Auch markentechnisch sind Links, die auf tracker.ihrunternehmen.de zeigen, vertrauenswürdiger als Links, die auf links.acellemail.com zeigen.

Sobald der CNAME auflöst, schreibt AcelleMail alle Klick-Tracking-URLs in ausgehenden Nachrichten so um, dass sie ihn verwenden. Die Domain des Abmelde-Links folgt derselben Regel (und demselben CNAME).

MTA-STS (RFC 8461) sagt anderen Absendern „Verlangt immer TLS bei Zustellung an meinen MX". Ohne MTA-STS kann ein Angreifer auf dem Pfad einen TLS-fähigen Handshake auf Klartext herabstufen. Mit MTA-STS verweigert der sendende Server die Zustellung, wenn TLS nicht etabliert werden kann. Die Umsetzung ist ein TXT-Eintrag, der auf eine gehostete Policy-Datei zeigt:

Lassen Sie die Policy in der ersten Woche im mode: testing laufen, dann auf mode: enforce umschalten. Viele Bulk-Sender überspringen MTA-STS — es bereitzustellen, ist ein kostenloses Vertrauenssignal.

BIMI (Brand Indicators for Message Identification) ist der jüngste der sieben Einträge und der einzige, der noch kein finalisierter RFC ist, aber er wird von Gmail, Yahoo, Apple Mail, Fastmail und anderen Clients produktiv unterstützt. Der Deal: einen TXT-Eintrag veröffentlichen, der auf ein SVG-Logo zeigt, und (optional) ein Verified Mark Certificate (VMC) — unterstützende Clients zeigen das Logo dann neben Ihren Nachrichten in der Posteingangsliste an.

Voraussetzungen: eine DMARC-Policy von mindestens p=quarantine (BIMI wird unter p=none nicht beachtet), und das SVG muss SVG Tiny Portable / Secure (SVG-PS) sein. Akzeptanz variiert: Gmail verlangt für die volle Anzeige in der Posteingangsliste ein kostenpflichtiges VMC ($1.500/Jahr über DigiCert / Entrust); Yahoo und Apple akzeptieren BIMI ohne VMC. Öffnungsraten-Hebungen von 5-20 % werden in veröffentlichten Fallstudien häufig berichtet.

Nach der Veröffentlichung senden Sie sich selbst eine Testnachricht und prüfen die Header. Gmail Web: Nachricht öffnen, Drei-Punkte-Menü, „Original anzeigen". Suchen Sie nach:

Drei pass-Verdikte sind die Latte. Alles darunter — fail, softfail, neutral — bedeutet, dass ein Eintrag falsch ist, dass DNS noch nicht propagiert ist oder dass der Mail-Body auf dem Transportweg verändert wird (selten). Bei zweifelhaftem Verdikt mit der kanonischen Spezifikation des Authentication-Results-Headers (RFC 8601) abgleichen.