DNS-DMARC-Policy-Record-Builder & Syntax-Validator

DNS-DMARC-Policy-Record-Builder & Syntax-Validator

Erstellen und validieren Sie RFC 7489-konforme DMARC DNS TXT-Einträge mit Richtliniendurchsetzung (none/quarantine/reject), rua/ruf-Berichten und Alignment-Tags.

Voreinstellungen:
Enforcement Percentage (pct=)100%
Domain: example.comPolicy: rejectPct: 100%
Security Health ScoreSicherheitsstufe A+ (100/100)

Maximum defense against spoofing, BEC attacks, and phishing impersonation.

100/100
DMARC DNS TXT Value
v=DMARC1; p=reject; rua=mailto:[email protected]!10m
BIND 9 / RFC 1035 Master Zone Syntax
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]!10m"
DNS Management Table
Host / Name_dmarc(or _dmarc.example.com)
Record TypeTXT
TTL3600 (or Auto)
Length: 60 charsUDP DNS: < 255 B (Single String)
RFC 7489 Valid
Richtlinienstatusp=reject (100%)
Berichts-Feeds1 RUA / 0 RUF
AbgleichmodiDKIM: Relaxed | SPF: Relaxed

RFC 7489-konforme Syntax

Formatiert gültige v=DMARC1-Tags sofort mit strikter Tag-Reihenfolge und Validierung.

Zero-Knowledge-Browser-Builder

Alle Richtlinienberechnungen und Parser-Ausführungen erfolgen lokal im Browser ohne externe Datenübertragung.

Multi-Plattform-Export-Engine

Generieren Sie BIND-Zoneneinträge, Cloudflare/Route53-Konfigurationen, dig-CLI-Befehle und RFC 7489 Abschnitt 7.1 Autorisierungsnachweise.

Technische Referenz & Architektur-Leitfaden

DNS-DMARC-Richtlinien-Generator & Syntax-Validator — Referenz-Leitfaden

Erstellen und validieren Sie RFC 7489-konforme DMARC DNS TXT-Einträge mit Richtliniendurchsetzung (none/quarantine/reject), rua/ruf-Berichten und Alignment-Tags.

Wichtige Parameter & Steuerelemente

v (Protokollversion)Enum ("DMARC1")

Identifiziert den TXT-Eintrag als DMARC-Richtliniendefinition. Muss zwingend als erstes Tag in Großbuchstaben gefolgt von einem Semikolon stehen.

Standard: DMARC1
p (Empfänger-Richtlinie)Enum ("none" | "quarantine" | "reject")

Durchsetzungsrichtlinie für empfangende Mailserver bei Fehlschlagen von SPF- und DKIM-Authentifizierung. 'none' überwacht ohne Zustellblockade; 'quarantine' leitet fehlerhafte Mails in den Spamordner; 'reject' verweigert die Annahme bereits im SMTP-Dialog.

Standard: none
sp (Subdomain-Richtlinie)Enum ("none" | "quarantine" | "reject")

Überschreibt die Richtlinie 'p' explizit für alle Subdomains. Die Angabe von 'sp=reject' schützt ungenutzte oder neu erstellte Subdomains wirksam vor Phishing.

Standard: Geerbt (identisch mit p)
rua (Aggregierte Feedback-Berichts-URIs)URI-Liste (mailto:address)

Kommagetrennte Liste von mailto:-URIs, an die empfangende MTAs tägliche aggregierte XML-Telemetrieberichte mit Authentifizierungsergebnissen und Quell-IPs senden.

Standard: Keine
ruf (Forensische Fehlerberichts-URIs)URI-Liste (mailto:address)

Kommagetrennte Liste von mailto:-URIs für sofortige detaillierte Vorfallberichte im RFC 6591 AFRF-Format bei spezifischen Authentifizierungsfehlern.

Standard: Keine
pct (Richtliniendurchsetzungs-Prozentsatz)Integer (0 - 100)

Prozentsatz der fehlschlagenden E-Mails, auf die die Richtlinie 'p' bzw. 'sp' angewendet wird. Ermöglicht eine schrittweise Einführung (z. B. 25% -> 50% -> 100%), bevor 'reject' greift.

