Was die MX-Abfrage prüft
Das Tool liest die MX-Records der Domain und listet jeden Mailhost mit seinem Präferenzwert auf. Passen die Hostnamen zum Muster eines bekannten Anbieters, nennt es den wahrscheinlichen Anbieter. Anschließend holt es die SPF-Richtlinie aus den TXT-Records der Domain und die DMARC-Richtlinie aus _dmarc unterhalb der Domain, wertet beide aus und meldet Befunde.
Alles hier wird aus dem öffentlichen DNS gelesen. Das Tool verbindet sich nicht mit Ihrem Mailserver, verschickt keine Testnachrichten und schaut in kein Postfach.
MX-Records richtig lesen
Sendende Server versuchen zuerst den MX-Host mit der niedrigsten Präferenzzahl und gehen nur bei einem Fehlschlag zu höheren Zahlen über. Gleiche Zahlen teilen sich die Last. Das Ziel eines MX-Records muss ein Hostname sein, der zu einer Adresse auflöst. Es darf keine IP-Adresse und kein CNAME sein. Hat eine Domain gar keinen MX-Record, weichen Absender auf den A- oder AAAA-Record der Domain aus, was selten beabsichtigt ist.
Eine Domain, die niemals E-Mails empfangen soll, kann einen Null-MX veröffentlichen: einen einzelnen Record mit der Präferenz 0 und einem einzelnen Punkt als Ziel. Das weist Absender an, sofort abzubrechen, statt es tagelang erneut zu versuchen.
SPF: wer für die Domain senden darf
SPF ist ein TXT-Record, der mit v=spf1 beginnt und die Server aufführt, die die Domain in der Envelope-Absenderadresse verwenden dürfen. Die Befunde suchen nach den Fehlern, die SPF in der Praxis unbrauchbar machen: mehr als ein SPF-Eintrag, wodurch die Auswertung vollständig fehlschlägt; Mechanismen, die nach dem Auflösen der includes mehr als zehn DNS-Abfragen erfordern; der veraltete Mechanismus ptr; und ein Abschluss mit +all, der das gesamte Internet autorisiert.
Eine Richtlinie, die mit ~all endet, bittet Empfänger, andere Quellen mit Misstrauen zu behandeln, und -all bittet sie, solche Nachrichten abzulehnen. Beides ist in Verbindung mit DMARC sinnvoll. Ein Eintrag mit ?all oder ganz ohne all-Mechanismus bietet fast keinen Schutz.
DMARC: Richtlinie und Berichte
DMARC verknüpft SPF und DKIM mit der Adresse, die Menschen tatsächlich im From-Header sehen. Eine Nachricht besteht, wenn SPF oder DKIM besteht und die authentifizierte Domain zur From-Domain passt (Alignment). Der Eintrag legt fest, was Empfänger mit durchgefallenen Nachrichten tun sollen, nämlich none, quarantine oder reject, und wohin aggregierte Berichte gehen.
p=none ist der richtige Einstieg, weil Sie damit Berichte sammeln, ohne die Zustellung zu beeinflussen. Ein Ziel ist es nicht. Eine Domain, die dauerhaft bei p=none bleibt, hat Einblick, aber keinen Schutz vor Spoofing. Das Tool zeigt die Richtlinie, die Subdomain-Richtlinie, falls gesetzt, den pct-Wert und die Berichtsadressen.
Warum DKIM einen Selektor braucht
Öffentliche DKIM-Schlüssel werden unter selector._domainkey.example.com veröffentlicht, und der Selektor ist eine beliebige Bezeichnung, die das sendende System wählt. Eine Domain kann viele Selektoren haben, und das DNS bietet keine Möglichkeit, sie aufzulisten. Kein Tool kann daher einen DKIM-Schlüssel allein anhand des Domainnamens finden. Sie finden den Selektor im Header DKIM-Signature einer von der Domain gesendeten Nachricht, im Tag s=, und können diesen Namen dann per DNS-Abfrage prüfen. Ein DKIM-Schlüssel im DNS zeigt, dass DKIM eingerichtet ist, nicht dass E-Mails tatsächlich signiert werden.
Was diese Einträge nicht beweisen können
Korrekte MX-, SPF-, DKIM- und DMARC-Einträge sind für eine verlässliche Zustellung notwendig, garantieren aber nicht, dass eine Nachricht im Posteingang landet. Postfachanbieter gewichten zusätzlich die Reputation des Absenders, Beschwerderaten, Inhalte und das Verhalten der Empfänger. Nichts davon ist im DNS sichtbar. Ebenso beweist eine saubere Konfiguration nicht, dass E-Mails fließen. Sie zeigt, dass die veröffentlichte Richtlinie in sich stimmig ist, und das ist der Teil, den Sie auf der DNS-Seite beheben können.