DMARC-Check: So prüfen Sie, ob Ihr Eintrag wirklich aktiv ist

DNS-Einträge, denen Sie einen falschen Wert, einen zweiten Record oder ein Anführungszeichen zu viel mitgeben, werden meist kommentarlos ignoriert — es gibt keine automatische Fehlermeldung, die Sie warnt. Dieser Artikel zeigt, wie Sie mit kostenlosen Checker-Tools und ein paar Kommandozeilenbefehlen zuverlässig feststellen, ob Ihr DMARC-Eintrag aktiv ist, inklusive der Eigenheiten von Hostern wie Strato oder IONOS, bei denen das DNS-Interface gerne eigene Überraschungen bereithält.

Warum eingetragen nicht gleich aktiv bedeutet

Ein DMARC-Record im Kundenportal Ihres Hosters zu speichern und einen tatsächlich wirksamen DMARC-Record im öffentlichen DNS zu haben, sind zwei verschiedene Dinge. Dazwischen liegen mehrere Fehlerquellen: eine falsche Eingabe im Hostname-Feld, automatisch hinzugefügte Anführungszeichen, ein noch nicht abgelaufenes TTL vom vorherigen Eintrag, oder schlicht ein Interface, das den Eintrag zwar anzeigt, aber nie korrekt an die autoritativen Nameserver weitergereicht hat.

Gerade bei Hostern mit einfachen Consumer-Oberflächen wie Strato oder IONOS ist das DNS-Interface oft nicht für TXT-Records mit Semikolon-getrennten Werten optimiert — hier lohnt sich der externe Check besonders, weil das Interface selbst Ihnen ein trügerisches gespeichert anzeigt, ohne die tatsächliche Wirksamkeit zu prüfen. Ein Interface kann eine Eingabe technisch korrekt annehmen und trotzdem beim Übertragen an die Zone einen Zeichensatz oder eine Zeilenlänge falsch behandeln, ohne dass Sie davon etwas merken.

Der Unterschied wird besonders dann teuer, wenn Sie sich auf den vermeintlich aktiven Eintrag verlassen und im nächsten Schritt bereits die Policy von none auf quarantine hochstufen — während in Wahrheit noch gar kein Record im öffentlichen DNS liegt und Sie schlicht keine Reports erhalten, ohne dass klar wird, woran es liegt.

Für Kaltakquise-Domains kommt eine weitere Komplikation hinzu: Häufig verwalten Sie mehrere Subdomains bei demselben Hoster, jede mit eigenem DMARC-Eintrag. Ein Copy-Paste-Fehler beim Anlegen der zweiten oder dritten Subdomain — falscher Hostname, vergessenes Löschen des Platzhalter-Werts, den das Interface beim Anlegen eines neuen Eintrags vorschlägt — fällt oft erst auf, wenn Sie jede Subdomain einzeln und bewusst nachprüfen, statt sich auf den ersten erfolgreichen Check zu verlassen.

Der schnelle Kommandozeilen-Check

Der zuverlässigste erste Schritt braucht kein externes Tool: dig oder nslookup fragen direkt die öffentlichen Nameserver ab, unabhängig davon, was das Hoster-Interface anzeigt. Beide Befehle sind auf so gut wie jedem System vorhanden oder mit wenig Aufwand nachinstallierbar, und beide liefern innerhalb von Sekunden eine Antwort, die nichts mit dem Cache Ihres Hoster-Portals zu tun hat.

Dieser Check zeigt Ihnen die Rohwahrheit — das, was ein Mail-Provider tatsächlich sieht, wenn er eine eingehende Mail Ihrer Domain prüft. Alles Weitere sind Komfort-Tools, die dieselbe Information verständlicher aufbereiten, aber im Kern nichts anderes tun als denselben DNS-Lookup.

