Saltar al contenido

Aprende

SPF, DKIM y DMARC, un registro cada vez

Tres registros en el DNS de tu dominio le demuestran al mundo que tu correo es realmente tuyo. Esto es lo que hace cada uno, en qué orden configurarlos y cómo endurecer DMARC sin perder correo legítimo.

Por qué un servidor de correo pide pruebas

Cualquiera puede escribir cualquier dirección en el campo De de un correo. La RFC 7208, el estándar detrás de SPF, empieza diciendo que el correo se puede falsificar de varias maneras. Así que un servidor que recibe un mensaje no puede creerlo sin más. Busca la prueba en el DNS del dominio del que el mensaje dice venir.

El DNS es una lista pública de datos sobre un dominio, y cualquier servidor puede leerla. Cada entrada de esa lista es un registro DNS. Tres registros importan para el correo, y cada uno responde a una pregunta distinta:

SPF
¿El servidor que envió este mensaje está en la lista de remitentes permitidos del dominio?
DKIM
¿El mensaje lleva una firma del dominio? Google dice que los servidores receptores usan DKIM para comprobar que el propietario del dominio realmente envió el mensaje.
DMARC
¿Qué debe hacer quien recibe cuando esas comprobaciones fallan? Google dice que DMARC indica a los servidores receptores qué hacer con los mensajes que no pasan SPF ni DKIM.

SPF: quién puede enviar por tu dominio

Un registro SPF es una línea de texto en el DNS de tu dominio. Enumera los servidores que pueden enviar correo por ese dominio. Google dice que, cuando llega un mensaje, los servidores receptores comprueban el registro SPF para confirmar que el mensaje vino de servidores autorizados.

Este es el registro que da Google a un dominio que envía solo por Google Workspace. El tuyo enumerará a tu propio proveedor.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
v=spf1
Todo registro SPF empieza con esta etiqueta.
include:
Añade la lista de servidores de otro remitente. La página de Google indica ponerlo delante de cada dominio de remitente en tu registro.
~all
Es el último término. Siempre coincide, así que fija el valor por defecto para todo servidor que no está en la lista. La tilde convierte ese valor en un softfail, que la RFC 7208 describe como una afirmación débil de que el host probablemente no está autorizado. Google recomienda este final.
-all
Lo mismo, pero el resultado es un fail, que la RFC describe como una declaración explícita de que el cliente no está autorizado. Úsalo solo cuando estés seguro de que la lista está completa.

Dos límites sorprenden a mucha gente.

DKIM: una firma en cada mensaje

DKIM pone una firma en cada mensaje. Quien envía tu correo la hace con una clave privada que solo esa persona o empresa tiene. Quien recibe la comprueba con la clave pública correspondiente, que, en palabras de la RFC 6376, sale de consultar directamente el dominio de quien firmó.

La clave está en un nombre armado con un selector, una etiqueta que elige quien firma para que un mismo dominio pueda tener varias claves. La RFC 6376 dice que todas las claves DKIM se guardan en un subdominio llamado _domainkey. Para el selector mail y el dominio example.com, quien recibe pide al DNS este nombre:

mail._domainkey.example.com.  TXT  "v=DKIM1; p=<public key>"

Tú no creas la clave. Tu proveedor de correo la genera y te muestra el registro que publicar. Publícalo tal como te lo muestra, en el nombre exacto. Una clave en el nombre equivocado es una clave que nadie encuentra.

Google dice que enviar a cuentas personales de Gmail exige una clave DKIM de 1024 bits o más y recomienda una clave de 2048 bits si tu proveedor de dominio lo permite.

DMARC: qué hacer cuando falla la prueba

El campo De es la dirección que ve la persona. SPF no comprueba esa dirección. Comprueba la que anuncia el servidor de envío, la identidad MAIL FROM o HELO. DKIM tampoco, porque separa a quien firma de quien escribe. DMARC cierra esa brecha. Google dice que el dominio del campo De debe estar alineado con el dominio de SPF o con el de DKIM. Basta con uno de los dos.

Un registro DMARC está en _dmarc, delante del nombre de tu dominio. Dice qué debe hacer quien recibe con un mensaje que falla y adónde enviar informes de lo que vio.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"
p=none
El propietario no declara preferencia sobre lo que pasa con el correo que falla (en palabras de la RFC 9989, no expresa preferencia). Google recomienda empezar por aquí.
p=quarantine
El propietario considera sospechoso el correo que falla: es posible que sea válido, aunque el fallo genera una preocupación significativa.
p=reject
El propietario toma cada fallo como una indicación clara de que el uso del nombre de dominio no es válido.
rua=
Adónde envía quien recibe los informes agregados, que pueden revelar correo que usa tu dominio y no pasa. Parte será de impostores. Parte será de servicios tuyos que aún no están configurados.

