Ein „Nein DMARC Eintrag Die Warnung „gefunden“ ist ein Ausgangspunkt für die Diagnose. Sie kann auf eine tatsächlich fehlende Richtlinie, eine Abfrage nach dem falschen Namen, eine Bearbeitung in einem inaktiven DNS Konto, eine ältere zwischengespeicherte Antwort oder einen Auflösungsfehler hinweisen.
Stellen Sie vor der Veröffentlichung eines weiteren Datensatzes fest, was das Tool abgefragt hat und welche autorisierenden Server diese Antwort steuern. Behalten Sie den DNS -Antwortcode sowie alle zurückgegebenen TXT Daten bei. Dies trennt einen fehlenden Datensatz von ein Rekord das existiert, aber nicht über einen bestimmten Suchpfad abgerufen werden kann.
Erfassen Sie die genaue fehlgeschlagene Suche
Notieren Sie das Tool, die abgefragte Domäne, den Zeitstempel, den Resolver und die vollständige DNS Antwort, sofern verfügbar. Speichern Sie den aktuellen Richtlinieneintrag und DNS Konfiguration vor der Bearbeitung.
Diese beispielhaften BIND-Dig-Befehle werden hier nicht ausgeführt. Ersetzen Sie Dokumentationsnamen durch den genehmigten Zielserver und den tatsächlich delegierten Server. Der BIND-Dig-Handbuch definiert den Server, den Namen, den Typ und die Abfrageoptionen. Der Autoritätsabschnitt hilft dabei, den Kontext negativer Antworten beizubehalten. Kommentare behalten den Header-Status und die Flags. Eine einfache Abfrage für die sichtbare Von-Domäne example.com beginnt hier:
dig _dmarc.example.com . TXT +noalle +Antwort +Autorität +KommentareBehalten Sie den Antwortstatus sowie den Antwortabschnitt bei. Eine Kurzanzeige kann den Unterschied zwischen einem Namen ohne relevante TXT Daten und einem Auflösungsfehler verdecken.
Identifizieren Sie, wer die öffentliche DNS Antwort kontrolliert
Dieses Problem wird oft zu einem Eigentumsproblem. Ein Unternehmen hat möglicherweise die Domain von einem Anbieter gekauft, seine Website an einen anderen Anbieter verlegt und DNS an ein drittes Konto delegiert. Ein im falschen Bereich hinzugefügter Datensatz kann vollständig erscheinen, hat aber keine Auswirkung auf öffentliche E-Mail-Prüfungen.
Bitten Sie den Betreiber, den aktuellen autorisierenden DNS Host zu identifizieren und seine Antwort für den vorgesehenen Namen anzuzeigen. Vermeiden Sie die Zahlung für wiederholte Korrekturen ohne nachgewiesenen Veröffentlichungspfad. Fragen Sie auch, ob die Warnung Ihre Hauptdomain, eine sendende Subdomain oder eine andere von einer Anwendung verwendete Identität betrifft.
Überprüfen Sie den Namen und das Veröffentlichungskonto
Überprüfen Sie die autorisierende Delegation für die Zone, einschließlich einer separat delegierten untergeordneten Zone, falls vorhanden. Fragen Sie einen relevanten autorisierenden Server direkt ab, indem Sie seinen tatsächlichen Namen verwenden:
dig @ ns1.example.net _dmarc.example.com . TXT +norecurse +noall +answer +authority +commentsWenn der DNS Editor die Zone automatisch anhängt, geben Sie ein _dmarc.example.com kann versehentlich veröffentlicht werden _dmarc.example.com.example.com. In einem anderen Editor nur Eingabe _dmarc kann falsch sein. Überprüfen Sie den endgültig veröffentlichten Eigentümernamen, anstatt für jeden Anbieter das gleiche Eingabeformat vorzuschreiben.
Weitere häufige Fehler sind: a TXT Eintrag am Domänenstamm, eine Bearbeitung eines inaktiven DNS Kontos, eine nicht gespeicherte Änderung oder eine Suche nach der falschen sendenden Domäne.
Unterscheiden Sie zwischen Abwesenheit und Suchfehler
- Beobachtung: NXDOMAIN ; Was zu untersuchen ist: Der abgefragte Name wird als nicht vorhanden gemeldet
- Beobachtung: NOERROR ohne relevante TXT Daten; Was zu untersuchen ist: Der abgefragte Name enthält in dieser Antwort keine anwendbare TXT Antwort
- Beobachtung: SERVFAIL ; Was zu untersuchen ist: Lösung fehlgeschlagen; Überprüfen Sie Autorität, Delegation, Validierung und Abhängigkeiten
- Beobachtung: Es gibt eine autoritative Antwort, die rekursive Antwort ist jedoch unterschiedlich. Was zu untersuchen ist: Cache-Status, Resolver-Ansicht, Delegationspfad und Timing
- Beobachtung: Mehrere Kandidaten-Richtlinienaufzeichnungen; Was zu untersuchen ist: Ein Datensatzproblem, kein einfacher Zustand fehlender Datensätze
Die DNS Status und die Unterscheidung negativer Antworten werden in beschrieben RFC 1035 §4.1.1, RFC 2308 §2.1 Und RFC 2308 §2.2. Behandeln Sie SERVFAIL nicht als Erlaubnis, einen anderen Datensatz zu veröffentlichen. Der Datensatz ist möglicherweise vorhanden, aber über den fehlgeschlagenen Lösungspfad nicht verfügbar. Ebenso hat ein fehlender Eintrag bei einem Kindernamen keinen Einfluss darauf, ob ein Empfänger an anderer Stelle eine anwendbare Richtlinie finden kann RFC 9989 §4.10.1.
Ausführliches Beispiel: Der Datensatz befindet sich in einer inaktiven Zone
Betrachten Sie diese anschauliche Untersuchung. Ein Administrator fügt hinzu _dmarc zum DNS Panel des Registrars. Die öffentliche Delegation verweist jedoch auf einen separaten DNS Host, der während einer früheren Website-Migration verwendet wurde.
Das Bedienfeld des Registrars zeigt den beabsichtigten Wert an. Eine direkte Anfrage an die aktuell delegierte Behörde gibt diese nicht zurück. Längeres Warten kann eine inaktive Zone nicht autorisierend machen.
Die Berichtigung ist mit entsprechender Genehmigung durch die zuständige Behörde zu veröffentlichen. Behalten Sie anschließend die maßgebliche Antwort bei und vergleichen Sie die rekursive Beobachtung. Das Ändern von Nameservern, nur um das frühere Panel wirksam zu machen, könnte zu Störungen bei nicht zusammenhängenden Web- und E-Mail-Datensätzen führen, daher handelt es sich um eine separate, viel umfassendere Änderung.
Vergleichen Sie maßgebliche und zwischengespeicherte Antworten
Unter RFC 2308 §5, kann ein Resolver eine frühere negative Antwort zwischenspeichern. Ein neuer maßgeblicher Datensatz kann daher vorübergehend mit einer rekursiven Beobachtung fehlender Antworten koexistieren. Durch das Leeren des Cache eines Laptops wird der Resolverstatus eines externen Empfängers nicht gelöscht.
Vergleichen Sie die Autorität und relevante rekursive Beobachtungen mit Zeitstempeln. Wenn autoritative Server anderer Meinung sind, untersuchen Sie ihren veröffentlichten Status. Wenn sich internes und öffentliches DNS unterscheiden, legen Sie fest, welche Ansicht der externe Mailempfänger verwendet.
Vermeiden Sie das Versprechen, dass alle Antworten nach einer festgelegten Anzahl von Minuten übereinstimmen. Diagnostizieren Sie den tatsächlichen Pfad und den Cache-Beweis.
Korrigieren Sie den Veröffentlichungsprozess
Behandeln Sie das Ergebnis als Kontroll-Eigentümer-Problem, wenn es unklare DNS Verantwortung, aufgegebene Konten oder nicht verwaltete Delegierung offenbart. Halten Sie fest, wer Änderungen vornehmen kann, welche Zone aktiv ist und wie ein zweiter Prüfer das Ergebnis überprüft.
Eine Beobachtung fehlender Richtlinien ist ein Konfigurationsbefund. Es stellt nicht fest, dass a Phishing Kampagne erfolgreich war, dass jeder Subdomain eine Richtlinie fehlt oder dass jede empfangene Nachricht fehlschlägt DMARC. Halten Sie diese Schlussfolgerungen getrennt und sammeln Sie die jeweils erforderlichen Beweise.
Überprüfen Sie die Richtlinie und eine echte Nachricht
Bestätigen Sie nach der beabsichtigten Korrektur die entsprechende Richtliniensuche und testen Sie eine echte legitime Nachricht über den entsprechenden Dienst. Überprüfen Sie das vertrauenswürdige Authentifizierungsergebnis und Ausrichtung.
Verwenden Der Workflow zur Datensatzerstellung wann tatsächlich eine neue Police erforderlich ist. Wenn die Richtlinie sichtbar ist, die E-Mail jedoch fehlschlägt, wechseln Sie zu Ausrichtungsdiagnose. Wenn sich eine alte Anleitung und ein neuer Empfänger bei der Entdeckung unterscheiden, schließen Sie diese ein DMARCbis Bereitschaft bei der Untersuchung.
Der praktische Imbiss
Schließen Sie das Ergebnis mit dem korrigierten Veröffentlichungspfad und der daraus resultierenden verbindlichen Antwort ab. Überprüfen Sie dann die geltenden Richtlinien und eine echte legitime Nachricht. Dies hinterlässt eine reproduzierbare Diagnose anstelle eines ungeklärten Checker-Ergebnisses.
Bewahren Sie die Entscheidung und die Beweise getrennt auf
Wählen Sie für das inaktive Zonengerät die aktive Autorität als vorgeschlagenes Veröffentlichungsziel aus. Ändern Sie die Delegation nicht nur, um ein veraltetes Gremium relevant zu machen. Überprüfen Sie das Flag „Authoritative-Antwort“ und den vollständigen Antwortkontext, nicht nur den zurückgegebenen Text. RFC 8767 §4 erlaubt die qualifizierte Verwendung veralteter Antworten über den TTL-Ablauf hinaus, daher ist ein TTL keine universelle Konvergenzfrist. Es wurde keine Suche oder Konfigurationsänderung durchgeführt.