• dig TXT _dmarc.ihredomain.de +short — zeigt den öffentlich sichtbaren DMARC-Record, sofern vorhanden.
• nslookup -type=TXT _dmarc.ihredomain.de — dieselbe Abfrage für Windows-Systeme ohne dig.
• Kommt keine Antwort oder eine leere Zeile zurück, ist entweder kein Record vorhanden oder er ist noch nicht propagiert — Letzteres meist eine Frage von Minuten bis wenigen Stunden, je nach TTL des vorherigen Eintrags.
• Kommen mehrere TXT-Zeilen mit v=DMARC1 zurück, liegt ein doppelter Record vor, der den gesamten Eintrag ungültig macht.

Online-Checker: mehr als nur ja oder nein

Kostenlose Online-Checker gehen über die reine dig-Abfrage hinaus: Sie prüfen zusätzlich die Syntax der einzelnen Tags, weisen auf ein überschrittenes SPF-Lookup-Limit hin, erkennen doppelte Records und zeigen oft direkt an, welche Policy-Stufe aktuell gesetzt ist. Für eine erste vollständige Bestandsaufnahme sind solche Tools praktischer als eine reine dig-Abfrage, weil sie Fehler auch benennen, statt nur eine leere oder unerwartete Antwort zu liefern, mit der Sie als Laie wenig anfangen können.

Ein wichtiger Punkt bei allen Online-Checkern: Sie fragen ebenfalls öffentliche DNS-Resolver ab und unterliegen damit denselben Propagationsverzögerungen wie Ihre eigene dig-Abfrage. Ein negatives Ergebnis kurz nach dem Speichern im Hoster-Interface ist deshalb nicht zwingend ein Konfigurationsfehler — prüfen Sie in diesem Fall erneut nach einigen Stunden, bevor Sie den Eintrag anfassen und womöglich einen zweiten, konkurrierenden Record anlegen, weil Sie den ersten für gescheitert halten.

Nutzen Sie einen Online-Checker deshalb am besten zweistufig: einmal direkt nach dem Anlegen, um grobe Syntaxfehler sofort zu erkennen, und ein zweites Mal nach einigen Stunden Wartezeit, um sicherzustellen, dass es sich bei einem anfänglich negativen Ergebnis wirklich nur um Propagation und nicht um einen tatsächlichen Fehler handelte. Notieren Sie sich bei jedem Check kurz Datum und Ergebnis — bei mehreren Domains verlieren Sie sonst schnell den Überblick, welcher Eintrag zuletzt wann und mit welchem Ergebnis geprüft wurde, gerade wenn Prüfungen über mehrere Wochen verteilt stattfinden, weil eine erste Propagation noch abgewartet werden musste.

Die typischen Strato- und Hoster-Stolperfallen

Bei Consumer-orientierten Hostern wiederholen sich dieselben Fehler auffällig oft, weil die Oberflächen für einfache A- und CNAME-Records gebaut sind und TXT-Records mit komplexer Syntax nur notdürftig unterstützen. Wer aus einer technischeren DNS-Verwaltung kommt, unterschätzt gerne, wie viele dieser Interfaces stillschweigend Eingaben verändern, statt sie unverändert zu übernehmen.

• Automatisch hinzugefügte Anführungszeichen: Manche Interfaces setzen um den eingegebenen Wert selbst Anführungszeichen, sodass im DNS am Ende doppelte Anführungszeichen landen, wenn Sie den Wert bereits mit welchen eingegeben haben.
• Hostname mit oder ohne abschließenden Punkt: Je nach Interface muss _dmarc oder _dmarc.ihredomain.de eingetragen werden — die falsche Variante erzeugt einen Record unter der falschen Subdomain, etwa _dmarc.ihredomain.de.ihredomain.de.
• Zeilenumbruch oder Leerzeichen am Ende des eingefügten Werts, häufig beim Kopieren aus einem Generator-Tool, das für die Zwischenablage unsichtbare Zeichen mitliefert.
• Alter, konkurrierender Eintrag aus einem früheren Test, der nie gelöscht wurde und jetzt zusammen mit dem neuen Record für einen doppelten TXT-Eintrag sorgt.

