SPF, o Sender Policy Framework, es un estándar usado para verificar que los correos electrónicos enviados desde un determinado dominio, proceden de servidores de correo autorizados para dicho dominio.
Es decir, con telnet (u otros métodos), podríamos enviar un mail usando cualquier dirección de correo electrónico como origen. Así por ejemplo, yo podría enviar un mail haciéndome pasar por [email protected], o [email protected]. Aquí (y en muchos otros sitios) explican cómo.
El registro SPF, pues, sirve para ayudar a determinar a un servidor de correo, si el mail que acaba de recibir ha de descartarse o entregarse en el inbox.
¿Cómo se configura un registro SPF?
En primer lugar, deberemos crear un registro del tipo TXT para el dominio desde el que quieres enviar mails. Si quieres enviar desde @midominio.com deberás crear una entrada del estilo:
nombre: midominio.com tipo: TXT valor: "v=spf1 ip4:80.80.80.0/24 ip4:90.90.90.0/24 ip6:aaaa:aaaa:aa::/48 ?include:_spf.google.com +a +mx ~all"
Vamos a explicar un poco qué es todo ésto que aparece en el valor del registro del ejemplo:
- El valor del SPF empieza con «v=spf1» que no es más que la etiqueta que identifica a este registro como un SPF. Así pues, todo SPF ha de tenerlo.
- En el ejemplo, a continuación, se muestran dos rangos de direcciones IPv4 mediante «ip4:80.80.80.0/24 ip4:90.90.90.0/24» y otro IPv6 mediante «ip6:aaaa:aaaa:aa::/48». Con ésto estaremos diciendo que cualquier mail enviado desde una IP de este rango, que tenga en el MAIL FROM una dirección @midominio.com deberá devolver un «pass» en el chequeo del SPF.
- A continuación, en el ejemplo he añadido un «include«, que básicamente sirve para aceptar las IPs definidas en otro SPF de otro dominio, como IPs válidas para enviar desde mi dominio. En este caso, hemos incluido el SPF de Google, así que podremos enviar mails mediante Google con nuestro dominio @midominio.com. Hay que tener en cuenta un par de consideraciones:
- Si el SPF incluído no es válido, nuestro SPF tampoco lo será, y devolverá un «Permanent Error», lo cual puede perjudicar en mucho nuestras entregas.
- En la documentación de OpenSPF se recomienda que los includes devuelvan un «neutral» en lugar de un «pass», ya que como en realidad puede pasar que la gestión del registro DNS del dominio que estamos incluyendo no la tengamos nosotros, si ese registro DNS resulta comprometido, podrían enviarse mails no autorizados con nuestro dominio. El «?» sirve para indicar que las IPs del include deberán dar un «neutral» en el test del SPF.
- Se suele poner «+a +mx» en los SPF, aunque hemos de ir con cuidado. Básicamente estamos indicando que la IP que devuelve el registro «A» de midominio.com, así como los MX, son IPs autorizadas. El «+» sirve para, explícitamente indicar que estas IPs darán un «pass» en el test del SPF. Los «calificadores» que podríamos haber usado son los siguientes, aunque si no usas ninguno, por defecto estarás devolviendo un «pass»:
- «+» Pass
- «-» Fail
- «~» SoftFail
- «?» Neutral
- Finalmente, el valor «~all» estará indicando, que el resto de IPs no indicadas en este SPF, si envían desde @midominio.com, darán un «SoftFail» en el test del SPF. Aquí podríamos querer usar un «-all» para que directamente, toda IP que no hayamos especificado en nuestro SPF de un «Fail» si intenta enviar haciéndose pasar por nosotros.
NOTA: Quizá hayas oído que existe un registro del tipo SPF y que es necesario (o mejor) configurar el SPF tanto en el registro TXT como en el propio registro SPF. Cierto, aunque al parecer ya no se recomienda el uso de registros del tipo SPF para configurar el SPF. En su lugar se recomienda usar únicamente el de tipo TXT, tal y como acabamos de explicar.
Too many DNS lookups
En alguna ocasión te puedes encontrar con que un SPF devuelve este error permanente. Hay un límite de 10 resoluciones DNS para un registro SPF. Esto significa que en nuestro ejemplo, tendríamos las siguientes resoluciones DNS:
- El propio registro TXT «midominio.com», que nos devolverá el valor del SPF.
- La resolución del registro «A» que hemos incluído como «+a»
- LA resolución del registro «MX» que hemos incluído como «+mx». Aunque esta resolución nos devuelva 4 o 5 MX diferentes, sólo cuenta como una única resolución DNS.
- El include de «_spf.google.com» cuenta como otra resolución, pues hemos de conocer los valores de este nuevo SPF.
- Cualquier otra resolución dentro de un include cuenta como una resolución extra. En este caso el valor de _spf.google.com contiene a su vez, otros 3 includes, así que sumaríamos 3 resoluciones DNS más, llegando a 7, tal y como se muestra a continuación. Si el SPF de Google tuviera un «+a» o un «mx», también deberían contarse estas otras resoluciones.
_spf.google.com text = "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
- De nuevo, deberíamos ver el valor de cada uno de los nuevos includes que tiene el SPF de Google, para continuar sumando resoluciones DNS. En este caso, todos los includes del SPF de Google devuelven «ip4» o «ip6», que no cuentan como resoluciones DNS pues directamente son IPs.
En este ejemplo, pues, estaríamos cumpliendo el límite de resoluciones DNS. Si tienes errores de este estilo, prueba a usar la herramienta de validación de SPF de emailstuff. Aquí tienes otro ejemplo sacado de StackOverflow.
Void lookup limit of 2 exceeded
Otro error que nos podemos encontrar, es cuando nuestro SPF tiene más de 2 resoluciones DNS que devuelven vacío. Es decir, si nosotros ponemos en nuestro SPF un «+a +mx» pero nuestro dominio no tiene un registro del tipo A, ni uno (o más de uno) del tipo MX, entonces estará devolviendo 2 errores de registro vacío. Si superamos este límite de 2, nuestro SPF devolverá un error permanente.
Herramientas útiles
Además de nslookup y dig, tenemos algunas herramientas online muy útiles:
- Validador de SPF de Kitterman, recomendado por OpenSPF.
- Validador de emailstuff, ideal para contar resoluciones DNS.
- Herramienta de ayuda de Google Apps, perfecto cuando tu dominio está con Google Apps.
Fuentes:
http://www.openspf.org/SPF_Record_Syntax
https://wordtothewise.com/2013/07/spf-fail-too-many-dns-lookups/
Foto por Pacdog
Excelente post Adrian¡¡¡, muy bien explicado. Quisiera realizarte una consulta… entiendo que cuando se envia un correo, esta verificacion de SPF, osea los servidores autorizados para enviar correo de nuestro dominio, se realiza en el destino, osea lo realiza en primera instanacia el AntiSpam de la organizacion (de tenerlo claro)verdad? o el flujo es otra manera?. De antemano muchas gracias por tu respuesta.
¡Hola Martin!
Gracias por comentar.
La verificación la realiza, como tu dices, el servidor de destino.
Aprovecho para comentar que port25 tiene una herramienta muy útil para verificar el estado de varias medidas antispam (spf, dkim, rdns, etc.). Funciona muy bien y te da una idea de lo que puedes mejorar, de un sólo vistazo:
https://www.port25.com/support/authentication-center/email-verification/
Salud,
Adri
Hola Adrian!
Si tengo un dominio como el que usas, midominio.com, y a su vez tengo otro subdominio de ese mismo dominio, por ejemplo otro.midominio.com. Los SPF records para midominio.com son usados tambien para otro.midominio.com ya que este es un subdominio? O necesito declarar un record SPF para cada dominio/subdominio? Gracias de antemano por tu respuesta.
Hola Julio,
Debes crear un SPF para cada dominio/subdominio de envío, pues cada uno puede tener a su vez características diferentes (usar servidores de envío diferentes, etc.).
Más info: http://www.openspf.org/FAQ/The_demon_question
Salud
Gracias Adrian,
Justo lo que necesitaba entender. Leere las FAQs para conocer mas. Gracias y saludos!
Buenas Adrian exelente explicacion, pero tengo un problema el cual no pude resolver con lo que expusite anteriormente y es sobre el error «Void lookup limit of 2 exceeded» es el unico problema que me da cuando hago el test con las herramientas que dejaste al final a continuacion te envio mi configuracion a ver si me puedes ayudar gracias de antemano y saludos.
$TTL 1h ; 1 hour
@ IN SOA ns.ejemplo.co. hostmaster.ejemplo.co. (
2009020205
1h
15m
1w
1h )
; DNS Servers
IN NS ns.ejemplo.co.
IN NS ns2.ejemplo.co.
IN NS x.ejemplo.co.
; MX Records
IN MX 5 ns2.ejemplo.co.
IN MX 10 ns.ejemplo.co.
; IN MX 20 mail.example.org.
IN A 1.1.1.3
IN A 1.1.1.4
; SPF Record for ejemplo.co
ejemplo.co. IN TXT «v=spf1 mx mx:ns.ejemplo.co mx:ns2.ejemplo.co ip4:1.1.1.3 ip4:1.1.1.4 -all»
; Machine Names
ns IN A 1.1.1.3
ns2 IN A 1.1.1.4
x2 IN A 1.1.1.11
x IN A 1.1.1.2
mirror IN A 1.1.1.14
; SPF records specific to machines
ns.ejemplo.co. IN TXT «v=spf1 mx mx:ns.ejemplo.co mx:ns2.ejemplo.co ip4:1.1.1.3 ip4:1.1.1.4 -all»
; Aliases
www IN CNAME @
; Wildcard SPF record for all subdomains
*.ejemplo.co. IN TXT «v=spf1 mx mx:ns.ejemplo.co mx:ns2.ejemplo.co ip4:1.1.1.3 ip4:1.1.1.4 -all»
; Wildcard MX Records for all subdomains
* IN MX 5 ns2.ejemplo.co.
* IN MX 10 ns.ejemplo.co.
; Wildcard A Records for all subdomains
* IN A 1.1.1.3
;
;
Hola @Frank
Me alegro que hayas encontrado útil la entrada.
Si te devuelve ese error, por favor, usa «dig» , «nslookup» o cualquier herramienta de resolución de registros DNS para verificar que existan todas las entradas DNS que está usando tu SPF.
Si has creado hace poco el MX, por ejemplo, dale tiempo a que se propague y vuelve a realizar el test pasadas 24-48h.
Al final, el error que te devuelve, indica que tu SPF usa por lo menos 2 registros DNS que no existen o no se pueden resolver.
¡Suerte!
Gracias adrian por responderme tan rapidamente, te enviaba mi configuracion porque me llego una alerta de que mi dominio tenia vulnerabilidades y me decian que no tenia configurado registro spf, pero he revisado muchisimos articulos en internet y he hecho pruebas con herramientas en internet y el unico warning que me daba era el error que te comentaba, el problema que esta alerta me la manda la oficina encargada de la seguridad informatica de mi pais y queria saber si encuentras en la configuracion que te mande algun problema con el registro spf. Saludos y gracias
Hola Frank,
La verdad que al ser un SPF con valores «no reales» es un poco difícil de decir 🙂
Por eso te comentaba de revisar, uno a uno, los registros que usan tus SPF, con nslookup, dig o similares, para confirmar que en efecto todos los registros se puedan resolver y tengan un valor. Eso tendrías que hacerlo tú, que tienes los datos.
Por ejemplo, para el siguiente SPF:
ejemplo.co. IN TXT “v=spf1 mx mx:ns.ejemplo.co mx:ns2.ejemplo.co ip4:1.1.1.3 ip4:1.1.1.4 -all
Asegúrate de que el mx de ejemplo.co tenga valor y se pueda resolver.
Lo mismo para los mx ns.ejemplo.co y ns2.ejemplo.co, que a priori suenan a culpables (por tener como subdominio «ns» cuando en realidad son «mx»)
El resto son 2 IPv4, así que no debería haber problema con ellas.
Si tras revisarlo, continúan los problemas, te recomendaría, si puedes, que modifiques el SPF y lo dejes con lo mínimo (v=spf1 mx -all), valides, y si pasa el test, añadas un registro (v=spf1 mx mx:ns.ejemplo.co -all), vuelvas a validar, y así con el resto, hasta dar con los culpables.
¡Suerte!
Muchas gracias adrian por la respuesta, voy a hacer lo que me recomendaste, te comento que la configuracion que te mande es exactamente igual que la que tengo lo que cambie el nombre del dominio y las ip, tambien los mismos servidores funcionan como dns y mx para el dominio (ns.ejemplo.co y ns2.ejemplo.co) es decir ambos estan en mi dmz ellos los tengo resgistrados como mis dns oficiales de mi dominio en internet. Muchisimas gracias por la ayuda lo que necesite me puede escribir. Saludos
Hola Adrián, mi pregunta es la siguiente:
Qué sucedería si tengo la siguiente situación…..
serverinterno.redlolo.pe —- envía correos a ——— serverrelay.lolo.com —– y este a su vez distribuye los emails.
A la hora de validar el registro SPF que debería poner? La situación es que si implemento
v=spf1 serverrelay.lolo.com -all no me entran los correos al ——serverinterno.redlolo.pe
Sldos