DMARC-Record-Checker — sofortige Validierung gegen die veröffentlichte Policy Ihrer Domain
Geben Sie eine Domain ein. Der Browser fragt DNS over HTTPS direkt am 1.1.1.1-Resolver von Cloudflare an und parst den resultierenden TXT-Record unter _dmarc.ihredomain.de. Sie sehen den Rohrecord, die geparste Policy, die Aggregate- und Failure-Report-Adressen, die Alignment-Modi, die Subdomain-Policy und alle Syntax- oder Betriebsprobleme — einschließlich derer, die Gmail, Yahoo und Microsoft Outlook daran hindern, Massen-E-Mail unter den 2024-2026-Anforderungen anzunehmen. Kein Konto, keine Telemetrie, keine Rate-Limits; die Abfrage erfolgt komplett in Ihrem Browser.
Domain prüfen
Geben Sie eine Domain ein — Ihre eigene, die eines Wettbewerbers, einen Anbieter, den Sie evaluieren. Die Abfrage läuft in Ihrem Browser gegen den öffentlichen DNS-over-HTTPS-Resolver von Cloudflare.
DNS over HTTPS via cloudflare-dns.com · Keine Daten an unsere Server gesendet
DMARC ist die Policy-Schicht über SPF und DKIM — der Ort, an dem Sie empfangenden Mailbox-Providern mitteilen, was mit E-Mail zu tun ist, die Authentifizierung oder Alignment nicht besteht
Der DMARC-Record ist ein einzelner TXT-Eintrag unter _dmarc.ihredomain.de in Ihrem DNS. Es ist eine kurze Policy-Erklärung, definiert in RFC 7489, die Receiver wie Gmail, Outlook und Yahoo auswerten, wenn sie eingehende E-Mail bewerten, die behauptet, von Ihrer Domain zu stammen. Der Receiver führt zuerst SPF- und DKIM-Checks aus; DMARC stellt dann zwei weitere Fragen. Die erste Frage: Hat mindestens einer dieser Checks mit der Domain im From:-Header bestanden — die Alignment-Anforderung, die verhindert, dass ein Angreifer SPF auf seiner eigenen Domain besteht, während er behauptet, Sie zu sein. Die zweite Frage: Was soll der Receiver tun, wenn keiner der Checks aligned bestanden hat: normal zustellen (p=none, nur Monitoring), in den Spam-Ordner leiten (p=quarantine) oder direkt zur SMTP-Zeit ablehnen (p=reject).
Der Record sagt Receivern auch, wohin Aggregate-Reports gesendet werden sollen — die täglichen XML-Zusammenfassungen, die zeigen, welche Versender Ihre Domain nutzen und ob sie bestehen oder fallen — über das Tag rua. Ein zweites Tag, ruf, fordert forensische Failure-Reports an, obwohl die meisten großen Receiver diese 2017-2018 aus Datenschutzgründen eingestellt haben. Zwei Alignment-Modus-Tags steuern, ob SPF- und DKIM-Checks streng (exakte Domain-Übereinstimmung) oder relaxed (organisationale Domain-Übereinstimmung) ausgerichtet sein müssen: aspf und adkim, beide standardmäßig relaxed. Ein Subdomain-Policy-Tag sp setzt die Policy für Subdomains; ohne dieses Tag erben Subdomains die Policy des Eltern-Eintrags. Ein Prozentsatz-Tag pct wendet die Policy auf einen Anteil der fehlschlagenden E-Mail an — nützlich während Enforcement-Rollouts, aber eine häufige Quelle der Verwirrung, wenn Versender es nach Abschluss des Rollouts vergessen.
Die Enforcement-Landschaft 2024-2026 hat den Unterschied zwischen Policy-Stufen materialisiert. Seit Februar 2024 verlangen Gmail und Yahoo von Massenversendern (5.000+ Nachrichten täglich an Gmail-Konten) die Veröffentlichung eines DMARC-Records mit Mindest-Policy p=none; ohne wird E-Mail abgelehnt. Microsoft Outlook folgte im Mai 2025 mit dem gleichen Schwellenwert und einem 550 5.7.15 SMTP-Ablehnungscode für nichtkonforme Massen-E-Mail. Gmails Postmaster Tools v2 im Oktober 2025 fügten einen binären „Compliance Status"-Indikator hinzu, der DMARC auf Enforcement-Niveau (p=quarantine oder p=reject) als stärkeres Vertrauenssignal liest als reines Monitoring. Die Progression von p=none zu Enforcement ist für Versender, die Inbox-Platzierung im Skalierungsbereich aufrechterhalten wollen, nicht mehr optional.
Im DACH-Kontext überschneidet sich das mit dem regulatorischen Rahmen. Der BfDI und die Datenschutzkonferenz (DSK) haben in ihren Hinweisen 2024-2025 Domain-Authentifizierung als angemessene technische Maßnahme nach Art. 32 DSGVO und §22 BDSG-neu eingeordnet. Für einen deutschen Mittelständler unter B2B-Audit, eine Schweizer Bank unter dem revidierten DSG und der FINMA-Aufsicht, oder einen österreichischen Anbieter unter der DSB ist das Veröffentlichen und Halten von DMARC im Enforcement Teil des angemessenen Mindeststandards, den ein Sicherheits-Auditor eines Geschäftskunden zu sehen erwartet. Hinzu kommt, dass die BSI-C5-Registrierungsfrist am 6. März 2026 lief mit Strafen bis zu 10 Mio. € oder 2% des weltweiten Jahresumsatzes — und C5-Compliance bewertet E-Mail-Authentifizierung als Teil des Sicherheitsprofils. Das Tool oben sagt Ihnen, auf welcher Seite dieser Linie Ihr Record steht, und der Rest dieser Seite geht durch, was zu beheben ist, wenn es Probleme zurückgibt.
Jedes Tag, das der Checker parst, was es bedeutet und welchen Wert Sie typischerweise verwenden sollten
Beispielrecord im Enforcement
v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de; ruf=mailto:forensik@beispiel.de; sp=reject; adkim=s; aspf=s; pct=100; fo=1
v=DMARC1 Versionsbezeichner. Immer DMARC1. Muss das erste Tag sein. Receiver ignorieren den Record bei Fehlen oder Fehlformatierung.
p=none | quarantine | reject Policy für fehlschlagende E-Mail. none = nur Monitoring, quarantine = in Spam leiten, reject = zur SMTP-Zeit blockieren. Die Vertrauenssignal-Skala 2024-2026 läuft none → quarantine → reject.
rua=mailto:adresse Wohin Aggregate-XML-Reports gesendet werden — die tägliche Zusammenfassung der Authentifizierungsergebnisse aller Versender, die Ihre Domain nutzen. Kritisch für Sichtbarkeit. Mehrere Adressen erlaubt, durch Komma getrennt.
ruf=mailto:adresse Ziel für Failure-Reports (forensisch). Die meisten großen Receiver haben das Senden 2017-2018 aus Datenschutzgründen eingestellt. Optional und zunehmend ignoriert — setzen Sie es, wenn Ihre DMARC-Plattform es verlangt; rechnen Sie nicht mit Volumen.
sp=none | quarantine | reject Subdomain-Policy. Wenn weggelassen, erben Subdomains p. sp=reject bei gleichzeitigem p=quarantine ist ein gängiges Rollout-Muster — streng auf ungenutzten Subdomains, schrittweise auf der Hauptdomain.
adkim=r | s · aspf=r | s Alignment-Modi. r (relaxed, Default) erlaubt organisationale Domain-Übereinstimmung — mail.beispiel.de aligned mit beispiel.de. s (strict) verlangt exakte Übereinstimmung. Strict fängt mehr Spoofing, bricht aber mehr legitime Versender mit Subdomains.
pct=N (1-100) Prozentsatz fehlschlagender E-Mail, auf den die Policy angewendet wird. pct=10 mit p=quarantine bedeutet, 10% der Fehlschläge in Quarantäne, den Rest als p=none behandeln. Wird bei Rollouts genutzt; sollte im stabilen Zustand auf pct=100 zurückkehren.
fo=0 | 1 | d | s Failure-Report-Optionen. fo=1 sendet einen Report, wenn entweder SPF oder DKIM scheitert (am nützlichsten). fo=d nur bei DKIM-Fehler, fo=s nur bei SPF, fo=0 nur wenn beide scheitern. Default 0 liefert zu wenig Daten für diagnostischen Nutzen.
Die acht Probleme, die wir am häufigsten beim Ausführen dieses Checks gegen Kunden-Domains sehen
Kein Record veröffentlicht
Das häufigste Ergebnis bei der ersten Prüfung. Null Schutz, und seit Februar 2024 blockiert es die Zustellung an Gmail- und Yahoo-Konten für Massenversender (5.000+ täglich). Beginnen Sie mit v=DMARC1; p=none; rua=mailto:dmarc@ihredomain.de;, um Monitoring zu starten; das gibt Ihnen Sichtbarkeit, wer unter Ihrer Domain sendet, bevor Sie die Policy verschärfen.
Policy seit Jahren bei p=none festgefahren
Der Record existiert, aber die Policy hat sich nie von Monitoring weiterbewegt. Gmails Postmaster Tools v2 seit Oktober 2025 liest DMARC auf Enforcement-Niveau (quarantine oder reject) als stärkeres Vertrauenssignal als p=none. Wenn Ihre Aggregate-Reports 30-90 Tage saubere Alignment für bekannte Versender zeigen, wechseln Sie zu p=quarantine; pct=10, skalieren Sie pct über 4-8 Wochen, dann zu p=reject.
Mehrere DMARC-Records
Zwei oder mehr TXT-Records unter _dmarc.ihredomain.de. Nach RFC 7489 führt das dazu, dass Receiver die Policy als undefiniert behandeln und Enforcement vollständig überspringen. Tritt meist auf, wenn ein Security-Tool einen Record hinzufügt, ohne den alten zu entfernen. Konsolidieren Sie auf einen einzelnen Record.
Syntaxfehler
Fehlende Semikolons, ungültige Tag-Werte, falscher Versionsstring, fehlerhafte E-Mail in rua. Receiver parsen strikt; ein einzelner Syntaxfehler führt dazu, dass der Record ignoriert wird. Der häufigste Fehler, den wir sehen, ist ein Tippfehler in v=DMARC1 (Kleinbuchstabe v, fehlende 1, oder DMARC2 von jemandem, der es mit dem IETF-Draft DMARCbis verwechselt).
Keine rua-Adresse — keine Sichtbarkeit
Ein DMARC-Record ohne rua setzt die Policy bei Receivern weiterhin durch, aber Sie erhalten keine Aggregate-Reports. Sie fliegen blind, welche legitimen Versender Ihre Domain nutzen und ob sie Authentifizierung bestehen. Setzen Sie immer rua — auf einen Posteingang, den Sie tatsächlich lesen, oder auf eine DMARC-Monitoring-Plattform, die das XML für Sie parst.
Externes Report-Ziel nicht autorisiert
Wenn Ihr rua oder ruf auf eine Domain zeigt, die Ihnen nicht gehört (eine DMARC-Plattform wie Postmark, dmarcian, EasyDMARC oder unser eigenes Monitoring), benötigt die empfangende Domain einen separaten TXT-Record unter ihredomain.de._report._dmarc.ihredomain.com, der das domainübergreifende Reporting autorisiert. Die meisten Plattformen richten das für Sie ein; manche erfordern manuelle Konfiguration.
Keine Subdomain-Policy auf geparkten oder ungenutzten Subdomains
Ohne sp erben Subdomains die Eltern-Policy. Wenn Ihr Elternteil während eines langsamen Rollouts bei p=none ist, ist jede Subdomain — einschließlich derer, von denen Sie nicht senden, aber die Angreifer spoofen können — ebenfalls bei p=none. Fügen Sie sp=reject früh hinzu; es kostet nichts für Subdomains, die Sie nicht nutzen.
Festgefahrener pct-Wert aus altem Rollout
Records mit p=reject; pct=10 sind häufig — das Team hat quarantine ausgerollt, pct skaliert, zu reject gewechselt und vergessen, pct auf 100 zurückzusetzen. Ergebnis: Nur 10% der fehlschlagenden E-Mail wird tatsächlich abgelehnt. Stellen Sie pct=100 im stabilen Zustand wieder her; Sie haben die Policy, die Sie wollten, nur wenn pct passt.
Der Check ist Schritt eins. Die nächsten Schritte sind Aggregate-Report-Ingest, Alignment-Fixes für sich falsch verhaltende Versender und der Rollout zum Enforcement
Ein DMARC-Record allein verbessert die Zustellbarkeit nicht — er fügt nur eine Policy-Erklärung hinzu, die sich in Receiver-Entscheidungen widerspiegeln kann oder nicht. Die eigentliche Arbeit, sicher zu p=reject zu gelangen, ist: tägliche Aggregate-Reports 30-90 Tage einlesen, um zu sehen, wer unter Ihrer Domain sendet, SPF- und DKIM-Alignment für legitime Versender beheben, die fehlschlagen (Newsletter-Plattformen, transaktionale ESPs, Marketing-Tools, Lohnabrechnungssysteme, Support-Ticket-Software — jede Domain hat einen langen Schwanz), dann pct stufenweise hochfahren und auf Kollateralschäden achten, bevor Enforcement erklärt wird.
Das Tool oben gibt Ihnen die Policy-Momentaufnahme. Die längere Arbeit ist das, was wir täglich für gemanagte Kunden tun — Aggregate-Report-Parsing, Versender-Identifikation, Alignment-Behebung und der Rollout von Monitoring zu Quarantine zu Reject, ohne den eigenen Lohnabrechnungsanbieter des Unternehmens drei Tage vor dem Zyklus zu blockieren. Wenn Sie das auf Ihrer eigenen Domain ausführen und das Ergebnis nach Jahren p=none ist, ist das das Gespräch, das geführt werden sollte, nicht das Gespräch darüber, welcher DMARC-Record veröffentlicht werden soll.
Was Teams fragen, wenn sie diesen Check zum ersten Mal ausführen
Sendet dieses Tool meine Daten an Ihre Server?
+
Nein. Die Abfrage läuft vollständig in Ihrem Browser über den öffentlichen DNS-over-HTTPS-Resolver von Cloudflare unter cloudflare-dns.com/dns-query. Die Domain, die Sie eingeben, wird an die DNS-Infrastruktur von Cloudflare gesendet — der gleiche Abfragepfad, den Ihr Browser für jede DNS-Auflösung verwendet — und die Antwort wird lokal geparst. Wir sehen weder die Abfrage noch das Ergebnis noch andere Browsing-Daten. Sie können das im Netzwerk-Tab der Entwicklertools Ihres Browsers überprüfen; es gehen keine Anfragen an Authorize-Hosting-Domains während des Checks.
Reicht p=none für die Bulk-Sender-Anforderungen von Gmail und Yahoo?
+
Ja, technisch. Die Ankündigungen von Gmail und Yahoo im Februar 2024 legten das Minimum auf „einen DMARC-Record mit mindestens p=none" fest. Microsoft Outlook folgte mit demselben Schwellenwert im Mai 2025. Also ist p=none das Eintrittsticket; ohne wird E-Mail an diese Receiver zur SMTP-Zeit abgelehnt.
Die Einschränkung ist, dass seit dem Start von Gmails Postmaster Tools v2 im Oktober 2025 der binäre „Compliance Status"-Indikator ein stärkeres Vertrauenssignal für Enforcement-Policy-DMARC (p=quarantine oder p=reject) als für Monitoring liefert. Inbox-Platzierung, Complaint-Schwellenwerte und Reputationswiederherstellung spielen alle eine Rolle. p=none bringt Sie an der Tür vorbei; p=reject mit sauberen Aggregate-Reports verschafft Ihnen den besseren Tisch.
Wie lange sollten wir bei p=quarantine bleiben, bevor wir zu p=reject wechseln?
+
Hängt von der Form Ihres Versandprogramms ab, aber das typische Muster, das wir in gemanagten Migrationen sehen, ist 30 Tage bei p=none, um Aggregate-Reports zu sammeln, dann ein gestaffelter p=quarantine-Rollout: pct=10 für 1-2 Wochen, pct=25 für 1-2 Wochen, pct=50 für 2 Wochen, pct=100 für 2-4 Wochen, dann Wechsel zu p=reject; pct=100. Der vollständige Rollout von Kein-DMARC zu Enforcement dauert typisch 3-4 Monate. Kürzer ist möglich für Versender mit einfacher, gut kontrollierter Infrastruktur; länger ist normal für Unternehmen mit Dutzenden legitimer Versandquellen, die Alignment-Behebung benötigen.
Wir haben p=reject und sehen trotzdem Spoofing-Versuche durchkommen. Wie?
+
Mehrere Möglichkeiten. Zunächst: p=reject schützt nur vor direktem Domain-Spoofing — Angreifer, die Ihre exakte Domain im From:-Header verwenden. Lookalike-Domains (ihre-firma.co statt ihre-firma.de oder Homoglyph-Varianten) und Display-Name-Spoofing (wo der sichtbare Name „Ihre Firma" lautet, aber die From-Adresse angreifer@gmail.com ist) sind völlig andere Angriffsflächen, die DMARC nicht adressiert.
Außerdem: Manche Receiver — insbesondere kleine oder selbst gehostete Server, bestimmte Mailinglisten-Software und einige Legacy-Enterprise-Gateways — setzen DMARC gar nicht oder inkonsistent durch. Ihre Aggregate-Reports sagen Ihnen, welche Receiver Ihre Policy honorieren; der lange Schwanz kleiner Receiver kann trotzdem Fehlschläge ankommen lassen.
Und schließlich hat DMARC bekannte Interaktionen mit Mailinglisten und Weiterleitung. Eine legitime Nachricht, die über eine Mailingliste weitergeleitet wird, scheitert bei DMARC oft am zweiten Hop, weil die Liste den Body umschreibt oder das From ändert. ARC (Authenticated Received Chain) wurde dafür entworfen, aber die Adoption ist ungleichmäßig. Wenn Ihre Reports DMARC-Fehlschläge in Korrelation mit Mailinglisten-Aktivität zeigen, ist das, was Sie sehen.
Können wir diesen Checker für Kundendomänen nutzen, die uns nicht gehören?
+
Ja. DMARC-Records sind öffentliche DNS-Records — jeder kann sie für jede Domain abfragen. Agenturen, MSPs und Berater führen solche Checks routinemäßig im Rahmen des Kunden-Onboardings durch. Der Checker authentifiziert sich in keiner Weise gegen die Ziel-Domain; er führt nur eine öffentliche DNS-Abfrage durch. Der einzige Unterschied zwischen der Prüfung der eigenen Domain und der eines Kunden ist, dass Sie für die eigene auf das Ergebnis reagieren können.
Was ist mit DMARCbis — dem vorgeschlagenen DMARC-Update?
+
DMARCbis ist der IETF-Draft, der RFC 7489 aktualisiert — er fügt eine Public-Suffix-List-bewusste Auflösung für die organisationale Domain hinzu, formalisiert Tree Walking für Subdomain-Auflösung, depreziert pct zugunsten benannter Prozent-Rollouts und verschärft Report-Format-Anforderungen. Mitte 2026 ist der Draft noch im IETF-Prozess; kein großer Receiver hat signalisiert, dass er DMARCbis-spezifische Syntax verlangen wird. Der Versionsstring bleibt v=DMARC1; veröffentlichen Sie keine Records, die DMARC2 oder DMARCbis behaupten — die sind nicht gültig und Receiver ignorieren sie.