Eingaben
Beispiel
Prüfe einen SPF-Record, _dmarc-Policy-Tags und selector._domainkey-Owner-Namen vor dem Veröffentlichen.
SPF/DMARC/DKIM-Prüfer
Liest SPF-, DMARC- und DKIM-TXT-Records, markiert Policy-Probleme und fragt DNS nur bei Bedarf ab.
Nutze es, um Mail-Auth-Records zu lesen, bevor DNS geändert oder mit einem gelieferten Header verglichen wird.
Drei Records, eine Authentifizierungsgeschichte
SPF, DKIM und DMARC werden meist zu verschiedenen Zeitpunkten konfiguriert, von verschiedenen Tools, unter verschiedenem Zeitdruck — funktionierende Mail-Authentifizierung entsteht aber nur, wenn alle drei dieselbe Geschichte erzählen. SPF benennt die Server, die für die Envelope-Domain senden dürfen, DKIM belegt, dass eine Signaturdomain für die Nachricht bürgt, und DMARC entscheidet, was Empfänger tun sollen, wenn nichts davon zur sichtbaren From-Adresse passt. Die meisten echten Zustellprobleme wohnen in den Nahtstellen: ein zweiter SPF-Record aus einer gut gemeinten Plattform-Anleitung, ein still rotierter DKIM-Selector, eine DMARC-Policy, die Reject verspricht, während das Alignment leise scheitert.
Dieser Checker liest alle drei Record-Familien einer Domain und markiert Probleme auf Werteebene: Syntaxfehler, schwache oder widersprüchliche Policy-Tags, fehlgeformte Schlüssel, doppelte Records und Owner-Namen, die der Konvention nicht folgen. Er arbeitet mit eingefügten TXT-Werten, wenn die Zonendaten vorliegen, oder mit Live-DNS, wenn zählt, was die Welt gerade auflöst.
Von der Record-Inspektion zum sicheren Publizieren
Füge bekannte Records zuerst ein, wenn du an einer Zone arbeitest: Der Parser läuft lokal, ein SPF- oder DMARC-Entwurf lässt sich also vor der Veröffentlichung korrigieren. Für den Live-Blick gib die Domain an und — wenn DKIM Teil der Frage ist — den Selector, den deine Sending-Plattform wirklich verwendet; der Lookup baut daraus die selector._domainkey-Namen. Eine erwartete DMARC-Policy macht den Report auf die richtige Art meinungsstark: Er zeigt die Distanz zwischen Absicht und veröffentlichtem Zustand.
Lies Warnungen nach Schadensradius. Doppelte SPF-Records sind Permerror-Territorium und kommen zuerst. Danach DMARC: Policy-Tag, Alignment-Erwartungen, Reporting-Adressen. Dann die DKIM-Schlüsselform — Algorithmus, Schlüssellänge, leere oder zurückgezogene Keys. Veröffentliche Änderungen pro Record-Familie einzeln und prüfe nach dem DNS-Settling erneut, damit eine Regression der Änderung zuordenbar bleibt, die sie verursacht hat.
Lookup-Pfade und was lokal bleibt
Eingefügte Records werden vollständig im Browser geparst. Live-Lookups starten erst per Klick und senden nur die nötigen DNS-Namen — Domain, _dmarc-Owner und selector-abgeleitete Namen — über DNS-over-HTTPS mit dem Same-Origin-DNS-Helper als Fallback. Das Tool inspiziert veröffentlichte Records; es versendet keine Testnachrichten, sieht deinen realen Sendepfad nicht und kann deshalb nicht beweisen, dass eine zugestellte Mail DMARC-Alignment besteht.
Häufige Fragen
Beweist dieser Check, dass meine Mail DMARC besteht?
Nein. Er prüft die veröffentlichten Records — eine Voraussetzung, nicht das Urteil. Ein echter DMARC-Pass hängt zusätzlich am Sendepfad, an Envelope-Domain, Header-From, der tatsächlich angebrachten DKIM-Signatur und deren Alignment.
Warum ist ein zweiter SPF-Record so gravierend?
Weil der Standard genau einen SPF-Record pro Name verlangt und viele Empfänger Duplikate mit einem permanenten Auswertungsfehler quittieren — das kann die Authentifizierung komplett scheitern lassen. Typische Ursache: Eine SaaS-Anleitung wurde befolgt, ohne den Bestand zu prüfen.
Welchen DKIM-Selector trage ich ein?
Den, den deine Sending-Plattform konfiguriert hat — üblich sind s1, default oder datierte Selectors. Der Lookup fragt selector._domainkey.domain ab; ein falscher Selector beweist nur, dass unter genau diesem Namen kein Schlüssel liegt.
Was bedeutet Alignment konkret?
Dass die vom Empfänger validierte Domain — über SPFs Envelope-Domain oder DKIMs Signaturdomain — zur Domain passt, die der Mensch im From sieht. DMARC zählt nur alignte Authentifizierung; eine gültige DKIM-Signatur einer fremden Domain hilft nicht.
Sollte ich direkt auf p=reject gehen?
Nicht standardmäßig. Starte mit p=none und Aggregate-Reports, korrigiere legitime Sender und wähle die Durchsetzung danach passend zu Zweck und indirekten Mailflüssen der Domain. RFC 9989 warnt vor p=reject bei allgemeinen Benutzer-Maildomains; streng kontrollierte Sendedomains oder Subdomains sind anders zu bewerten.
Werden eingefügte Records irgendwohin hochgeladen?
Nein. Eingefügte Werte bleiben in der Browser-Session. Nur ein Live-Lookup sendet etwas — nämlich die abgefragten DNS-Namen — an den Resolver-Pfad.