1. Inventar aller sendenden Systeme
Der häufigste Fehler ist nicht ein falscher Record, sondern ein vergessener Absender. Bevor du irgendetwas im DNS änderst, brauchst du eine Liste aller Systeme, die im Namen der Domain Mails verschicken. Frag den Kunden, und frag dann noch einmal nach, denn die Buchhaltung, der Vertrieb und die Shop-Agentur haben oft eigene Tools eingerichtet.
- Mailanbieter für die Postfächer: Microsoft 365, Google Workspace, ein Hoster-Postfach
- Shopsystem und ERP: Bestellbestätigungen, Rechnungen, Versandbenachrichtigungen
- CRM und Ticketsystem: HubSpot, Salesforce, Zendesk und ähnliche
- Newsletter-Tool: Mailchimp, Brevo, CleverReach, rapidmail
- Kontaktformulare der Website, oft direkt vom Webserver per PHP mail()
- Transaktionsdienste: SendGrid, Postmark, Amazon SES, Mailgun
- Drucker, Scanner, Monitoring-Systeme und Backup-Software, die Berichte verschicken
2. MX-Records und Altlasten
Die MX-Records müssen ausschließlich auf die Hosts des aktuellen Mailanbieters zeigen, mit den vom Anbieter vorgegebenen Prioritäten. Nach einem Wechsel bleibt oft ein alter MX mit niedrigerer Priorität stehen; der frühere Hoster nimmt dann Mail an oder lehnt sie ab, je nachdem, ob das Konto noch existiert. Auch ein verwaister Autodiscover- oder Webmail-Eintrag gehört aufgeräumt.
Prüfe mit dem MX Checker, ob jeder Host auflösbar ist, auf Port 25 antwortet, STARTTLS anbietet und ein gültiges Zertifikat für seinen Hostnamen präsentiert.
beispiel.de. IN MX 10 mail.beispiel.de.
beispiel.de. IN MX 20 mail2.beispiel.de.
Nach dem Wechsel zu Microsoft 365 darf nur noch das stehen:
beispiel.de. IN MX 0 beispiel-de.mail.protection.outlook.com.3. SPF: ein Record, unter zehn Lookups, -all
Genau ein TXT-Record mit v=spf1, der alle Absender aus dem Inventar abdeckt. Zähle die DNS-Lookups: Mehr als zehn ergeben einen permerror, und der ist schlimmer als kein SPF. Dienste mit festen IP-Adressen trägst du als ip4 oder ip6 ein, große Versender wie das Newsletter-Tool bekommen eine eigene Subdomain mit eigenem SPF. Am Ende steht -all; ~all ist nur für die Übergangsphase gedacht.
- Alle bestehenden TXT-Records prüfen und doppelte SPF-Records zusammenführen.
- Für jeden Absender aus dem Inventar den passenden include oder die IP eintragen.
- Lookups zählen und mit dem SPF Checker verifizieren, verwaiste includes entfernen.
- Mit ~all veröffentlichen, DMARC-Reports zwei Wochen beobachten, dann auf -all wechseln.
4. DKIM für jedes sendende System
Jedes System aus dem Inventar signiert seine Mails mit einem eigenen DKIM-Schlüssel unter einem eigenen Selektor, denn nur DKIM übersteht Weiterleitungen und ist für DMARC bei Newslettern und Transaktionsdiensten oft die einzige funktionierende Prüfung. Schlüssellänge 2048 Bit; 1024 Bit gelten als zu schwach und werden von manchen Empfängern abgewertet. Trage die CNAME- oder TXT-Records des Anbieters ein und aktiviere die Signierung dann im Anbieter-Panel, denn viele Dienste signieren erst nach einer manuellen Bestätigung.
Achte darauf, dass die DKIM-Domain (d=) mit der Absenderdomain übereinstimmt oder eine Subdomain davon ist, sonst gibt es keinen DMARC-Alignment. Notiere alle Selektoren im Kundeninventar, damit sie beim nächsten DNS-Umzug nicht verloren gehen.
5. DMARC: mit p=none starten, bis reject hochfahren
DMARC verbindet SPF und DKIM mit der sichtbaren Absenderadresse und gibt dir über die rua-Adresse Berichte über alle Mails, die im Namen der Domain gesendet werden. Beginne immer mit p=none und einer Reportadresse, damit du siehst, welche Absender noch nicht authentifiziert sind. Nach zwei bis vier Wochen sauberer Berichte gehst du auf p=quarantine, dann auf p=reject, gern zunächst mit pct=25 und schrittweiser Erhöhung.
Vergiss die Subdomains nicht: Ohne sp= gilt die Policy der Hauptdomain auch für Subdomains, was meist gewollt ist. Für nicht genutzte Subdomains ist das genau richtig. Nutzt der Kunde Subdomains für Newsletter oder Shops, brauchen diese ihre eigenen SPF- und DKIM-Records, sonst landen sie in der Quarantäne. BIMI mit Logo in der Inbox ist ein optionaler späterer Schritt, der p=quarantine oder p=reject und für die meisten Empfänger ein Verified Mark Certificate voraussetzt.
_dmarc.beispiel.de. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de; adkim=r; aspf=r"
Ziel nach dem Rollout:
_dmarc.beispiel.de. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de; sp=reject"6. Transport, Server und Zertifikate
Für Domains bei Anbietern, die MTA-STS unterstützen, richtest du TLS-RPT und anschließend MTA-STS im testing-Modus ein und schaltest nach Auswertung der Berichte auf enforce. Damit ist eingehende Mail gegen Downgrade-Angriffe geschützt. Betreibt der Kunde einen eigenen Mailserver, kommen PTR-Record und Forward-Confirmed reverse DNS dazu: Die IP muss auf den Hostnamen zeigen und der Hostname zurück auf die IP, und der HELO-Name muss dazu passen.
Die Zertifikate aller Mailhosts gehören in dieselbe Überwachung wie die der Websites. Ein abgelaufenes Zertifikat auf dem MX ist bei klassischem STARTTLS nur ein Schönheitsfehler, bei MTA-STS im enforce-Modus aber ein Zustellungsstopp.
7. Anforderungen von Google und Yahoo
Seit Februar 2024 gelten bei Google und Yahoo verbindliche Anforderungen an alle Absender, mit verschärften Regeln für Massenversender ab etwa 5000 Mails pro Tag an den jeweiligen Anbieter. Für Agenturkunden mit Newsletter oder Shop sind sie der praktische Maßstab, weil die Punkte alle Bereiche dieser Checkliste berühren.
- SPF und DKIM für die sendende Domain, bei Massenversendern beides
- Ein DMARC-Record, mindestens p=none, mit Alignment der From-Domain
- Gültiger PTR-Record für alle sendenden IPs
- TLS für die Zustellung
- One-Click-Unsubscribe per List-Unsubscribe-Header (RFC 8058) für Marketing-Mails, Abmeldung innerhalb von zwei Tagen umgesetzt
- Spam-Rate in Google Postmaster Tools unter 0,3 Prozent, besser unter 0,1 Prozent
8. Dokumentieren, nachprüfen, überwachen
Lege pro Kunde ein Dokument an: Absender-Inventar, alle Records mit Datum, Selektoren, Reportadressen und die Person beim Kunden, die über neue Tools Bescheid weiß. Nach jedem Hostingwechsel, jedem Anbieterwechsel und jeder Website-Migration läuft die Checkliste erneut, denn bei einem DNS-Umzug gehen erfahrungsgemäß genau die Records verloren, die niemand in der Zone erwartet hat: der DKIM-Selektor des CRM, der TLS-RPT-Record, der SPF der Newsletter-Subdomain.
Zwischen diesen Anlässen ändern sich Records trotzdem: Dienstleister ändern ihre includes, Kunden fügen Tools hinzu, Mitarbeiter löschen Einträge, die sie nicht kennen. Deshalb gehört jede Kundendomain in eine automatische Überwachung, die SPF, DKIM, DMARC, MX und Zertifikate regelmäßig prüft und jede Änderung meldet, nicht erst den Ausfall.
Häufige Fragen
- In welcher Reihenfolge setze ich das um?
- Inventar, MX, SPF, DKIM, DMARC mit p=none, dann Reports lesen. Erst wenn alle Absender pass liefern, DMARC verschärfen und danach MTA-STS und BIMI angehen. Wer DMARC vor dem Inventar auf reject stellt, verliert Mails.
- Wie lange dauert die komplette Einrichtung für eine Kundendomain?
- Die Records sind in ein bis zwei Stunden gesetzt. Der Rollout von DMARC bis p=reject dauert wegen der Beobachtungsphase realistisch vier bis acht Wochen. Plane das im Angebot ein.
- Muss ich das für jede Subdomain wiederholen?
- Für jede Subdomain, die Mails sendet, ja: eigener SPF, eigene DKIM-Selektoren. Subdomains ohne Mailversand deckt die DMARC-Policy der Hauptdomain mit sp=reject ab, und ein SPF mit v=spf1 -all verhindert Missbrauch.