Warum die DMARC-Syntax vor der Veröffentlichung prüfen?
Ein fehlerhafter DMARC-Eintrag wird von Gmail, Outlook, Yahoo und allen Empfangsservern stillschweigend ignoriert. Keine Warnung wird ausgegeben. Ihre E-Mails bleiben ungeschützt vor Spoofing und Phishing.
Der Validator liest Ihren Eintrag vor der DNS-Veröffentlichung, prüft jedes Tag und verifiziert die Report-URIs. Sie beheben Fehler sofort, ohne 24 bis 48 Stunden Propagierung abzuwarten, nur um festzustellen, dass ein Detail die Anwendung der Richtlinie verhindert.
DMARC-Tags gemäß RFC 7489
Die RFC 7489 definiert jedes in einem DMARC-Eintrag zulässige Tag. Der Validator prüft Name, Position und Wert jedes Tags.
| Tag | Rolle | Beispiel |
|---|---|---|
| v | Protokollversion, immer an erster Position | v=DMARC1 |
| p | Auf die Hauptdomain angewandte Richtlinie | p=quarantine |
| sp | Auf Subdomains angewandte Richtlinie | sp=reject |
| adkim | DKIM-Ausrichtungsmodus, r (relaxed) oder s (strict) | adkim=s |
| aspf | SPF-Ausrichtungsmodus, r oder s | aspf=r |
| pct | Prozentsatz der der Richtlinie unterliegenden Nachrichten, 1 bis 100 | pct=50 |
| rua | Ziele für aggregierte Berichte (mailto-URI) | rua=mailto:dmarc@captaindns.com |
| ruf | Ziele für forensische Berichte (mailto-URI) | ruf=mailto:forensic@captaindns.com |
| fo | Optionen zur Erstellung forensischer Berichte | fo=1 |
Die Tags v und p sind erforderlich. Die übrigen Tags greifen auf Standardwerte zurück, wenn sie weggelassen werden (adkim=r, aspf=r, pct=100).
Korrekturbeispiele vorher und nachher
Der Validator meldet jeden Syntaxfehler mit seiner Position. Hier drei häufige Fälle, die in veröffentlichten Einträgen auftreten.
Fehlerhafter rua-URI:
- v=DMARC1; p=reject; rua=reports@captaindns.com
+ v=DMARC1; p=reject; rua=mailto:reports@captaindns.com
Das Präfix mailto: ist laut RFC 7489 verpflichtend.
Ungültige p-Richtlinie:
- v=DMARC1; p=monitor; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com
Akzeptiert werden ausschließlich none, quarantine und reject.
pct außerhalb des Bereichs:
- v=DMARC1; p=quarantine; pct=150; rua=mailto:dmarc@captaindns.com
+ v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@captaindns.com
Der pct-Wert muss eine ganze Zahl zwischen 1 und 100 sein.
Häufige Diagnosen des Validators
Der Validator gibt für jede erkannte Anomalie einen kurzen Code zurück. Die folgenden Codes treten am häufigsten auf.
| Code | Ursache | Aktion |
|---|---|---|
| missing_version_tag | Tag v=DMARC1 fehlt | v=DMARC1 als erstes Tag einfügen |
| unsupported_version | Wert von v= abweichend von DMARC1 | Durch v=DMARC1 ersetzen |
| missing_policy | Tag p= fehlt | p=none, p=quarantine oder p=reject ergänzen |
| invalid_policy | Wert von p= außerhalb none/quarantine/reject | Wert korrigieren |
| invalid_subdomain_policy | Wert von sp= ungültig | none, quarantine oder reject verwenden |
| invalid_alignment | Wert von adkim= oder aspf= abweichend von r/s | Auf r oder s setzen |
| invalid_percent | pct= außerhalb von 1-100 | Ganze Zahl zwischen 1 und 100 verwenden |
| invalid_rua_uri | Fehlerhafter rua-URI | mailto:adresse@domain verwenden |
| invalid_ruf_uri | Fehlerhafter ruf-URI | mailto:adresse@domain verwenden |
| invalid_failure_option | Unbekannter fo=-Wert | 0, 1, d oder s verwenden |
| duplicate_tag | Tag doppelt deklariert | Nur eine Vorkommen behalten |
| unknown_tag | Unbekannter Tag-Name | Schreibweise gemäß RFC 7489 prüfen |
| record_trailing_quote | TXT-Zeichenkette endet mit Anführungszeichen | Abschließendes Anführungszeichen entfernen |
Warnungscodes (policy_none, pct_less_than_100, subdomain_policy_none) zeigen eine gültige, aber unvollständige Konfiguration an: Der Schutz bleibt eingeschränkt, solange die Richtlinie auf none steht oder pct unter 100 liegt.
FAQ - Häufig gestellte Fragen
Welche Vorgehensweise empfiehlt sich für die p=-Richtlinie?
Beginnen Sie immer mit p=none, um den Verkehr über aggregierte rua-Berichte zu beobachten. Sobald SPF und DKIM auf allen legitimen Quellen ausgerichtet sind, wechseln Sie zu p=quarantine und dann zu p=reject. Springen Sie nicht direkt zu p=reject: Die rua-Berichte aus der Beobachtungsphase decken fast immer vergessene legitime Streams auf.
Sollte ich ruf zusätzlich zu rua konfigurieren?
Anfangs nicht. Aggregierte rua-Berichte (täglich) sind für die Steuerung Ihrer Einführung unerlässlich. Forensische ruf-Berichte (pro fehlgeschlagener Nachricht) erzeugen erhebliches Volumen und können personenbezogene Daten enthalten. Aktivieren Sie sie nur, wenn Sie eine Analyse-Pipeline und ein juristisches Gutachten zur Erhebung dieser Daten haben.
Sollte ich das sp=-Tag auf Subdomains konfigurieren?
Standardmäßig erben Subdomains die p-Richtlinie. Konfigurieren Sie sp= nur, wenn sich die Subdomain-Richtlinie vom Apex unterscheiden soll. Stellen Sie sicher, dass SPF und DKIM auf jeder versendenden Subdomain ausgerichtet sind, bevor Sie sp= verschärfen.
Wendet der Validator DMARCbis-Regeln an?
Diese Version wendet die RFC 7489-Regeln an. Um den Übergang zu DMARCbis vorzubereiten (Entfernung von pct, ri, rf, Hinzufügung von np, psd, t), verwenden Sie den DMARCbis Checker oder das Tool DMARCbis-Migration.
Ergänzende Tools
| Tool | Zweck |
|---|---|
| DMARC Checker | Veröffentlichung prüfen und DMARC-Eintrag aus dem DNS auflösen |
| DMARC Generator | Spezifikationskonformen DMARC-Eintrag erstellen |
| SPF Validator | SPF-Syntax für Ihre Domain validieren |
| DKIM Validator | Syntax eines DKIM-Schlüssels validieren |
| DMARCbis Migration | DMARC-Eintrag auf den neuen Standard migrieren |
| DMARC-Monitoring | Empfangen und analysieren Sie Ihre aggregierten DMARC-Berichte automatisch |