Anleitungen

Die Reihenfolge, in der sich das aufbaut

Die Anleitungen bauen aufeinander auf. Wer in dieser Reihenfolge vorgeht, muss nichts zweimal machen:

1. Reverse DNS — nur relevant, wenn du selbst einen Mailserver betreibst. Ohne passenden PTR-Eintrag lehnen viele Empfänger schon ab, bevor sie überhaupt in die Nachricht sehen.
2. SPF-Record erstellen — legt fest, welche Server im Namen deiner Domain senden dürfen. Der günstigste erste Schritt, weil er nur einen TXT-Eintrag kostet.
3. DKIM einrichten — signiert jede Nachricht kryptographisch. Anders als SPF übersteht DKIM Weiterleitungen und ist damit der belastbarere der beiden Nachweise.
4. DMARC einrichten — verknüpft SPF und DKIM mit der sichtbaren Absenderadresse und sagt dem Empfänger, was bei einem Fehlschlag zu tun ist. Start bei p=none mit einer rua-Adresse.
5. Reports auswerten, dann verschärfen — nach einigen Wochen Aggregate-Reports auf p=quarantine, später auf p=reject.
6. MTA-STS und TLS-RPT — sichert die Transportverschlüsselung gegen Downgrade-Angriffe ab. Sinnvoll, sobald die Authentifizierung steht.
7. BIMI — das Logo im Posteingang. Setzt eine durchgesetzte DMARC-Policy voraus und steht deshalb am Ende, nicht am Anfang.

Die Reihenfolge ist kein Selbstzweck: DMARC wertet ausschließlich die Ergebnisse von SPF und DKIM aus. Wer DMARC vor den beiden anlegt, veröffentlicht eine Regel, an der jede eigene Nachricht scheitert.

Warum p=reject nicht am Anfang steht

Der häufigste Fehler beim DMARC-Einstieg ist die scharfe Policy zu früh. In fast jeder Organisation sendet mehr im Namen der Domain, als zunächst bekannt ist: das Newsletter-Tool, das Ticketsystem, die Buchhaltungssoftware, ein altes Kontaktformular, der Kalender-Server. Jede dieser Quellen fällt bei p=reject aus — und zwar unsichtbar, denn abgelehnte Mail landet nirgends, auch nicht im Spam-Ordner.

p=none mit rua ändert an der Zustellung nichts, liefert aber genau die Liste dieser Absender. Erst wenn dort nur noch Bekanntes auftaucht, ist das Verschärfen risikofrei.

Wie lange DNS-Änderungen brauchen

Jeder DNS-Eintrag trägt eine TTL — die Zeit, die ein fremder Resolver die alte Antwort behalten darf. Eine Änderung wirkt deshalb nicht sofort überall, sondern frühestens nach Ablauf der TTL des alten Eintrags. Vor einer Umstellung hilft es, die TTL ein bis zwei Tage vorher auf einen kleinen Wert zu senken und sie danach wieder hochzusetzen.

Ob die Änderung angekommen ist, lässt sich direkt nachsehen: der SPF-Check, der DMARC-Check und der MX-Check lesen den Live-Stand aus dem DNS.

Wenn schon etwas kaputt ist

Steht die sendende IP bereits auf einer Blacklist, hilft eine Neukonfiguration allein nicht: Zuerst muss die Ursache geschlossen sein — offenes Relay, kompromittiertes Postfach, ein Formular ohne Rate-Limit —, sonst folgt der nächste Eintrag in wenigen Tagen, und jedes wiederholte Delisting wird schwerer. Der Delisting-Leitfaden geht das der Reihe nach durch.

Wenn die Grundlage steht

Die sieben Schritte oben sind die Pflicht. Danach hängt es davon ab, was du tust:

• Du betreibst einen eigenen Mailserver. Dann geht es um den Transport: das Zertifikat auf den richtigen Namen und, sofern deine Zone DNSSEC-signiert ist, DANE. Beides entscheidet erst dann über die Zustellung, wenn MTA-STS oder DANE im Spiel sind — vorher ist Verschlüsselung unverbindlich.
• Du versendest an viele Empfänger. Dann gelten seit 2024 feste Anforderungen, dazu die Abmeldung mit einem Klick. Und wenn IP oder Domain neu sind, kommt das Aufwärmen davor.
• Dein SPF-Record ist gewachsen. Über zehn DNS-Abfragen wird er ungültig — wie man ihn wieder unter die Grenze bringt, ohne Absender zu verlieren.

Anleitung, Check oder Fehlermeldung?

Drei Bereiche mit unterschiedlichem Zweck: Die Anleitungen hier zeigen, wie du etwas einrichtest. Die Checks erklären, was der Report prüft und wie ein Ergebnis zu lesen ist. Und wenn dein Mailserver eine konkrete Meldung zurückgegeben hat, findest du sie wörtlich bei den Fehlermeldungen.