DMARC-Eintrag mit Generator erstellen und die Policy sicher hochstufen

Ein DMARC-Eintrag von Hand getippt hat oft einen von zwei Fehlern: eine falsche Tag-Syntax oder eine zu aggressive Policy vom ersten Tag an. Beides kann bei laufenden Kaltakquise-Kampagnen dazu führen, dass legitime Mails blockiert werden, bevor Sie überhaupt wissen, wer eigentlich in Ihrem Namen versendet. Dieser Artikel zeigt, wie ein DMARC-Generator den Eintrag baut und wie Sie die Policy in kontrollierten Schritten hochstufen, ohne Ihre eigene Zustellbarkeit zu gefährden.

Warum ein Generator besser ist als der Eintrag von Hand

Ein DMARC-Record ist ein einzelner TXT-Eintrag unter _dmarc.ihredomain.de, aber die Syntax ist unnachsichtig: Tags müssen mit Semikolon getrennt werden, v=DMARC1 muss als erstes Tag stehen, und ein fehlendes Semikolon oder ein Leerzeichen an der falschen Stelle kann dazu führen, dass Mail-Provider den gesamten Eintrag ignorieren, ohne eine Fehlermeldung an Sie zurückzugeben. Anders als bei einem falsch konfigurierten Webserver gibt es hier keinen Fehlercode, der Sie warnt — der Record liegt einfach ungenutzt im DNS, und Sie merken es erst an ausbleibenden Reports oder an sinkender Zustellrate.

Ein Generator — etwa der von MXToolbox oder vergleichbare kostenlose Tools, auch für Microsoft-365-Umgebungen — führt Sie durch die einzelnen Tags, erklärt deren Wirkung und baut daraus eine syntaktisch korrekte Zeile. Das ersetzt nicht das Verständnis der Tags, aber es nimmt Ihnen die Fehleranfälligkeit beim reinen Abtippen ab, besonders wenn Sie den Eintrag für mehrere Sending-Domains parallel pflegen und dieselben Werte nicht jedes Mal neu aus dem Gedächtnis rekonstruieren wollen.

Für Teams, die regelmäßig neue Subdomains für Kaltakquise-Kampagnen anlegen, ist ein Generator zusätzlich deshalb praktisch, weil er sich als wiederholbarer Schritt in eine Setup-Checkliste einbauen lässt — ohne dass jede neue Person im Team die komplette Tag-Syntax auswendig kennen muss.

Ein zusätzlicher Vorteil, der in der Praxis oft übersehen wird: Ein Generator zwingt Sie dazu, jeden einzelnen Tag bewusst auszufüllen, statt einen vorgefundenen Beispiel-Record aus einem alten Blogartikel einfach zu kopieren und nur die Domain auszutauschen. Kopierte Beispiel-Records enthalten erstaunlich häufig eine rua-Adresse, die noch auf den ursprünglichen Autor verweist, oder eine Policy-Stufe, die für eine frische Domain viel zu aggressiv ist.

Die wichtigsten Tags: was ein Generator eigentlich fragt

Bevor Sie einen Generator öffnen, hilft es zu wissen, wonach er fragt und warum. Die folgenden Tags entscheiden über die tägliche Wirkung Ihres DMARC-Eintrags — und über das, was Sie in den kommenden Wochen an Berichten und an Zustellverhalten sehen werden:

