Как проверить правильно ли настроена запись SPF для домена?

Создана:

2016-11-16 12:39:09 UTC

Изменена:

2017-08-23 02:20:55 UTC

43

Помогла ли вам статья?


Есть вопросы?

Отправить запрос

Как проверить правильно ли настроена запись SPF для домена?

Applicable to:

  • Plesk for Linux

Симптомы

Как проверить правильно ли настроена запись SPF для домена?

Решение

Самым простым решением будет воспользоваться одним из приведенных ниже онлайн-инструментов:

http://mxtoolbox.com/spf.aspx

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

http://www.openspf.org/Tools

Для проверки вручную через командную строку, воспользуйтесь следующими инструкциями:

Попробуйте выполнить запрос в командной строке libspf2:

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

При правильно настроенном домене вы увидите такой ответ (для примера взяли Google):

    $ /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;

Ответ для домена с проблемами будет похож на этот:

$ /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;

Чтобы продолжить исследование проблемы, вам необходимо знать, что информация SPF может быть записана в формате TXT или в виде выделенной записи SPF. Последнюю иногда еще называют записью "type99". Информация SPF должна быть по крайней мере в одном из этих форматов. Если используются оба, то такие записи должны быть точными копиями друг друга. Эти записи обслуживаются тем же сервером DNS, что и ваше доменное имя.

Затем libspf2 выполняет проверку SPF. Сначала он запрашивает запись SPF у сервера DNS. Если она не определена, он пытается запросить TXT. Если обе попытки неудачные, это означает, что для этого домена нет информации SPF.

Чтобы проверить запись, воспользуйтесь утилитой dig:

$ 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"

Как вы можете здесь увидеть, строка, начинающаяся с v=spf1 , является записью SPF. Для gmail.com не существует записи SPF, поэтому при запросе вы получите следующий результат:

    $ 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

Как видите, вместо нее возвращается запись SOA. Теперь, если мы проверим проблемный домен, то увидим следующее:

$ 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

Для него не существует записи TXT, но все остальное в порядке. Давайте проверим 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



There is no SPF or SOA. This means that the DNS server is claiming it knows nothing about mydomain.com. Since this is the DNS server that is responsible for the domain name, there is no one else to ask. Therefore, it is considered a DNS query error, and libspf2 handles it as such.
Была ли эта статья полезной?
Пользователи, считающие этот материал полезным: 43 из 135
Еще есть вопросы? Отправить запрос
Войдите в службу, чтобы оставить комментарий.