BrowserTools
Inicio / Generadores / Generador de SPF y DMARC

Generador de SPF y DMARC

Crea los registros DNS que impiden que otros envíen correo en tu nombre, o revisa uno que ya tengas.

Cargando Generador de SPF y DMARC… Si no ocurre nada, activa JavaScript.

Cualquiera puede poner tu dirección en la línea De de un correo. SPF y DMARC son los dos registros DNS que permiten a los servidores de correo distinguir el correo auténtico de las falsificaciones. SPF (Sender Policy Framework) es un registro TXT en tu dominio que enumera los servidores autorizados a enviar en su nombre: tu proveedor de correo, tu servicio de boletines, tu propio servidor. DMARC se apoya en él, en _dmarc.tudominio, e indica a los receptores qué hacer con el correo que no supera las comprobaciones (entregarlo, mandarlo a spam o rechazarlo) y adónde enviar informes al respecto. Gmail, Yahoo y Microsoft ya exigen ambos a los remitentes masivos, y sin ellos tu correo legítimo tiene más probabilidades de acabar en spam mientras el falsificado pasa.

Preguntas frecuentes

¿Dónde añado estos registros?
En la configuración DNS de la empresa que aloja el DNS de tu dominio, normalmente tu registrador o un servicio como Cloudflare. Crea un registro TXT. Para SPF el host es el propio dominio, que a menudo se escribe @. Para DMARC el host es _dmarc, que algunos paneles piden como _dmarc.ejemplo.com y otros solo como _dmarc, porque añaden el dominio por ti. Los cambios suelen aplicarse en unos minutos o unas horas, según el TTL.
¿Qué diferencia hay entre ~all y -all?
Los dos cierran la lista de remitentes autorizados. Con ~all (fallo suave), el correo de servidores no incluidos se acepta pero se trata como sospechoso, lo que normalmente significa la carpeta de spam. Con -all (fallo definitivo), los receptores pueden rechazarlo directamente. ~all es el comienzo más seguro mientras aún descubres todos los servicios que envían por ti. Cuando ya tengas DKIM y DMARC, -all es una buena opción, y Microsoft lo recomienda para los dominios de Microsoft 365. ?all no protege nada y +all autoriza a todo internet, así que evita ambos.
¿Por qué SPF tiene un límite de 10 consultas DNS?
Comprobar un registro SPF puede obligar al receptor a consultar el DNS una y otra vez, por eso el RFC 7208 limita a 10 por comprobación los mecanismos que necesitan una consulta (include, a, mx, ptr, exists y redirect), contando también todo lo que hay dentro de los include anidados. Superar el límite es un error permanente y SPF falla para todo tu correo. Esta herramienta cuenta las consultas escritas directamente en tu registro. No puede ver el interior de los registros incluidos sin consultas DNS reales, y algunos usan varias por sí solos, así que deja margen. Si te quedas sin espacio, pasa un servicio a un subdominio o sustituye un include por sus rangos de IP publicados.
¿Puedo tener dos registros SPF?
No. Un dominio o subdominio debe publicar exactamente un registro TXT que empiece por v=spf1. Si hay dos, los receptores devuelven un error permanente y SPF falla para todo, un error habitual tras añadir un servicio nuevo. Únelos: deja un solo v=spf1 al principio, pon todos los términos ip4, ip6 e include en medio y termina con un único all.
¿Y DKIM?
DKIM añade una firma criptográfica a cada mensaje saliente, y la clave pública correspondiente se publica en el DNS bajo un selector, como selector1._domainkey.ejemplo.com. El par de claves lo crea quien firma tu correo, así que no puedes generar por tu cuenta un registro DKIM útil: activa DKIM en la consola de administración de tu proveedor (Google Workspace, Microsoft 365, SendGrid y otros) y publica los registros TXT o CNAME que te indique. DKIM importa porque sobrevive al reenvío, donde SPF suele fallar, y DMARC se supera si cualquiera de los dos está alineado con tu dominio De.
¿Con qué política DMARC debería empezar?
Empieza con p=none y una dirección rua. Tu correo no cambia, pero los receptores empiezan a enviar informes agregados diarios con cada servidor que envía en nombre de tu dominio y si ha pasado las comprobaciones. Tras dos a cuatro semanas, corrige SPF o DKIM de cualquier remitente legítimo que falle, pasa a p=quarantine y más adelante a p=reject. Quedarse en p=none para siempre no protege: solo observa.
¿Qué cambió con el RFC 9989?
En mayo de 2026 el IETF publicó el RFC 9989, que sustituye al RFC 7489 como norma DMARC, junto con los RFC 9990 y 9991 para los informes. Elimina las etiquetas pct, ri y rf, añade t=y como modo de prueba sencillo y np para los subdominios que no existen, e incorpora la etiqueta psd que usan los operadores de sufijos públicos. Los registros existentes siguen funcionando y muchos receptores todavía respetan pct, por eso esta herramienta mantiene pct y ri como ajustes antiguos opcionales.
¿Por qué los informes enviados a otro dominio necesitan un registro adicional?
Para evitar que alguien dirija informes DMARC a un buzón que no es suyo, los receptores comprueban que el destino acepta recibirlos. Si tu registro de ejemplo.com envía informes a reports@dmarc-service.net, ese servicio debe publicar un registro TXT en ejemplo.com._report._dmarc.dmarc-service.net con v=DMARC1. Los servicios de informes lo configuran cuando añades tu dominio, pero un buzón en otro dominio tuyo también lo necesita.
¿Esta herramienta consulta mi dominio?
No. Los registros se crean y comprueban por completo en tu navegador y nada de lo que escribes se envía a ningún sitio. Eso también significa que no puede ver lo que está publicado ahora ni resolver los include anidados. Usa la herramienta DNS Lookup para obtener los registros TXT reales de tu dominio y de _dmarc.tudominio, y pégalos en el comprobador.

