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.

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)