Wie Sie überprüfen, ob für eine Domain ein korrekter SPF-Eintrag festgelegt ist

Created:

2016-11-16 12:39:09 UTC

Modified:

2017-08-16 16:29:27 UTC

43

Was this article helpful?


Have more questions?

Anfrage einreichen

Wie Sie überprüfen, ob für eine Domain ein korrekter SPF-Eintrag festgelegt ist

Applicable to:

  • Plesk for Linux/Unix

Kennzeichen

Wie überprüfe ich, ob für eine Domain ein korrekter SPF-Eintrag festgelegt ist?

Ursache

Lösung

Die einfachste Lösung ist, Online-Tools wie die nachfolgenden zu verwenden:

http://mxtoolbox.com/spf.aspx

http://www.kitterman.com/spf/validate.html

http://www.openspf.org/Tools

Zum manuellen Prüfen der Situation mithilfe der Befehlszeile müssen Sie folgende Schritte ausführen:

Versuchen Sie zuerst, mit einer von libspf2 bereitgestellten Befehlszeile eine Abfrage durchzuführen:

/usr/bin/spfquery_static -ip 12.345.67.89 -sender from@mydomain.com -rcpt-to to@mydomain.com

Bei einer korrekt eingerichteten Domain wird die Ausgabe wie folgt angezeigt (wir verwenden Google als Beispiel):

    $ /usr/bin/spfquery_static -ip 66.102.13.18 -sender from@gmail.com -rcpt-to to@gmail.com
    pass

    spfquery: domain of gmail.com designates 66.102.13.18 as permitted sender
    Received-SPF: pass (spfquery: domain of gmail.com designates 66.102.13.18 as permitted sender) client-ip=66.102.13.18; envelope-from=from@gmail.com;

Eine problematische Domain sieht mehr wie folgt aus:

$ /usr/bin/spfquery_static -ip 12.345.67.89 -sender from@mydomain.com -rcpt-to to@gmail.com
StartError
Context: Failed to query MAIL-FROM
ErrorCode: (26) DNS lookup failure
Error: Temporary DNS failure for 'mydomain.com'.
EndError
(invalid)neutral
Please see http://www.openspf.org/Why?id=from%40mydomain.com&ip=12.345.67.89&receiver=spfquery : Reason: default
spfquery: 12.345.67.89 is neither permitted nor denied by domain of mydomain.com
Received-SPF: neutral (spfquery: 12.345.67.89 is neither permitted nor denied by domain of domain.com) client-ip=12.345.67.89; envelope-from=from@mydomain.com;

Zur weiteren Analyse müssen Sie wissen, dass die SPF-Information entweder im TXT-Format oder als dedizierter SPF-Eintrag geschrieben werden kann. Letzterer wird mitunter auch als Eintrag "Typ 99" bezeichnet. Die SPF-Information muss in mindestens einem dieser Formate vorliegen. Wenn beide verwendet werden, müssen die Einträge exakte Kopien voneinander sein. Die Einträge werden vom selben DNS-Server bedient, der auch Ihren Domainnamen bedient.

Anschließend führt libspf2 eine SPF-Prüfung durch. Zuerst fragt es einen SPF-Eintrag beim DNS-Server ab. Wenn dieser nicht definiert ist, versucht es, TXT abzufragen. Schlagen beide Versuche fehl, ist dies ein Zeichen dafür, dass es kein SPF für diese Domain gibt.

Verwenden Sie das Dienstprogramm dig, um auf den Eintrag zu prüfen:

$ dig -t TXT gmail.com

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> -t TXT gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39868
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;gmail.com.                     IN      TXT

;; ANSWER SECTION:
gmail.com.              300     IN      TXT     "v=spf1 redirect=_spf.google.com"

Hier können Sie sehen, dass die Zeile, die mit v=spf1 beginnt, ein SPF-Eintrag ist. gmail.com besitzt keinen SPF-Eintrag, also erhalten Sie folgendes Ergebnis, wenn Sie eine Abfrage danach starten:

    $ dig -t SPF gmail.com

    ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> -t SPF gmail.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10846
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;gmail.com.                     IN      SPF

    ;; AUTHORITY SECTION:
    gmail.com.              1       IN      SOA     ns1.google.com. dns-admin.google.com. 1445323 21600 3600 1209600 300

Wie Sie sehen können, wird stattdessen der SOA-Eintrag zurückgegeben. Wenn wir nun die Domain mit dem genannten Problem überprüfen, sehen wir Folgendes:

$ dig -t TXT mydomain.com
; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> -t TXT mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, #14137 Unable to work with java console from SDK
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;mydomain.com.             IN      TXT

;; AUTHORITY SECTION:
mydomain.com.      1       IN      SOA     ns1.mydomain.com. ns2.mydomain.com. 2006070615 10800 3600 604800 180

Es gibt keinen TXT-Eintrag, aber alles andere ist OK. Prüfen wir nun auf SPF:

$ dig -t SPF mydomain.com

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> -t SPF mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28010
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mydomain.com.             IN      SPF

Es gibt kein SPF oder SOA. Das bedeutet, der DNS-Server behauptet, er wisse nichts über mydomain.com. Da dies der DNS-Server ist, der für den Domainnamen verantwortlich ist, gibt es nicht Weiteres, was gefragt werden könnte. Daher wird dies als DNS-Abfragefehler gewertet und libspf2 handhabt dies als solchen.

Haben Sie Fragen? Anfrage einreichen
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.