Der DMARC-Eintragsprüfer analysiert die Struktur und die Parameter eines DMARC-TXT-Eintrags direkt im Browser. Das Werkzeug zerlegt den bereitgestellten Text in seine einzelnen Bestandteile, prüft die Syntax der Tags, bewertet die gewählten Richtlinien und zeigt potenzielle Risiken oder veraltete Konfigurationen auf.
Funktionsweise des DMARC-Eintragsprüfers
Das Werkzeug verarbeitet einen DMARC-TXT-Wert, der als Zeichenkette übergeben wird. Dieser Wert muss mit der Angabe v=DMARC1 beginnen, wobei die Groß- und Kleinschreibung exakt beachtet werden muss. Falls der DNS-Eintrag in Anführungszeichen gesetzte DNS-TXT-Abschnitte enthält, werden diese vom Werkzeug vor der Analyse automatisch zusammengefügt. Die maximale Länge für die Eingabe liegt bei unter 20.000 Zeichen.
Die Verarbeitung der Daten erfolgt lokal. Der eingegebene DMARC-Eintrag verbleibt vollständig im Browser des Nutzers; es findet kein Upload oder eine Speicherung der Daten statt. Das Werkzeug schreibt keine Daten in den Speicher des Browsers und sendet keine ausgehenden Anfragen bezüglich des Eintrags.
Struktur und Komponenten eines DMARC-Eintrags
Ein gültiger DMARC-Eintrag setzt sich aus verschiedenen Schlüssel-Wert-Paaren (Tags) zusammen, die durch Semikolons voneinander getrennt sind. Das wichtigste Element ist das Versions-Tag, das zwingend an erster Stelle stehen muss.
Die Rolle von v=DMARC1
Der Eintrag muss zwingend mit dem exakten, fallsensitiven Wert v=DMARC1 beginnen. Ist dies nicht der erste Begriff im Eintrag, ist die gesamte Konfiguration für empfangende Mailserver ungültig. Der DMARC-Eintragsprüfer validiert diese Positionierung und gibt bei Fehlern entsprechende Warnungen aus.
Richtlinien für Domänen und Subdomänen (p, sp, np)
DMARC-Richtlinien legen fest, wie ein empfangender Mailserver mit E-Mails verfahren soll, die die SPF- und DKIM-Prüfungen bestehen oder nicht bestehen. Hierbei existieren drei spezifische Tags:
- Domain-Richtlinie (
p): Bestimmt das Verhalten für die Hauptdomäne. Wenn keinp-Tag im Eintrag vorhanden ist, fällt die Richtlinie automatisch aufnonezurück. Eine Richtlinie vonp=nonedient ausschließlich der Überwachung von Fehlern und weist Empfänger nicht an, fehlerhafte E-Mails unter Quarantäne zu stellen oder abzuweisen. - Subdomain-Richtlinie (
sp): Definiert die Richtlinie für alle Subdomänen. - Richtlinie für nicht existierende Subdomänen (
np): Regelt das Verhalten für Subdomänen, die im DNS nicht existieren.
Fehlt ein spezifischeres Tag, greift ein automatischer Fallback-Mechanismus: Die Richtlinie für nicht existierende Subdomänen fällt von np auf sp und schließlich auf p zurück.
Der Testmodus mit t=y
Das Tag t=y signalisiert, dass sich die DMARC-Implementierung im Testmodus befindet. Während dieses Tests verringert sich die Auswirkung der Richtlinien bei den Empfängern: Eine quarantine-Richtlinie wird auf none herabgestuft, und eine reject-Richtlinie wird zu quarantine abgemildert.
Konfiguration des Berichtswesens (rua und ruf)
DMARC ermöglicht es Domäneninhabern, Berichte über den E-Mail-Versand und Authentifizierungsfehler zu erhalten.
- Aggregierte Berichte (
rua): Diese Berichte liefern statistische Daten über das E-Mail-Aufkommen. Ist keine gültigerua-Adresse im Eintrag konfiguriert, werden keine aggregierten Berichte angefordert. - Fehlerberichte (
ruf): Diese detaillierten Berichte informieren über spezifische Zustellungsfehler. Das Tagfo(Optionen für die Fehlerberichterstattung) wird von Empfängern ignoriert, wenn keine gültigeruf-Adresse für Fehlerberichte hinterlegt ist.
Historische Spezifikationen erlaubten den Suffix !size an einer Berichts-URI, um die maximale Berichtsgröße zu limitieren. Nach aktuellen Standards ist dieser Suffix veraltet und sollte von modernen Empfangssystemen ignoriert werden.
Historische Tags und Ausrichtung
Einige Tags und Werte in älteren DMARC-Einträgen entsprechen nicht mehr dem aktuellen Standard:
- Prozentwert (
pct): Derpct-Wert diente in älteren Implementierungen dazu, die Richtlinie nur auf einen bestimmten Prozentsatz der E-Mails anzuwenden. Diese Werte sind historisch und beschränken die Richtlinienabdeckung nur noch bei Empfängern, die veralteten DMARC-Spezifikationen folgen. - Ausrichtung (Identifier Alignment): Die Tags
aspfundadkimsteuern die Striktheit der Ausrichtung für SPF und DKIM. Der Prüfer analysiert diese Einstellungen, um die Konsistenz der Identitäten sicherzustellen.
Analyseergebnisse und Fehlermeldungen
Der DMARC-Eintragsprüfer gibt nach der Analyse eine detaillierte Auswertung aus. Diese unterteilt sich in die DMARC-Zusammenfassung, die Berichtsempfänger, eine Tabelle der analysierten Begriffe sowie spezifische Hinweise zu Syntax und Richtlinien.
Folgende Fehlermeldungen und Warnungen können bei der Überprüfung auftreten:
| Ursache | Fehlermeldung / Warnung im Werkzeug |
|---|---|
| Leere Eingabe | Fügen Sie zuerst einen DMARC-Eintrag ein. |
| Zeichenlimit überschritten | Dieser Eintrag ist ungewöhnlich groß. Halten Sie ihn unter 20.000 Zeichen. |
| Fehlende Version am Anfang | Der Eintrag muss mit v=DMARC1 beginnen. |
| Falsche Position des Versions-Tags | Begriff ‹position›: v=DMARC1 muss der erste Begriff sein. |
| Mehrfach vorhandenes Tag | ×2: ‹tag› (‹position›) |
| Fehlerhafte Syntax | name=value ✕ (‹position›) |
| Fehlender Wert bei einem Tag | ‹tag›=∅ (‹position›) |
| Ungültiger Wert | ‹tag›=‹detail› ✕ (‹position›) |
| Ungültige Berichts-Adresse | URI ✕: ‹tag› (‹position›) |
| Unbekanntes Tag | Unbekannt: ‹tag› (‹position›) |
| Veraltetes Tag nach aktuellem Standard | RFC 7489 → RFC 9989: ‹tag› (‹position›) |
| Fehlendes Richtlinien-Tag | p → none |
| Reine Überwachungsrichtlinie | p=none |
| Aktiver Testmodus | t=y: reject → quarantine; quarantine → none |
| Keine Empfänger für aggregierte Berichte | rua=∅ |
| Fehleroptionen ohne Empfängeradresse | fo → ∅ (ruf=∅) |
| Verwendung des historischen Prozent-Tags | pct=‹detail›% (RFC 7489) |
| Zusammenfügung von Anführungszeichen | In Anführungszeichen gesetzte DNS-TXT-Abschnitte wurden vor der Analyse zusammengefügt. |
| Veralteter Größen-Suffix bei Berichten | !size → ∅ (RFC 9989) |
FAQ
Hinweise zu Syntax und Richtlinie: p / sp / np?
Eine Richtlinie von p=none dient nur der Überwachung und weist Empfänger nicht an, fehlerhafte E-Mails abzuweisen. Mit t=y wird ein Testmodus aktiviert, der die Richtlinien quarantine zu none und reject zu quarantine herabstuft. Bei der Auswertung der Subdomänen-Richtlinien gilt die Vererbungskette np → sp → p, falls spezifischere Tags im Eintrag fehlen.
RFC 9989: pct / rf / ri?
Nein. Diese Seite prüft nur den eingefügten Text. Sie fragt DNS nicht ab, erweitert keine Anbietereinträge, testet keine Absender-IP und bestätigt nicht, was ein empfangender Mailserver zurückgibt. Nach RFC 9989 gelten die Tags pct, rf und ri als historisch (RFC 7489), während np, psd und t als aktiv (RFC 9989) eingestuft werden.
Beweist ein fehlerfreies Ergebnis, dass meine DMARC-Konfiguration funktioniert?
Nein. Diese Seite prüft nur den eingefügten Text. Sie fragt DNS nicht ab, erweitert keine Anbietereinträge, testet keine Absender-IP und bestätigt nicht, was ein empfangender Mailserver zurückgibt. Ein fehlerfreies Ergebnis im Prüfer bedeutet lediglich, dass die Syntax und die Struktur des bereitgestellten Textes formal korrekt sind.