Apunta rua a una dirección creada solo para los informes. Tienen un formato que la RFC 9989 recomienda que lea una máquina, y muchos servicios los leen por ti.

De p=none a una política más estricta

Una política más estricta es quarantine o reject. Llegar ahí demasiado pronto convierte un hueco en tus registros en correo perdido. La RFC 9989 explica por qué el registro empieza en none: para asegurarse de que no se pasó nada por alto en las primeras configuraciones de SPF y DKIM. Microsoft aconseja avanzar poco a poco, de none a quarantine y luego a reject, para evitar pérdidas de correo no deseadas.

Ninguno de los pasos de abajo es una regla de un proveedor. Es una forma de seguir ese consejo.

  1. Configura SPF para cada servicio que envía por tu dominio y pide a tu proveedor de correo que firme con DKIM.
  2. Publica DMARC en none, con una dirección rua que uses solo para informes. Por ahora no le pides nada a quien recibe, solo los informes.
  3. Lee los informes. La RFC 9989 dice que, según la frecuencia con que envíes, puede llevar muchos meses leyendo informes hasta que estés seguro de que todo tu correo se autentica.
  4. Corrige cada servicio legítimo que falla. La RFC dice que esos fallos deben resolverse antes de cualquier política más estricta.
  5. Pasa a quarantine y sigue los informes y las respuestas que lleguen. Pasa a reject solo cuando los informes sigan limpios.

Para las reglas de remitente, quizá nunca necesites pasar de none. La guía de Google dice que la política de DMARC puede quedarse en none, y la regla de Microsoft para quien envía mucho pide al menos p=none. Ir más allá es decisión tuya. Las reglas piden el registro, no una política más estricta.

Por qué el correo de una app lleva su propio subdominio

Imagina que tu producto envía recibos y códigos de acceso y además haces prospección por correo. Los proveedores llevan un registro por cada dominio de envío. Yahoo dice que cada IP y cada dominio DKIM tiene una reputación y pide no enviar correo masivo o de marketing desde las mismas IP que usas para el correo que envía tu producto. Si los dos tipos de correo comparten dominio, comparten reputación.

Así que envía el correo de la app desde un subdominio propio, como mail.example.com, y deja la prospección fuera de él. La RFC 7208 dice que cada registro SPF se coloca en el nombre al que corresponde, así que el subdominio necesita el suyo. Pide también a tu proveedor que firme el correo del subdominio con una clave publicada en él, para que tenga su propio dominio DKIM.

DMARC da menos trabajo. Google dice que, sin una etiqueta sp, los subdominios heredan la política DMARC del dominio principal. La RFC 9989 dice lo mismo y añade que la política se aplica a los subdominios salvo que la política del subdominio se describa explícitamente con las etiquetas sp o np. Un registro en el dominio principal cubre al subdominio hasta que digas otra cosa.

Un subdominio no te libra de las reglas de volumen. Google suma el correo de un mismo dominio principal para decidir quién es remitente masivo, y su propio ejemplo reparte el envío entre un dominio y un subdominio y lo cuenta como un solo remitente. Para una separación que aguante, envía la prospección desde otro dominio.

Qué comprueba colding

colding nunca firma tu correo y nunca toca tu DNS. Tu proveedor de correo firma, y tú publicas los registros. colding solo los lee.

Por cada buzón, busca un registro SPF en el dominio del propio buzón y un registro DMARC en ese dominio o en el dominio superior más cercano que tenga uno. Un DMARC en none cuenta. Los dos deben existir para que el dominio pase.

DKIM nunca decide. El DNS no puede enumerar los selectores de un dominio, así que colding prueba los nombres que más usan los proveedores. Si encuentra una clave, lo dice. Si no, dice que la clave está sin verificar, nunca que falta, porque la tuya puede tener otro nombre.

Si SPF o DMARC siguen faltando durante 72 horas, el calentamiento y las campañas dejan de usar ese buzón hasta que una comprobación pase. Una campaña cuyos buzones fallan todos se pausa y dice el motivo. Si el DNS no responde, no se detiene nada: una consulta fallida no es un veredicto. Mira cómo leer el estado del dominio de un buzón por la API.

colding no cuenta las consultas de SPF y no nota un segundo registro SPF. Comprueba esas dos cosas tú mismo cada vez que añadas un remitente.

Cuando un dominio envía el correo de una app y también campañas, la página del buzón sugiere un subdominio para el correo de la app. Es solo un consejo y no bloquea nada.

Fuentes

Leímos estas páginas el 5 de octubre de 2026. Están en inglés. Si un proveedor cambió su página desde entonces, vale lo que dice su página y este texto está desactualizado.

Sigue leyendo