Generador de Registros SPF y DMARC
Crea el registro SPF y el DMARC de tu dominio con un asistente: elige tus proveedores de correo y te da el TXT listo, avisando de los errores que tiran el correo.
Marca todos los que envíen en tu nombre. Olvidar uno hace que su correo acabe en spam.
| Nombre | @ |
|---|---|
| Tipo | TXT |
| Valor | v=spf1 include:_spf.google.com -all |
En el panel de tu proveedor de DNS, crea un registro TXT con ese nombre y ese valor. Si te pide el nombre completo, usa: tudominio.com
Los registros se construyen en tu navegador. No se consulta ni se envía nada.
Qué hace esta herramienta
Construye los dos registros DNS que autentican tu correo —SPF y DMARC— con un asistente, y te avisa de los errores que de verdad hacen daño antes de que los publiques.
Existe porque el catálogo tenía diecinueve verificadores y ningún generador: podías saber que te falta el SPF, pero no obtener el que hay que poner. Y es el lado en el que equivocarse sale caro: un SPF mal montado no deja pasar spam, tira tu propio correo.
SPF: el orden y el límite
Un registro SPF declara qué servidores pueden enviar correo en nombre de tu dominio. Dos cosas lo rompen, y las dos son invisibles a simple vista.
Solo puede haber uno
La especificación permite exactamente un registro SPF por dominio. Con dos, el receptor no los suma: falla la comprobación y se queda sin saber qué hacer.
Pasa constantemente. Contratas un servicio de facturación, te pide publicar su SPF, lo añades como un TXT nuevo, y sin enterarte acabas de romper la autenticación de todo tu correo. Lo correcto es fundir los include en un único registro, que es lo que hace este generador cuando marcas varios proveedores.
El límite de 10 consultas
Cada mecanismo include, a, mx o exists obliga al servidor receptor a una consulta DNS adicional, y la especificación corta en diez. Pasado ese punto la evaluación devuelve permerror y tu SPF deja de proteger nada.
Lo traicionero es que los include anidan: el de Google Workspace gasta cuatro consultas él solo, porque por dentro incluye otros. Tres o cuatro proveedores y ya estás rozando el límite con un registro que parece corto.
El contador de esta herramienta suma las consultas reales, no los mecanismos escritos, y se pone en rojo al pasarse. Si te pasas: sustituye el include de algún proveedor por sus IP directas con ip4:, que no consumen consulta.
El calificador final
Es lo que le dices al receptor sobre quien no está en la lista:
-all(rechazar) — lo recomendado cuando ya tienes localizados a todos tus remitentes.~all(sospechoso) — el sitio por donde empezar. Marca sin rechazar, así que un remitente olvidado no desaparece: llega marcado y te enteras.?all(neutral) — no afirma nada, así que apenas aporta.+all— no publiques esto nunca. Autoriza a todo internet a enviar como tú, y es peor que no tener SPF porque aparenta protección donde no la hay.
DMARC: la parte que casi nadie termina
DMARC le dice al receptor qué hacer cuando SPF y DKIM fallan, y le pide que te mande informes de lo que ve.
La política tiene tres escalones y el error habitual es quedarse en el primero:
p=none— solo observa. Recoges informes, no se bloquea nada. Es el punto de partida correcto.p=quarantine— a spam.p=reject— rechazado en la puerta.
El beneficio real está en el segundo y el tercero. Con p=none, un atacante que suplante tu dominio sigue llegando a la bandeja de entrada; lo único que cambia es que tú te enteras. Pero subir antes de tiempo tira tu propia facturación, así que el camino es: publica p=none con rua, espera unas semanas, mira los informes, arregla los remitentes legítimos que fallen, y entonces sube.
La etiqueta que no puedes omitir
rua es el buzón donde llegan los informes agregados. Sin ella, DMARC no te sirve de nada: no sabes quién envía en tu nombre, no sabes qué remitentes tuyos fallan, y no tienes con qué decidir cuándo endurecer. Es la etiqueta más útil del registro y la que más se olvida.
ruf, los informes forenses, es otra cosa: lleva contenido de correos reales —con las implicaciones de privacidad que eso tiene— y muy pocos proveedores los envían. Se puede prescindir de ella tranquilamente.
Dónde va cada registro
| Registro | Nombre en tu panel DNS | Tipo |
|---|---|---|
| SPF | @ (la raíz del dominio) | TXT |
| DMARC | _dmarc | TXT |
| DKIM | selector._domainkey | TXT |
Si tu proveedor te pide el nombre completo en vez del relativo, la herramienta te lo muestra debajo del registro.
Por qué DKIM no se genera aquí
Porque no es un registro que se escriba: es una clave pública. DKIM funciona con un par de claves —tu servidor de correo firma cada mensaje con la privada, y el receptor la verifica con la pública que publicas en el DNS—. Ese par lo genera tu proveedor de correo, y él te entrega el valor exacto que hay que pegar.
Lo que sí puedes hacer aquí es ver dónde va, y comprobarlo después con el verificador de DKIM.
Después de publicar
Los cambios de DNS tardan en propagarse, entre minutos y unas horas según el TTL. Cuando pase, compruébalo con el informe de salud del dominio, que revisa los tres a la vez y te dice qué queda por hacer.
Preguntas frecuentes
¿Puedo tener dos registros SPF?
No. La especificación permite exactamente uno por dominio, y con dos los servidores receptores fallan la comprobación en lugar de sumar ambos. Es un error muy común al contratar un servicio nuevo que te pide publicar su propio SPF: lo correcto es fundir los include en un único registro, que es lo que hace este generador.
¿Qué es el límite de 10 consultas y por qué importa?
Cada mecanismo include, a, mx o exists obliga al receptor a hacer una consulta DNS adicional, y la especificación corta en diez. Pasado ese punto la evaluación devuelve un error permanente y tu SPF deja de proteger nada. Lo traicionero es que los include anidan: el de Google gasta cuatro por sí solo. El contador de esta herramienta suma los reales, no los que se ven escritos.
¿Empiezo con -all o con ~all?
Con ~all si no estás seguro de tener localizados todos tus remitentes, porque marca como sospechoso en lugar de rechazar y te da margen a corregir. Pasa a -all cuando los informes de DMARC salgan limpios. Lo que nunca debes publicar es +all: autoriza a todo internet a enviar como tú y aparenta protección donde no la hay.
¿Por qué DMARC empieza en p=none?
Porque bloquear antes de saber quién envía en tu nombre es la forma más rápida de tirar tu propia facturación. Con p=none recoges informes sin rechazar nada, ves qué remitentes legítimos fallan la autenticación, los arreglas, y solo entonces subes a quarantine y después a reject. Casi todo el mundo se queda en el primer paso, que es donde no hay beneficio.
¿Y el registro DKIM?
DKIM no se puede generar aquí porque necesita un par de claves criptográficas: la privada la guarda tu servidor de correo para firmar, y la pública es la que se publica en el DNS. Ese par lo genera tu proveedor, y él te da el valor exacto a pegar. Esta herramienta sí te dice dónde va, en selector._domainkey.
Reseñas y valoraciones
Aún no hay reseñas. ¡Sé la primera persona en opinar!
Herramientas relacionadas
Otras del catálogo que se usan bien junto a esta.