Acerca de Generador de SPF y DMARC

El generador de SPF te deja marcar los servicios que usas (Google Workspace, Microsoft 365, Zoho Mail, Amazon SES, SendGrid, Mailgun y Mailchimp Transactional, con los valores include tomados de la documentación de cada proveedor), añadir tus propias direcciones IPv4 e IPv6 y elegir lo estricto que debe ser el all final. Cuenta las consultas DNS sobre la marcha, porque SPF deja de funcionar por encima de 10, y divide el valor en cadenas de 255 caracteres cuando un registro largo lo necesita. El comprobador toma un registro existente y explica cada término en lenguaje sencillo. Señala errores de sintaxis como include= en lugar de include:, un espacio después de los dos puntos o ipv4: en lugar de ip4:, y avisa de un segundo registro SPF en el mismo dominio, del mecanismo ptr obsoleto, del peligroso +all, de términos colocados después de all y de registros tan largos que fallan por UDP.

El generador de DMARC sigue el despliegue gradual que evita perder correo: empieza con p=none y una dirección para informes, lee los informes durante unas semanas para encontrar todos los servicios que envían en tu nombre, pasa después a quarantine y por último a reject. Incluye las políticas para subdominios y para subdominios inexistentes, la alineación estricta o flexible, las opciones de informes de fallos y el modo de prueba del RFC 9989, la norma DMARC actualizada publicada en mayo de 2026, y conserva las etiquetas antiguas pct y ri para los receptores que aún las usan. Ambas pestañas muestran el nombre de host exacto y el valor TXT con botones para copiar. Todo se calcula en tu navegador y no se hacen consultas DNS, así que para compararlo con lo que publica hoy un dominio, obtén sus registros TXT con la herramienta DNS Lookup y pégalos en el comprobador.

SPF nació para frenar el spam rebotado

A principios de los años 2000, los spammers falsificaban de forma rutinaria el remitente de sobre de sus mensajes, y los rebotes de millones de correos basura imposibles de entregar llegaban a los buzones de propietarios de dominios inocentes. Varias propuestas intentaron solucionarlo, entre ellas Reverse MX y Designated Mailers Protocol, y en 2003 Meng Weng Wong combinó sus ideas en Sender Permitted From, que pronto pasó a llamarse Sender Policy Framework. Microsoft impulsó un rival llamado Sender ID, y ambos se publicaron en paralelo como experimentos en 2006. Ganó SPF: se convirtió en norma propuesta como RFC 7208 en 2014, mientras Sender ID y sus registros spf2.0 cayeron en el olvido.

Por sí solo, SPF tenía un hueco, porque comprueba la dirección de sobre oculta y no la línea De que la gente ve de verdad. En 2012 un grupo que incluía a PayPal, Google, Microsoft y Yahoo publicó DMARC, que vincula los resultados de SPF y DKIM al dominio De visible y añade informes. PayPal tenía buenos motivos: era una de las marcas más suplantadas en el phishing. DMARC pasó años como documento informativo, el RFC 7489, hasta que el RFC 9989 lo llevó a la vía de normas del IETF en 2026.

Apoyar