Cómo verificar si un dominio tiene configurado correctamente un registro SPF

Created:

2016-11-16 12:39:09 UTC

Modified:

2017-08-16 16:29:27 UTC

43

Was this article helpful?


Have more questions?

Enviar una solicitud

Cómo verificar si un dominio tiene configurado correctamente un registro SPF

Applicable to:

  • Plesk for Linux

Resolución

La forma más fácil de realizar esta comprobación es utilizar herramientas online como las siguientes:

http://mxtoolbox.com/spf.aspx

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

http://www.openspf.org/Tools

Para efectuar la comprobación de forma manual mediante la línea de comandos, realice los pasos detallados a continuación.

En primer lugar, intente realizar la consulta con una línea de comando proporcionada por libspf2:

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

Un dominio configurado correctamente imprimirá algo parecido a lo siguiente (usando Google como ejemplo):

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

Un dominio que experimente problemas tendrá una apariencia más parecida a la siguiente:

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

El siguiente paso en la investigación será cerciorarse de que los datos SPF pueden escribirse en formato TXT o como un registro SPF dedicado. A veces, esta última opción se denomina registro "type99". Los datos SPF deben estar en al menos uno de estos formatos. De usarse ambos formatos, los registros deben ser copias exactas. Dichos registros son servidos por el mismo servidor DNS que sirve su nombre de dominio.

A continuación, libspf2 efectúa una verificación SPF. En primer lugar solicita al servidor DNS un registro SPF. De no estar definido, este intenta solicitar un registro TXT. Si ambos intentos resultan fallidos, esto significa que no existe ningún registro SPF para el dominio en cuestión.

Para localizar el registro, use la utilidad 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"

Como puede ver, la línea que empieza por v=spf1 es un registro SPF. gmail.com no tiene ningún registro SPF, por lo que si lo solicita obtendrá lo siguiente:

    $ 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

Como puede ver, en su lugar se devuelve el registro SOA. Ahora, si examina el dominio que experimentaba el problema verá lo siguiente:

$ 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

Si bien no existe ningún registro TXT, todo es correcto. Localicemos el registro 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.
¿Tiene más preguntas? Enviar una solicitud
Inicie sesión para dejar un comentario.