DMARC-Analyzer

Sie bereiten den Übergang von Monitoring zu Enforcement vor und müssen wissen, ob der veröffentlichte Record Receiver-Prüfung standhält. Marketing sendet über CRM, Produkt über Transactional-Provider, Finanzen über lokalen Relay. Bevor Sie `p` von `none` auf `quarantine` erhöhen, zeigt DN01, ob der TXT unter `_dmarc.example.com` syntaktisch gültig ist, ob doppelte Tags den Record invalidieren und ob `pct` Enforcement bereits begrenzt. Diese eine DNS-Veröffentlichung bewerten Milliarden Postfächer; ein Tippfehler in `p=` oder ein zweiter DMARC-TXT kann den Schutz aller Kanäle schwächen. Halten Sie den DN01-Bericht als Vorher-Nachher-Snapshot für Change Requests bereit.

Deliverability-Tickets geben DMARC die Schuld, obwohl SPF allein besteht. Eine Nachricht kann gültiges SPF haben und DMARC trotzdem scheitern, wenn Envelope From, Header From und DKIM-Signaturdomain nicht gemäß `aspf` und `adkim` alignen. DN01 zeigt Alignment-Defaults: fehlen Tags, gilt relaxed (`r`), mit Warnung, dass Receiver breitere Domain-Matches akzeptieren können. Kombinieren Sie das Ergebnis mit DKIM Validator und DNS Checker.

Security-Teams nutzen DMARC als Anti-Spoofing für Führungskräfte-Domains, Partnerportale und Look-alike-Marken. Fehlt `_dmarc`, liefert DN01 die klare Diagnose — `no DMARC record found at _dmarc.<domain>` — und empfiehlt `v=DMARC1` mit Start-Policy. Das ist kein Tool-Fehler, sondern der Zustand, den Receiver bei Phishing ohne veröffentlichte Reject-Policy sehen.

MSPs prüfen DMARC über Dutzende Kundenzonen beim Onboarding oder Renewal. Manuelle `dig`-Lookups skalieren nicht, wenn `sp` mit `p` verglichen, Report-Mailboxen geprüft und ungültiges `pct` im Portfolio gefunden werden muss. DN01 liefert konsistente Berichte mit Dauer, Tag-Inventar und Empfehlungen für Tickets.

Subdomain-lastige Architekturen — `news.example.com`, `billing.example.com`, `eu.example.com` — hängen von `sp=` ab, wenn Kindzonen mit eigenem SPF und DKIM senden. Ohne `sp` fallen Receiver auf `p` zurück, was Teams überrascht, die die Zone isoliert glaubten. DN01 zeigt beide Werte und markiert ungültige Subdomain-Policies.

Compliance-Fragebögen verlangen Nachweise für E-Mail-Authentifizierungsreife. Auditoren fragen nach Aggregate Reporting (`rua`), partiellem Enforcement (`pct` unter 100) und heutiger Gültigkeit. DN01 antwortet aus Live-DNS, speichert rohen TXT und trennt harte Fehler von Warnungen. Für ISO- oder SOC-Audits reicht oft ein Link zur Ergebnisseite plus Screenshot der Tag-Tabelle, weil Query-Name und `durationMs` den Prüfzeitpunkt dokumentieren.

Nach Spoofing-Wellen beginnt Incident Response oft mit «DMARC fehlt oder kaputt?». Mehrere TXT unter `_dmarc` mit mehr als einem `v=DMARC1`-Fragment können Receiver zur Invalidierung bringen. DN01 wählt den ersten passenden Record, meldet aber Duplicate-Tag-Fehler innerhalb einer Zeichenkette. Marketing- und Newsletter-Teams wechseln zudem häufig ESPs und vergessen, `rua` umzustellen oder `pct` nach Tests wieder auf 100 zu setzen — DN01 macht solche Zwischenzustände sichtbar. Nach TTL erneut prüfen, Signaturen via DKIM Validator validieren und die Rohzeile mit dem Kunden-DNS-Panel vergleichen.

Meldet DN01 keinen DMARC-Record, fragen Sie gezielt `_dmarc.ihredomain.tld` ab, nicht den Apex-TXT mit SPF. Viele Teams veröffentlichen SPF an der Wurzel und erwarten vererbtes DMARC. Prüfen Sie alle autoritativen NS nach DNS-Migration. Die Empfehlung «publish a TXT record at _dmarc… starting with v=DMARC1» im Ergebnis ist die gleiche Handlungsanweisung, die das Backend bei NXDOMAIN zurückgibt.

Ist `valid` false bei `found` true, lesen Sie zuerst das errors-Array. Doppelte `p=`-Tags, unbekannte Policies, nicht-ganzzahliges `pct` oder Werte außerhalb 0–100 invalidieren den Record. Entfernen Sie Duplikate, behalten Sie einen semikolongetrennten TXT und warten Sie TTL ab. Der Parser markiert auch doppelte Tag-Namen innerhalb einer Zeile — ein häufiger Copy-Paste-Fehler in Hosting-Panels.

