DMARC Validator

Warum die DMARC-Syntax vor der Veröffentlichung validieren?

Ein fehlerhafter DMARC-Eintrag wird von allen Empfangsservern stillschweigend ignoriert. Gmail, Outlook, Yahoo: Keiner wird Sie warnen. Ihre E-Mails bleiben ungeschützt vor Spoofing und Phishing.

Der DMARC-Syntax-Validator analysiert Ihren Eintrag vor der DNS-Veröffentlichung. Sie erkennen Fehler sofort, ohne 24-48 Stunden auf Propagierung zu warten, um ein Problem zu entdecken.

Häufig erkannte Fehler:

• Fehlendes v=-Tag → Eintrag wird nicht als DMARC erkannt
• Fehlende p=-Richtlinie → Keine Verarbeitungsanweisungen für Server
• Ungültiger rua/ruf-URI → Berichte werden nie empfangen
• Doppelte Tags → Unvorhersehbares Verhalten, oft ignoriert

So validieren Sie Ihren DMARC-Eintrag in 3 Schritten

Schritt 1: DMARC-Eintrag kopieren

Bereiten Sie Ihren vollständigen DMARC-Eintrag vor. Typisches Beispiel:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@captaindns.com; adkim=r; aspf=r; pct=100

Wenn Sie einen bestehenden Eintrag ändern, rufen Sie den aktuellen Wert aus Ihrem DNS ab:

dig TXT _dmarc.captaindns.com +short

Schritt 2: Einfügen und validieren

Fügen Sie den Eintrag in das obige Feld ein. Das Tool analysiert:

• Vorhandensein der obligatorischen Tags (v, p)
• Gültigkeit jedes Tags und Wertes
• Format der Report-URIs (rua, ruf)
• Konformität mit RFC 7489-Spezifikationen

Schritt 3: Korrigieren und veröffentlichen

Die Diagnose listet jedes Tag mit seinem Status auf:

• ✅ Gültig → Tag korrekt, bereit zur Veröffentlichung
• ❌ Fehler → Korrektur vor Veröffentlichung erforderlich
• ⚠️ Warnung → Funktionsfähig, aber Verbesserung empfohlen

Beheben Sie Fehler, validieren Sie erneut und veröffentlichen Sie dann in Ihrem DNS.

Was ist ein DMARC-Eintrag?

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist ein DNS-TXT-Eintrag, der unter _dmarc.ihredomain.com veröffentlicht wird. Er teilt Empfangsservern mit:

1. Welche Richtlinie angewendet werden soll bei E-Mails, die SPF und DKIM nicht bestehen
2. Wohin Berichte gesendet werden sollen über Authentifizierungsergebnisse
3. Wie SPF/DKIM-Domains mit der From-Adresse abgeglichen werden sollen

Struktur eines DMARC-Eintrags:

v=DMARC1; p=reject; rua=mailto:reports@captaindns.com; ruf=mailto:forensics@captaindns.com; adkim=s; aspf=s; pct=100

Validierte DMARC-Tags im Detail

Obligatorische Tags

Optionale Tags

Häufige Syntaxfehler

Fehler 1: Eintrag ohne v=DMARC1

Symptom: Validator zeigt "not_dmarc_record"

Ursache: Eintrag beginnt nicht mit v=DMARC1

Korrektur:

- p=reject; rua=mailto:reports@captaindns.com
+ v=DMARC1; p=reject; rua=mailto:reports@captaindns.com

Fehler 2: Fehlende p=-Richtlinie

Symptom: "missing_policy" oder "empty_policy"

Ursache: Das p=-Tag fehlt oder ist leer

Korrektur:

- v=DMARC1; rua=mailto:reports@captaindns.com
+ v=DMARC1; p=none; rua=mailto:reports@captaindns.com

Fehler 3: Ungültiger rua/ruf-URI

Symptom: "invalid_rua_uri" oder "invalid_ruf_uri"

Ursache: URI entspricht nicht dem mailto:- oder https:-Format

Korrekturbeispiele:

- rua=reports@captaindns.com          # Fehlt mailto:
+ rua=mailto:reports@captaindns.com

- ruf="mailto:forensics@captaindns.com"  # Anführungszeichen nicht erlaubt
+ ruf=mailto:forensics@captaindns.com

- rua=mailto: reports@captaindns.com  # Leerzeichen nicht erlaubt
+ rua=mailto:reports@captaindns.com

Fehler 4: Doppeltes Tag

Symptom: "duplicate_tag"

Ursache: Ein Tag erscheint mehrfach

Korrektur:

- v=DMARC1; p=none; p=reject; rua=mailto:reports@captaindns.com
+ v=DMARC1; p=reject; rua=mailto:reports@captaindns.com

Fehler 5: pct außerhalb des Bereichs

Symptom: "invalid_pct_value"

Ursache: pct-Wert liegt nicht zwischen 1 und 100

Korrektur:

- v=DMARC1; p=reject; pct=0      # 0 ist ungültig
+ v=DMARC1; p=reject; pct=10     # Minimum ist 1

