Article ID: 11152, created on Mar 22, 2011, last review on May 11, 2014

  • Applies to:
  • Plesk for Linux/Unix

Informations supplémentaires

AuuTout d'abord, essayez de demander avec une ligne de commande fournie par libspf2 :
/usr/bin/spfquery_static -ip 12.345.67.89 -sender from@mydomain.com -rcpt-to to@mydomain.com

Configurez correctement le domaine pour qu'il soit imprimé comme ceci (à l'aide de google par exemple) :
$ /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;

Une situation problématique ressemble à ceci :
$ /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;

Pour continuer l'investigation, vous devez savoir que les informations SPF peuvent être écrits en TXT ou un enregistrement SPF dédié. Ce dernier est également appelé enregistrement  type99. Il doit s'agir d'au moins l'un des deux. Si les deux sont utilisés, ils peuvent être des copies exactes l'une de l'autre. Ces enregistrements sont servis par le même serveur DNS qui sert votre nom de domaine.

Puis libspf2 exécute une vérification SPF. Tout d'abord, il demande au serveur DNS un enregistrement SPF. S'il n'est pas défini, il essaye de demander le TXT. Si les deux échouent, cela signifie qu'il n'y a pas de SPF pour ce domaine.

Pour vérifier cet enregistrement, utiliser l'utilitaire 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"

Comme vous pouvez le voir, la ligne commençant par v=spf1 est un enregistrement SPF. gmail.com n'a pas d'enregistrement SPF. Si vous le demandez, vous obtiendrez :
$ 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

Comme vous pouvez le voir, l'enregistrement SOA est renvoyé à la place. Maintenant, nous pouvons voir le domaine problématique :
$ 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

Aucun enregistrement TXT mais le reste est OK. Vérifions pour le 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

Aucun SPF, aucun SOA. Cela signifie que le serveur DNS prétend ne rien savoir sur mydomain.com. Comme c'est le serveur DNS qui est reponsable du nom de domaine, c'est à lui et à lui seul que vous devez le demande. cit est donc considéré comme une erreur de requête DNS et libspf2 agit en tant que tel.

29d1e90fd304f01e6420fbe60f66f838 a914db3fdc7a53ddcfd1b2db8f5a1b9c 56797cefb1efc9130f7c48a7d1db0f0c

Email subscription for changes to this article
Save as PDF