• v=DMARC1 — feste Versionskennung, immer identisch, immer an erster Stelle.
• p= — die Hauptregel für die Domain selbst: none (nur beobachten), quarantine (in Spam/Junk verschieben) oder reject (Annahme verweigern).
• sp= — die Regel für Subdomains, falls abweichend von p. Ohne diesen Tag gilt für Subdomains automatisch der Wert von p.
• rua= — die Adresse (oder mehrere, mit Komma getrennt), an die tägliche Aggregatberichte gehen. Fast immer gesetzt, da diese Berichte Ihre wichtigste Kontrollquelle sind.
• ruf= — die Adresse für forensische Einzelberichte pro fehlgeschlagener Mail. Wird von den meisten großen Providern aus Datenschutzgründen kaum noch bedient, ist aber weiterhin ein gültiges Tag.
• pct= — der Prozentsatz der Mails, auf den die Policy angewendet wird. Der zentrale Hebel für einen vorsichtigen Rollout.
• adkim= und aspf= — der Alignment-Modus, s für strict oder r für relaxed, für DKIM beziehungsweise SPF.
• fo= — steuert, wann forensische Berichte ausgelöst werden, relevant nur in Kombination mit ruf.

Schritt 1: Mit p=none beobachten, bevor Sie etwas blockieren

Der erste produktive DMARC-Eintrag sollte praktisch immer mit p=none beginnen, kombiniert mit einer gesetzten rua-Adresse. In diesem Modus passiert für den E-Mail-Fluss selbst nichts — keine Mail wird blockiert oder in Spam verschoben —, aber Sie erhalten ab sofort tägliche Berichte darüber, welche Server in Ihrem Namen Mails verschicken und ob diese SPF und DKIM bestehen.

Für Cold-Outreach-Domains ist diese Beobachtungsphase besonders wichtig, weil Sie häufig mehrere Versandkanäle parallel nutzen: das eigentliche Outreach-Tool, gelegentlich ein CRM mit eigenem Mailversand, vielleicht ein Transaktions-Mailer für Antwort-Benachrichtigungen. Erst die rua-Berichte zeigen zuverlässig, ob wirklich alle diese Absender sauber authentifiziert sind — ein manueller Testversand aus jedem einzelnen Tool deckt selten alle real genutzten Versandpfade ab.

Planen Sie für diese Phase mindestens zwei bis vier Wochen ein, bei mehreren aktiven Domains eher am oberen Ende. Gerade unregelmäßig genutzte Postfächer, etwa ein Backup-Account, der nur bei Ausfällen des Hauptpostfachs einspringt, tauchen sonst erst nach mehreren Wochen überhaupt in den Berichten auf.

Ein häufiger Einwand gegen diese Wartezeit: Man möchte doch möglichst schnell zu einer schützenden Policy kommen. Das Argument stimmt für die Zielrichtung, aber nicht für das Tempo — eine Domain, die zwei Wochen zu spät auf quarantine wechselt, verliert kaum etwas, während eine Domain, die zu früh wechselt und dabei den eigenen Rechnungsversand blockiert, einen konkreten, vermeidbaren Schaden verursacht. Die Beobachtungsphase ist der günstigste Zeitpunkt im gesamten Rollout, um Fehler folgenlos zu finden.

Schritt 2: pct schrittweise erhöhen, dann quarantine

Zeigen die Berichte aus der Beobachtungsphase keine unerwarteten Absender und keine SPF- oder DKIM-Fails bei legitimer Post, ist der nächste Schritt nicht der Sprung auf reject, sondern ein kontrollierter Übergang zu quarantine mit einem niedrigen pct-Wert, etwa pct=10 oder pct=25. So landet nur ein Bruchteil der ohnehin seltenen, fehlerhaft authentifizierten Mails im Spam-Ordner, während der überwiegende Teil unbeeinflusst bleibt.

Beobachten Sie in dieser Phase weiterhin die Aggregatberichte und erhöhen Sie pct in Schritten von zwei bis vier Wochen, etwa auf 50, dann 75, dann 100 Prozent bei p=quarantine. Ein typischer Fehler ist, den pct-Wert zu schnell hochzufahren, weil die ersten Berichte unauffällig aussehen — gerade bei Kaltakquise-Domains mit unregelmäßigem Versandvolumen können seltene Randfälle erst nach mehreren Wochen sichtbar werden, etwa wenn ein selten genutztes Antwort-Postfach zum ersten Mal eine automatische Bestätigung verschickt.