- v=DMARC1; p=reject; pct=150    # >100 ist ungültig
+ v=DMARC1; p=reject; pct=100

Best Practices für die DMARC-Bereitstellung

1. Mit p=none beginnen

Springen Sie nicht direkt zu p=reject. Beginnen Sie mit Beobachtung:

v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com

Diese Richtlinie blockiert nichts, generiert aber Berichte. Analysieren Sie diese 2-4 Wochen lang.

2. rua von Anfang an konfigurieren

Aggregierte Berichte sind unerlässlich für:

• Identifizierung legitimer Quellen, die die Authentifizierung nicht bestehen
• Erkennung von Spoofing-Versuchen
• Validierung des Fortschritts zu p=quarantine und dann p=reject

3. Fortschritt zu p=reject

Sobald SPF und DKIM auf allen legitimen Quellen abgeglichen sind:

1. p=none → Beobachten (2-4 Wochen)
2. p=quarantine; pct=10 → Test mit 10% des Datenverkehrs
3. p=quarantine; pct=50 → Schrittweise erhöhen
4. p=quarantine; pct=100 → Vollständige Quarantäne
5. p=reject → Maximaler Schutz

4. Subdomains mit sp= verwalten

Standardmäßig erben Subdomains die p-Richtlinie. Wenn Sie E-Mails von Subdomains senden (marketing.captaindns.com), denken Sie daran:

• SPF/DKIM auf jeder Subdomain zu konfigurieren
• sp= zu verwenden, wenn die Richtlinie abweichen soll

FAQ - Häufig gestellte Fragen

F: Welche DMARC-Tags sind obligatorisch?

A: Zwei Tags sind erforderlich: v=DMARC1 (Version) und p= (Richtlinie). Ohne diese Tags ist der Eintrag ungültig und wird von Empfangsservern ignoriert. Alle anderen Tags sind optional.

F: Was bedeutet der Fehler "fehlende Richtlinie"?

A: Der Eintrag enthält kein p=-Tag, das die Richtlinie definiert. Fügen Sie einen der drei möglichen Werte hinzu:

• p=none → Keine Aktion, nur Berichte
• p=quarantine → Als Spam markieren
• p=reject → Nachricht ablehnen

F: Wie behebe ich einen rua/ruf-URI-Fehler?

A: URIs müssen dem exakten Format mailto:adresse@domain.com oder https://endpoint entsprechen. Häufige Fehler:

• Vergessen von mailto: vor der Adresse
• Anführungszeichen um den URI
• Leerzeichen in der Adresse
• Ungültige E-Mail-Adresse

F: Was ist der Unterschied zwischen rua und ruf?

A:

• rua (aggregierte Berichte): tägliche Berichte im XML-Format, statistische Zusammenfassung
• ruf (forensische Berichte): Bericht pro fehlgeschlagener Nachricht

Beginnen Sie nur mit rua. ruf-Berichte erzeugen erheblichen Datenverkehr und können sensible Daten enthalten.

F: Was bedeutet "pct außerhalb des Bereichs"?

A: Das pct-Tag definiert den Prozentsatz der Nachrichten, die der p-Richtlinie unterliegen. Akzeptierte Werte: 1 bis 100. Wenn Sie pct weglassen, gilt die Richtlinie für 100% der Nachrichten (Standardverhalten).

F: Warum vor der DNS-Veröffentlichung validieren?

A: Ein Syntaxfehler macht den Eintrag ungültig. Empfangsserver ignorieren ihn stillschweigend: Sie erhalten keine Warnung, aber Ihre E-Mails haben keinen DMARC-Schutz. Validieren Sie systematisch vor jeder DNS-Änderung.

F: Überprüft der Validator die DNS-Veröffentlichung?

A: Nein, dieses Tool validiert nur die Syntax des Eintrags. Um zu überprüfen, ob der Eintrag korrekt im DNS veröffentlicht und propagiert wurde, verwenden Sie den DMARC-Inspektor nach der Veröffentlichung.

Bereiten Sie sich auf DMARCbis vor

DMARCbis ist der kommende IETF Proposed Standard, der RFC 7489 ersetzt. Er führt neue Tags ein (np, t, psd), entfernt veraltete Tags (pct, rf, ri) und ersetzt die Public Suffix List durch einen DNS tree walk-Algorithmus. Prüfen Sie die Kompatibilität Ihrer Domain mit dem DMARCbis Checker oder erstellen Sie einen konformen Eintrag mit dem DMARCbis-Migrationstool.

Ergänzende Tools

Nützliche Ressourcen

• RFC 7489 - Domain-based Message Authentication, Reporting and Conformance (DMARC) (offizielle Spezifikation)
• Google - DMARC einrichten (Gmail/Workspace-Anleitung)
• Microsoft - DMARC in Microsoft 365 (Outlook/M365-Anleitung)
• dmarc.org - Übersicht (DMARC-Konsortium-Dokumentation)