Standard: 100
adkim / aspf (Alignment-Modi)Enum ("r" | "s")

Bestimmt die Strenge des Domain-Abgleichs für DKIM und SPF. 'r' (relaxed) erlaubt Übereinstimmungen auf Organisationsebene (subdomain.example.com mit example.com); 's' (strict) verlangt exakte FQDN-Übereinstimmung.

Standard: r (relaxed)

Profi-Tipps & Best Practices

Starten Sie mit 'p=none' für 2 bis 4

Starten Sie mit 'p=none' für 2 bis 4 Wochen und analysieren Sie aggregierte XML-Berichte (rua), um alle legitimen Drittanbieter-Versender (SendGrid, Microsoft 365, Zendesk) zu identifizieren. Sobald über 99% des legitimen Datenverkehrs SPF/DKIM-konform sind, wechseln Sie zu 'p=quarantine; pct=25', steigern auf 100% und aktivieren schließlich 'p=reject'.

Wenn Ihre Domain 'example.com' lautet

Wenn Ihre Domain 'example.com' lautet und 'rua' auf 'mailto:[email protected]' zeigt, erfordert RFC 7489 Abschnitt 7.1 einen DNS TXT-Eintrag unter 'example.com._report._dmarc.thirdparty.com' mit dem Wert 'v=DMARC1;'. Andernfalls verwerfen Mailanbieter Berichte zum Schutz vor DDoS-Angriffen.

Angreifer fälschen selten die

Angreifer fälschen selten die Hauptdomain, sondern erfinden Subdomains (z. B. invoice.example.com). Mit 'v=DMARC1; p=none; sp=reject; rua=mailto:...' bleibt der reguläre E-Mail-Verkehr der Hauptdomain unbeeinflusst, während Subdomain-Spoofing sofort unterbunden wird.

Bei automatischer Weiterleitung oder

Bei automatischer Weiterleitung oder Mailinglisten ändert sich die IP des weiterleitenden Servers, wodurch das SPF-Alignment unweigerlich fehlschlägt. Da kryptografische DKIM-Signaturen den Transport unbeschadet überstehen, stellt DKIM das verlässlichste Kriterium dar.

Häufige Fallstricke & Fehlerbehebung

Aggregierte rua-Berichte werden von großen Anbietern (Google, Microsoft) nicht zugestellt

Überprüfen Sie, ob der rua-URI das erforderliche Präfix 'mailto:' enthält (z. B. 'mailto:[email protected]'). Bei externen Berichtsdomains muss der externe Verifizierungs-TXT-Eintrag existieren. Prüfen Sie zudem das Speicherkontingent des Zielpostfachs.

Legitime Marketing- oder CRM-Mails landen nach Aktivierung von quarantine/reject im Spam oder bouncen

Analysieren Sie die XML-Berichte auf Alignment-Fehler. Stellen Sie sicher, dass der Drittanbieter Mails mit einem DKIM-Schlüssel signiert, dessen Domain exakt zum RFC 5322 From-Header passt, und nicht lediglich mit der Shared-Domain des Anbieters. Konfigurieren Sie bei Bedarf CNAMEs für die Return-Path-Domain (SPF).

DNS-Tools melden 'DMARC Record Not Found' oder 'Doppelte DMARC-Einträge'

DMARC-Einträge müssen zwingend als TXT-Eintrag unter der Subdomain '_dmarc.ihredomain.de' angelegt werden (niemals auf der Root '@'). Es darf genau ein TXT-Eintrag existieren, der mit 'v=DMARC1' beginnt. Mehrere DMARC-Einträge führen nach RFC 7489 zur vollständigen Ungültigkeit der Richtlinie.

Häufig gestellte Fragen (FAQ)

Wie arbeiten SPF, DKIM und DMARC technisch zusammen?▼

SPF (RFC 7208) prüft die IP-Adresse des sendenden Servers gegen den Envelope-Absender (MAIL FROM). DKIM (RFC 6376) signiert E-Mail-Header und -Inhalt kryptografisch. DMARC (RFC 7489) verknüpft beide Verfahren mit der sichtbaren Absenderadresse ('From:', RFC 5322), fordert Alignment (Domain-Übereinstimmung), definiert Handlungsanweisungen bei Fehlern und stellt Berichte bereit.

