SPF: ¿quién puede enviar correo en nombre de su dominio?

Módulo 4: Registros para el correo electrónico · Tiempo de lectura: 10 minutos

Objetivo de la lección: Después de esta lección sabrá leer un registro SPF, añadir correctamente un servicio y evitar los tres errores más conocidos de SPF: dos registros, +all y más de diez consultas.

Conceptos clave: SPF, v=spf1, mecanismo (a, mx, ip4, ip6, include), calificador (+ - ~ ?), all, un único registro SPF, límite de 10 consultas DNS, remitente del sobre (Return-Path)

El problema: cualquiera puede usar su nombre

El correo electrónico se diseñó en los años ochenta para un internet pequeño y amistoso. Cualquier servidor de correo puede enviar un mensaje con el remitente info@example.com, aunque ese servidor no tenga absolutamente nada que ver con example.com. Los estafadores aprovechan esto con gusto.

SPF (Sender Policy Framework, RFC 7208) es un primer paso para evitarlo. En un registro SPF indica qué servidores pueden enviar correo en nombre de su dominio. Un servidor de correo receptor comprueba, en cada mensaje entrante: ¿proviene este correo de un servidor que está en la lista?

Piense en ello como una lista de invitados en una puerta. El portero (el servidor de correo receptor) consulta la lista de su dominio y comprueba si el visitante (el servidor que envía) figura en ella.

¿Cómo es un registro SPF?

Un registro SPF es un registro TXT en su dominio que empieza con v=spf1:

example.com.  3600  IN  TXT  "v=spf1 mx ip4:192.0.2.25 include:spf.mailer.example ~all"

Se lee de izquierda a derecha. El receptor recorre los elementos uno por uno y se detiene en el primero que coincide.

El final: ~all, -all, ?all o +all

Cada elemento puede llevar delante un símbolo que indica qué ocurre si coincide. En el caso de all (que siempre coincide), ese símbolo marca la diferencia:

Si no hay ningún símbolo, se aplica +. Por tanto, mx significa +mx.

¿Cuál elegir? ~all es una opción predeterminada segura. -all es más estricta y resulta adecuada si tiene la certeza de que todos sus remitentes figuran en el registro. Si utiliza DMARC (lección 4.5), la política de DMARC determina finalmente qué ocurre; muchos administradores optan entonces por ~all.

Error 1: dos registros SPF

Solo puede haber un registro SPF por dominio. Si el receptor encuentra dos, el resultado es un error (permerror) y su SPF no cuenta en absoluto. Eso es peor que no tener SPF.

Esto suele ir mal en la práctica. Un servicio de boletines o Microsoft 365 dice "añada este registro SPF", y de repente aparece un segundo registro v=spf1 junto al antiguo. La solución: añada el nuevo servicio al registro existente.

Incorrecto:

"v=spf1 mx include:spf.oldhost.example ~all"
"v=spf1 include:spf.protection.outlook.com -all"

Correcto:

"v=spf1 mx include:spf.oldhost.example include:spf.protection.outlook.com ~all"

Tenga en cuenta que, al combinarlos, no debe eliminar los servidores que todavía utiliza. Si su sitio web envía correo a través del servidor de su proveedor de hosting, este debe permanecer en el registro, aunque su correo habitual vaya a Microsoft 365. Un paquete de hosting suele tener ya un SPF predeterminado con un include del proveedor de hosting (en WebOké, por ejemplo, es include:webawere.nl); déjelo mientras su sitio web o sus formularios envíen correo a través de ese servidor.

Error 2: +all o un registro demasiado amplio

+all al final, o un rango enorme como ip4:0.0.0.0/0, significa que todo el mundo está permitido. En ese caso su SPF deja de proteger nada, y los filtros antispam lo interpretan como una mala señal.

Error 3: más de diez consultas

Para comprobar un registro SPF, el receptor a veces debe realizar consultas DNS adicionales. Cada include, a, mx, exists, ptr y redirect cuesta una consulta, y un include también suma todas las consultas del registro al que hace referencia. Según la RFC 7208, el total no puede superar diez. Si se supera, el resultado es permerror y SPF falla.