Warnungen zu `p=none`, fehlendem `rua` oder relaxed Alignment beschreiben Exposure. `p=none` überwacht ohne Quarantäne oder Reject. Ohne `rua` fehlen Aggregate-XML-Reports. Entscheiden Sie vor `reject`, ob `adkim=s` oder `aspf=s` nötig ist.

Weicht Live-DNS vom Registrar-Dashboard ab, vergleichen Sie das Roh-Record-Feld mit `dig +short TXT _dmarc.domain`. Caches und partielle Zonenimporte täuschen Dashboards. DN01 fragt zum Request-Zeitpunkt ab.

Wenn legitime Mail nach Policy-Verschärfung scheitert, kann DMARC korrekt sein, SPF oder DKIM nicht. DNS Checker für Includes, DKIM Validator für Selektoren und Schlüsselablauf. `pct` unter 100 erzeugt scheinbar zufällige Fehler. Dokumentieren Sie den DN01-Bericht vor und nach der Änderung, damit Rollback-Entscheidungen auf dem gleichen Parser basieren wie die Produktions-API.

DMARC baut auf SPF und DKIM. SPF prüft den Envelope-Pfad, DKIM die Signatur, DMARC fragt, ob eines mit der sichtbaren From-Domain aligniert und was bei beidem Scheitern gilt. DN01 sendet keine Mail und bewertet keine Einzelnachrichten — nur die DNS-Policy für Receiver. Kombinieren Sie mit DKIM Validator und DNS Checker, besonders wenn `adkim` oder `aspf` auf strict (`s`) stehen sollen.

Das Tag `p=` ist Pflicht. Policies müssen `none`, `quarantine` oder `reject` sein; alles andere ist ungültig. `none` eignet sich für Monitoring, warnt DN01 aber, dass es keine Blockade anweist. `quarantine` landet meist in Spam, `reject` verwirft Nachrichten. Eskalation sollte auf `rua`-Reports basieren. Viele deutsche Unternehmen bleiben zu lange bei `p=none`, weil interne Freigaben fehlen — der Analyzer macht diesen Stillstand als Warnung sichtbar statt als versteckten Erfolg.

`pct` begrenzt den Anteil fehlgeschlagener Nachrichten unter Policy. Werte unter 100 bedeuten partielles Enforcement — nützlich für Rollouts, verwirrend beim Debug. DN01 parst `pct` als Integer und fehler bei Nicht-Zahl oder außerhalb 0–100.

Aggregate Reports gehen an `rua`, meist registrierte `mailto:`-Adressen. DN01 listet Komma-Ziele und warnt bei fehlendem `rua`. Forensik `ruf` ist optional und datenschutzsensibel.

`adkim` und `aspf` steuern strict (`s`) oder relaxed (`r`). Fehlen sie, setzt DN01 relaxed an und warnt vor ungewollten Apex/Subdomain-Kombinationen. Strict-Modi sind vor `reject` üblich.

Gültig in DN01 heißt: keine blockierenden Parse-Fehler zum Prüfzeitpunkt. `valid=false` ist ein DNS-Stop-Ship bis zur Korrektur. Ein gefundener Record mit `p=none` und fehlendem `rua` kann trotzdem wertvolle Warnungen liefern, weil er zeigt, dass Monitoring ohne Reporting und ohne Enforcement läuft — ein häufiger Ausgangszustand vor dem ersten ESP-Onboarding.

`dig TXT _dmarc.example.com` zeigt rohe Strings schnell, Interpretation bleibt beim Operator. DN01 kodifiziert Duplikat-, `sp`- und `rua`-Regeln und liefert Empfehlungen in einem Durchlauf.

DNS Checker zeigt alle TXT der Zone; DMARC Analyzer fokussiert Policy-Risiko unter `_dmarc` und partielles `pct`.

Mailbox-Aggregate zeigen Verlauf, beweisen aber nicht die aktuelle DNS-Veröffentlichung nach Notfalländerung. DN01 antwortet in Sekunden.

Vendor-DMARC-Konsolen bieten Dashboards; externe Auditoren brauchen neutralen Lookup des öffentlich sichtbaren TXT.

Generische TXT-Validatoren prüfen nicht immer DMARC-Tags. DN01 nutzt denselben Go-Parser wie die Produktions-API.

Tabellen-Inventare veralten nach DNS-Edits. Eine DN01-Ergebnis-URL liefert aktuellen Snapshot mit Abfragename, Roh-Record und Timing. Für Kunden mit mehreren Marken-Domains lässt sich so schnell zeigen, welche Zone noch `p=none` ohne `rua` betreibt und welche bereits `reject` mit strict Alignment erzwingt.

MXToolbox und ähnliche Dienste liefern schnelle DMARC-Zeilen, verlangen aber oft Registrierung und mischen Werbung mit Ergebnissen. DN01 bleibt auf die `_dmarc`-TXT-Analyse fokussiert, ohne Mail zu senden, und integriert sich in die DKIM- und DNS-Tool-Kette der Plattform — praktisch, wenn Sie ohnehin WHOIS, SPF und Zertifikate im selben Audit prüfen.