Müssen sowohl SPF als auch DKIM erfolgreich sein, um DMARC zu bestehen?▼

Nein. Gemäß RFC 7489 besteht eine E-Mail die DMARC-Prüfung, wenn ENTWEDER das SPF-Alignment ODER das DKIM-Alignment erfolgreich ist. Es müssen nicht beide Mechanismen gleichzeitig greifen, wenngleich beidseitige Konfiguration für Redundanz sorgt.

Was ist der Unterschied zwischen den Alignment-Modi relaxed ('r') und strict ('s')?▼

Im Relaxed-Modus ('r', Standard) reicht es aus, wenn Envelope-Domain (SPF) bzw. Signaturdomain (DKIM) dieselbe organisatorische Hauptdomain wie der From-Header teilen (z. B. mail.example.com und example.com). Im Strict-Modus ('s') muss der Hostname zeichengenau übereinstimmen.

Warum führen automatische E-Mail-Weiterleitungen oft zu DMARC-Fehlern?▼

Weiterleitende Server verändern die Absender-IP, wodurch SPF fehlschlägt. Mailinglisten modifizieren zudem oft Betreffzeilen oder fügen Fußzeilen an, was die DKIM-Prüfsumme zerstört. Als Gegenmaßnahme dient ARC (Authenticated Received Chain, RFC 8617), das Authentifizierungsergebnisse über Zwischenstationen hinweg beglaubigt.

Worin unterscheiden sich rua- und ruf-Berichte?▼

rua liefert tägliche aggregierte XML-Übersichten über Sendemengen, Quell-IPs und Authentifizierungsquoten ohne E-Mail-Inhalte. ruf erzeugt Echtzeit-Meldungen einzelner fehlgeschlagener Nachrichten samt Header-Auszügen. Wegen Datenschutz- und DSGVO-Bedenken hinsichtlich personenbezogener Daten versenden die meisten großen Provider keine ruf-Berichte mehr.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →
DNS CAA-Record-Generator & Richtlinien-PrüferSicherheit

Erstellen Sie RFC 8659-konforme DNS-CAA-Einträge zur Begrenzung der SSL/TLS-Zertifikatsausstellung auf autorisierte Zertifizierungsstellen (Let's Encrypt, DigiCert, Sectigo).

Werkzeug öffnen→
DNS DKIM TXT-Eintrag-Generator & SelektorSicherheit

Erstellen Sie RFC 6376-konforme DNS-DKIM-TXT-Einträge mit Selektor, Public-Key-Formatierung (v=DKIM1; k=rsa; p=...), 255-Zeichen-Aufteilung und Prüfroutinen.

Werkzeug öffnen→
MTA-STS-Richtlinien & TLS-RPT DNS-Record-GeneratorSicherheit

Umfassende Dokumentation und Best Practices zur Erstellung von RFC 8461 MTA-STS-Richtliniendateien, _mta-sts DNS-TXT-Einträgen und RFC 8460 TLS-RPT-Berichtsdatensätzen.

Werkzeug öffnen→
JWT Token Decoder & Security InspectorSicherheit

Entwickler-Werkzeug zum clientseitigen Dekodieren von JSON Web Tokens, Prüfen von RFC 7519- und OIDC-Claims, Überwachen von Ablaufzeiten und lokalen Verifizieren von HMAC-Signaturen.

Werkzeug öffnen→
Kryptografischer Passwort- & Passphrasen-GeneratorSicherheit

Erzeugen Sie kryptografisch sichere Passwörter mit hoher Entropie, einprägsame Diceware-Passphrasen, PINs und API-Token mit nativer Web Crypto CSPRNG nach NIST SP 800-63B.

Werkzeug öffnen→
Kryptografischer Hash-Generator & Prüfsummen-RechnerSicherheit

Berechnen Sie sofort SHA-256, SHA-512, MD5, SHA-1, SHA-3, Keccak und CRC32 lokal im Browser mit 100% nativer Web Crypto API Sicherheit.

Werkzeug öffnen→