Stellen Sie zwei verschiedene DNS Fragen
Eine MX Prüfung fragt, wohin an eine Domain adressierte E-Mails zugestellt werden sollen. Eine Reverse-DNS-Prüfung fragt, welcher Hostname mit einer IP-Adresse verknüpft ist, und fragt anschließend, ob dieser Hostname wieder in die entsprechende Adresse aufgelöst wird. Keine der Fragen misst die Reputation des Absenders oder beweist die Authentifizierung der Nachricht. Durch die Trennung wird ein häufiger Fehler vermieden: Das Inbound-Gateway einer Domäne wird überprüft und davon ausgegangen, dass es sich auch um den Server handelt, der seine Anwendungsmails sendet.
Dies ist ein Interpretationsleitfaden mit einer bewusst fiktiven DNS Fixierung, kein funktionierender Prüfer oder ein Live-Domain-Bericht. Es wurde keine Suche oder SMTP Verbindung ausgeführt. Ein implementierter Prüfer würde explizite Eingaben, aufgezeichnete Beobachtungen, Tests auf erwartete Ergebnisse und Erklärungen für unvollständige Antworten benötigen, bevor seine Ausgabe eine operative Entscheidung unterstützen könnte.
Interpretieren Sie die Empfangsroute über MX
Ein MX Ressourceneintrag enthält einen Präferenzwert und einen Exchange-Hostnamen. Niedrigere Präferenzwerte werden vor höheren ausprobiert; Es handelt sich nicht um Prozentsätze oder um eine Garantie dafür, dass ein bestimmter Server eine Nachricht akzeptiert. RFC 1035 definiert den Datensatz und RFC 5321 erklärt SMTP Zielauswahl. Bewahren Sie alles Relevante auf MX Eintrag und die Adressauflösungsergebnisse für seine Ziele.
Unterscheiden Sie einen nutzbaren Empfangsweg von einer bloßen Antwort. Ein MX Ziel benötigt entsprechende Adressdatensätze; ein Ziel, das als dargestellt wird CNAME ist gemäß den SMTP -Zielauflösungsregeln kein gültiger Ersatz. Eine nicht erreichbare Adresse, ein vorübergehender DNS Fehler oder ein nicht verfügbarer SMTP Dienst erfordern eine andere Erklärung als ein fehlerhafter MX . Schließen Sie die Transportverfügbarkeit nicht allein aus DNS ab.
Keine MX Antwort bedeutet nicht immer, dass eine Domain keine E-Mails empfangen kann. SMTP kann unter den Bedingungen in RFC 5321 einen impliziten MX verwenden RFC 7505 definiert einen expliziten Null- MX : Präferenz Null mit dem Root-Namen als Austausch. Ein Null MX gibt an, dass kein Dienst empfangen wird und darf nicht mit anderen MX Einträgen koexistieren. Halten Sie diesen beabsichtigten Zustand von fehlenden Daten und einer fehlerhaften Empfangskonfiguration fern.
Starten Sie Reverse DNS von der tatsächlichen Absenderadresse
Identifizieren Sie die öffentliche IP-Adresse, die für die untersuchte Nachricht mit dem Empfänger verbunden ist. Die Website-Adresse, die eingehende MX -Adresse und die ausgehende Serviceadresse eines Unternehmens können unterschiedlich sein. Bei einer ausgelagerten Plattform kann der jeweilige Reverse-DNS-Besitzer der Dienst- oder IP-Space-Betreiber sein und nicht die Organisation, die die sichtbare From-Domäne kontrolliert.
Überprüfen Sie die PTR Antwort für diese Adresse und lösen Sie dann ihren Hostnamen in der entsprechenden Adressfamilie auf. Für die persönliche Gmail Zustellung: Googles Absender-Anleitung erfordert, dass die öffentliche IP des sendenden Servers über übereinstimmende Reverse- und Forward DNS verfügt. Dabei handelt es sich um eine empfängerspezifische veröffentlichte Anleitung und nicht um eine Garantie für die Akzeptanz durch Gmail oder andere Anbieter. Notieren Sie die überprüfte IP und den Hostnamen, damit ein anderer Bediener die Beziehung reproduzieren kann.
Ein PTR Hostname muss nicht als sichtbare Absenderdomäne interpretiert werden, a DKIM Unterzeichner oder Nachweis, dass die Organisation die Nachricht autorisiert hat. Diese Identitäten dienen unterschiedlichen Zwecken. SPF wertet die angegebene Umschlagidentität und -quelle aus, während DMARC hängt von ausgerichteten authentifizierten Identifikatoren ab. Eine erfolgreiche Vorwärts- und Rückwärtsübereinstimmung kann keine der beiden Bewertungen ersetzen.
Lesen Sie eine minimale fiktive Veranstaltung
Angenommen, die erfundene Domäne inbound.example verfügt über einen MX Eintrag mit der Präferenz 10, der auf mx.inbound.example zeigt, dessen Ein Rekord ist 192.0.2.10 . Die erwartete Antwort auf die vorgeschlagene MX Abfrage identifiziert diesen Austausch; Die erwartete A-Antwort liefert ihre Empfangsadresse. Bei diesen Dokumentationsnamen und -adressen handelt es sich um eine erstellte Ergänzung, nicht um eine erfasste Ausgabe. Die dargestellte Abhängigkeit ist das eingehende SMTP Routing für Empfänger unter inbound.example .
Angenommen, ein erfundener Outbound-Server verwendet 192.0.2.25 . Die erwartete PTR Antwort für 25.2.0.192.in -addr.arpa verweist auf outbound.example und die erwartete A-Antwort für outbound.example enthält 192.0.2.25 . Dies veranschaulicht eine vorwärtsbestätigte Reverse-DNS-Beziehung für diese Absenderadresse. Es begründet keine MX Beziehung, keinen positiven Ruf oder keine erfolgreiche Lieferung.
Eine Implementierung sollte auch einen PTR testen, der auf einen Hostnamen zeigt, dessen Weiterleitungsantwort die ursprüngliche Adresse, einen Null MX , einen impliziten MX-Fall und einen vorübergehenden Resolverfehler auslässt. Geben Sie das gewünschte Ergebnis an, bevor Sie jedes Gerät ausführen. Ändern Sie nicht einen echten PTR oder MX , nur um eine Diagnoseanzeige grün erscheinen zu lassen.
Bewahren Sie Fehler statt Herstellungssicherheit
Speichern Sie den genauen Abfragenamen, Typ, Server oder Resolver, Beobachtungszeit, Antwortstatus und relevante Abschnitte. Eine leere Antwort kann mit einem Pseudonym, einer Empfehlung oder einer negativen Antwort einhergehen. RFC 2308 erklärt Unterscheidungen, die ein Prüfer beibehalten muss. Eine Zeitüberschreitung oder SERVFAIL können nicht als Beweis dafür, dass kein Datensatz vorhanden ist, umgekennzeichnet werden. Zwischengespeicherte und maßgebliche Antworten können unterschiedlich sein, ohne dass es sich dabei um eine Abschrift dessen handelt, was ein früherer Empfänger gesehen hat.
Melden Sie Routing-Ergebnisse, Reverse-DNS-Konsistenz, Authentifizierung und Reputation als separate Dimensionen. Wenn ein Anbieter eine Nachricht ablehnt, bewahren Sie neben dem DNS Beweis auch die vollständige Diagnose, den Zeitstempel und die Route auf. A Blockliste Ergebnis, ein SPF Ein Ausfall und eine MX Fehlkonfiguration erfordern unterschiedliche Eigentümer und Abhilfemaßnahmen. DNS Konformität kann ein Hindernis beseitigen, während Beschwerden, Inhalte, kompromittierte Konten oder Empfängerrichtlinien weiterhin die Zustellung beeinträchtigen.
Definieren Sie das Nutzergebnis und das verbleibende Tor
Eine vertrauenswürdige Ausgabe benennt die getestete Abhängigkeit, die sie unterstützende Beobachtung und den nächsten genehmigten Überprüfungsschritt. Bei einem Problem mit der eingehenden Route kann dies bedeuten, dass der beabsichtigte Austausch mit dem E-Mail-Betreiber bestätigt werden muss. Für Reverse DNS, kann dies bedeuten, dass der Eigentümer des Adressraums gebeten wird, die beobachtete Nichtübereinstimmung zu überprüfen. Keiner der Schritte autorisiert die Veröffentlichung von Änderungen oder den automatischen Versand von Test-Mails.
Die genaue Anforderung an den Originalnachweis bleibt offen: Ein minimales DNS Beispiel mit der erwarteten Abfrageantwort und der spezifischen E-Mail-Abhängigkeit, die es unterstützt. Das fiktive Spiel liefert einen illustrativen Entwurf, kein ausgeführtes Abnahmeergebnis. Auch die separate Aufnahme erfordert die Umsetzung und Erprobung der versprochenen Funktion. Behalten Sie das Leitfadenetikett der Seite bei und stellen Sie sie nicht als Diagnosedienst dar, bis tatsächliche Beobachtungen und Arbeitsprüfbeweise vorliegen.