Die Meldung dmarc policy not enabled richtig einordnen

Viele Checker-Tools geben bei fehlendem oder fehlerhaftem Record die Meldung dmarc policy not enabled aus. Das ist keine Bewertung Ihrer bestehenden Mail-Sicherheit, sondern schlicht die Feststellung, dass an der erwarteten DNS-Stelle kein gültiger DMARC-Record gefunden wurde. Häufigste Ursache ist ein fehlender Eintrag, gefolgt von einem Syntaxfehler, der den Record für den Parser des Checkers unlesbar macht, obwohl im DNS technisch eine Zeile steht.

Bevor Sie hier in Panik den Eintrag neu anlegen, lohnt sich zuerst die eigene dig-Abfrage aus dem vorherigen Schritt: Zeigt sie überhaupt eine Zeile mit v=DMARC1, liegt das Problem eher in der Syntax als im kompletten Fehlen des Records. Zeigt sie nichts, war der Eintrag entweder nie gespeichert oder noch nicht propagiert. In beiden Fällen ist der nächste Schritt unterschiedlich: bei sichtbarer, aber fehlerhafter Zeile korrigieren Sie die Syntax, bei komplett fehlender Antwort prüfen Sie zuerst im Hoster-Portal, ob die Änderung überhaupt gespeichert wurde.

Ein zweiter, oft übersehener Grund für dieselbe Meldung: Der Checker fragt einen anderen DNS-Resolver ab als der, den Sie zufällig gerade in Ihrem eigenen Terminal nutzen, und dieser Resolver hat den vorherigen, leeren Zustand noch im Cache. Warten Sie in diesem Fall die TTL des vorherigen Eintrags ab, bevor Sie von einem echten Fehler ausgehen — ungeduldiges mehrfaches Neuanlegen verschlimmert die Verwirrung häufig eher, weil dann am Ende mehrere Records um denselben Hostnamen konkurrieren.

Halten Sie sich bei jeder neuen Domain an dieselbe Reihenfolge: erst die eigene dig-Abfrage, dann ein Online-Checker, erst danach — falls beide auf einen Fehler hindeuten — eine Änderung im Hoster-Interface. Diese Reihenfolge verhindert, dass Sie an einem eigentlich korrekten Eintrag herumkorrigieren, nur weil ein einzelnes Tool durch Propagations-Timing kurzzeitig ein falsches Bild liefert.

Checkliste: Woran Sie einen korrekten, aktiven Eintrag erkennen

Ein wirklich aktiver DMARC-Eintrag erfüllt alle folgenden Punkte gleichzeitig — fehlt einer, ist der Record entweder unwirksam oder liefert nicht die erwartete Absicherung. Gehen Sie die Liste nach jeder Änderung an Ihrer DNS-Konfiguration erneut durch, nicht nur bei der Ersteinrichtung.

Für Teams, die mehrere Sending-Domains parallel betreiben, lohnt sich diese Checkliste zusätzlich als feste Vorlage: Kopieren Sie sie für jede neue Domain und haken Sie jeden Punkt einzeln ab, statt sich auf einen einmaligen Gesamteindruck zu verlassen. Gerade der letzte Punkt — die tatsächlich eintreffenden Aggregatberichte — ist die einzige Bestätigung, die nicht nur die Syntax, sondern auch die reale Zustellung an den Berichtsempfänger verifiziert.

• Genau ein TXT-Record unter _dmarc.ihredomain.de, nicht null und nicht zwei.
• Der Record beginnt mit v=DMARC1 und enthält mindestens ein gültiges p-Tag.
• Eine dig- oder nslookup-Abfrage von einem beliebigen externen Netz aus liefert denselben Wert wie das Hoster-Interface anzeigt.
• Ein Online-Checker meldet keine Syntaxfehler und keine doppelten Records.
• Die rua-Adresse ist erreichbar und empfängt innerhalb von ein bis zwei Tagen die ersten Aggregatberichte.

Häufige Fragen