Article ID: 11152, created on Nov 1, 2013, last review on May 11, 2016

  • Applies to:
  • Plesk for Linux/Unix

症状

ドメインに 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 チェックを実施します。まず、DNS サーバに対して SPF レコードを問い合わせます。SPF レコードが定義されていない場合は 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 レコードがないため、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. 

29d1e90fd304f01e6420fbe60f66f838 a914db3fdc7a53ddcfd1b2db8f5a1b9c 56797cefb1efc9130f7c48a7d1db0f0c

Email subscription for changes to this article