Halten Sie sich bei jedem Schritt an dieselbe Regel: Erhöhen Sie pct nur, wenn der vorherige Wert über den vollen Beobachtungszeitraum hinweg keine unerwarteten Fails bei bekannten, legitimen Absendern gezeigt hat. Ein einzelner sauberer Bericht reicht nicht — E-Mail-Volumen schwankt über Wochentage und Kampagnenzyklen, und ein Randfall zeigt sich manchmal erst am Monatsende, wenn etwa eine automatisierte Rechnungsmail verschickt wird.

Schritt 3: p=reject — und was bei mehreren Sending-Domains zu beachten ist

p=reject ist die konsequenteste Stufe: Mail-Provider weisen nicht authentifizierte Mails im Namen Ihrer Domain vollständig ab, statt sie nur in Spam zu verschieben. Diesen Schritt sollten Sie erst gehen, wenn die Berichte über mehrere Wochen hinweg sauber sind und alle legitimen Absender — auch selten genutzte, wie ein Rechnungsversand oder ein Support-Postfach — zuverlässig SPF oder DKIM bestehen.

Bei mehreren Sending-Subdomains für Kaltakquise ist eine zusätzliche Überlegung wichtig: Der sp-Tag entscheidet, ob neue oder wenig genutzte Subdomains automatisch dieselbe strenge Policy erben oder eigenständig behandelt werden. Wenn Sie regelmäßig neue Subdomains für den Erstkontakt anlegen, kann eine vorübergehend abweichende sp-Policy sinnvoll sein, bis auch die neue Subdomain ihre eigene Beobachtungsphase durchlaufen hat — sonst landen frisch angelegte, noch nicht vollständig konfigurierte Subdomains sofort im Reject-Modus der Hauptdomain, was den ersten Versand über die neue Subdomain lahmlegen kann, bevor überhaupt eine Mail rausgegangen ist.

Eine sinnvolle Praxis für Teams mit rotierenden Subdomains: Behandeln Sie jede neue Subdomain wie eine eigene kleine Domain mit eigenem, verkürztem Rollout — beginnend bei p=none für wenige Tage, dann zügig zu quarantine, erst danach an die strengere Policy der Hauptdomain angeglichen. Das kostet etwas Mehraufwand pro Subdomain, verhindert aber, dass ein frisch aufgesetzter Sendekanal am ersten Tag ins Leere läuft.

Dokumentieren Sie diesen verkürzten Rollout pro Subdomain an einer zentralen Stelle, etwa in derselben Checkliste, die Sie ohnehin für neue Sending-Domains führen. Ohne Dokumentation verliert ein wachsendes Team schnell den Überblick, welche Subdomain sich noch in der Beobachtungsphase befindet und welche bereits die volle Reject-Policy der Hauptdomain geerbt hat.

Typische Generator-Fehler in der Praxis

Auch mit Generator schleichen sich Fehler ein — meist nicht im generierten String selbst, sondern beim Einfügen ins DNS oder bei der manuellen Nachbearbeitung danach.

• Zwei DMARC-Records auf derselben Domain: Wenn ein alter Test-Eintrag nicht gelöscht wurde, ist der neue, korrekte Eintrag technisch ungültig — DMARC verlangt genau einen Record pro Domain.
• rua-Adresse ohne mailto:-Präfix: Der Generator setzt das Präfix meist automatisch, beim manuellen Nachbearbeiten wird es gelegentlich vergessen.
• Anführungszeichen im DNS-Interface des Hosters falsch gesetzt oder verdoppelt, je nachdem, ob der Hoster den Wert automatisch in Anführungszeichen setzt.
• pct-Wert bei p=none gesetzt, wo er wirkungslos ist — pct greift nur bei quarantine oder reject.
• Reject-Policy ohne vorherige Beobachtungsphase direkt übernommen, häufig aus einer generischen Anleitung, ohne die eigenen Aggregatberichte geprüft zu haben.

Häufige Fragen