ip4 e ip6 no cuestan ninguna consulta. all tampoco.

Además, como máximo dos consultas pueden volver "vacías" (un nombre que no existe o que no tiene respuesta). Por tanto, un include hacia un servicio que ya no utiliza desde hace tiempo y que ha eliminado su registro también puede causar problemas.

Si utiliza muchos servicios, cuente las consultas con una herramienta de comprobación de SPF (lección 8.3) y elimine los servicios que ya no utiliza.

Lo que SPF no hace

SPF comprueba el remitente del sobre: la dirección técnica del remitente (Return-Path) que los servidores de correo utilizan entre sí. Esta no es siempre la misma dirección que el campo "De:" que usted ve en su programa de correo. Un servicio de boletines suele enviar con su propio Return-Path. Por tanto, SPF por sí solo no detiene todos los remitentes falsificados. Para eso están DKIM (lección 4.4) y DMARC (lección 4.5).

SPF también falla al redirigir: si reenvía automáticamente el correo a otra dirección, este llega al destinatario final desde un servidor que no figura en su SPF.

Por qué es importante

Los grandes proveedores de correo se han vuelto más estrictos. Desde febrero de 2024, Gmail y Yahoo exigen que cualquiera que envíe correo tenga al menos SPF o DKIM, y que quien envíe mucho correo (más de unos 5.000 al día) tenga SPF, DKIM y DMARC. Microsoft impone el mismo requisito desde mayo de 2025 para Outlook.com, Hotmail y Live.com. Incluso si envía poco correo, un buen registro SPF ayuda a evitar la carpeta de spam.

En la práctica: así se ve en un panel

En este ejemplo utilizamos DirectAdmin. En Administración de DNS, haga clic en el lápiz situado junto al registro TXT que empieza por v=spf1. DirectAdmin abre un asistente de SPF: en Incluir Dominio introduce el dominio del servicio (sin include:), en Modo elige SoftFail (~all) o Falla (-all). Abajo verá el registro completo. Mi WebOké dispone de un asistente de SPF similar en la pestaña DNS.

Otros paneles no siempre tienen un asistente así. En ese caso, edite el registro TXT como texto normal; el contenido es exactamente el mismo.

Resumen

• SPF es un registro TXT con v=spf1 que indica qué servidores pueden enviar correo en nombre de su dominio.
• Exactamente un registro SPF por dominio. ¿Un servicio nuevo? Amplíe el registro existente.
• Termine con ~all o -all, nunca con +all.
• Máximo diez consultas DNS (include, a, mx, exists, ptr, redirect); ip4/ip6 no cuentan.
• SPF se fija en el remitente del sobre; para una protección real también necesita DKIM y DMARC.

Cuestionario

Ejercicio

Ejercicio Z4.3: buscar un registro SPF. Busque el registro SPF de google.com (o de su propio dominio). Pegue el registro completo e indique con qué termina (~all, -all, ?all o +all). En el caso de su propio dominio, el ejercicio también comprueba si tiene exactamente un único registro SPF.

Ejercicio O4.3: configurarlo usted mismo en su zona de práctica. En la zona de práctica utiliza un servicio ficticio; en su dominio real utilizará el include auténtico que le indique su proveedor de correo (por ejemplo, include:_spf.google.com). Cree en su zona de práctica <code>.dnspractice.eu un registro SPF que permita lo siguiente: los servidores MX de la zona (mx), la dirección 192.0.2.25 y el servicio de práctica _spf.mailsuite-demo.dnspractice.eu. Los demás servidores son sospechosos o no están permitidos, por lo que el registro termina en ~all o -all.

Para saber más

Los pasos de estos artículos corresponden a los paneles de WebOké; en otros paneles el funcionamiento es similar.

• Manual de DirectAdmin 5.7: Configurar y ampliar el SPF
• ¿Cómo funciona el registro SPF en el DNS?
• Añadir o modificar un registro SPF en DirectAdmin
• Manual de WebOké 5.5: Asistentes DNS: MX, SPF, DMARC, CAA y SRV
• RFC 7208 (SPF), en concreto el apartado 4.6.4 (límite de diez consultas y dos consultas vacías)