/
Generador DNS Email (SPF DKIM DMARC)

Generador DNS Email (SPF DKIM DMARC)

Genera registros DNS completos para email: SPF, DKIM, DMARC, MX y BIMI. Exporta zonas BIND, previene la suplantación de identidad y garantiza la máxima entregabilidad.

✨ Ajustes predefinidos:

Flujo de entrega y autenticación de correo en tiempo real

Postura DMARC activa:p=none
MTA Emisoracme-corp.comFiltro SPF~all (1/10 consultas)RFC 7208Verificación DKIMgoogle (RSA-2048)RFC 6376Alineación DMARCp=none (100%)RFC 7489Entregado en bandejaSolo monitorizadoSpam / CuarentenaOmitidoRechazo 550 / DropInactivo
Arquitectura de dominio y correoacme-corp.com
Parámetros del registro SPF (RFC 7208)1/10 consultas
Parámetros del registro DKIM (RFC 6376)
Motor de políticas DMARC (RFC 7489)_dmarc.acme-corp.com
Porcentaje de aplicación (pct=)100%
Enrutamiento de correo MX (RFC 5321)1 Servidores de enrutamiento activos
1smtp.google.com.
Indicador de marca BIMI (BIMI v1)
Dominio: acme-corp.comConsultas SPF: 1/10
Tabla consolidada de todos los registros DNS sintetizados. Copia valores individuales o exporta el archivo de zona completo.4 registros
TipoHost / NombrePrioridad / TTLContenido del registroAcción
MX@1 (TTL 3600)smtp.google.com.
TXT@3600v=spf1 include:_spf.google.com ~all
TXTgoogle._domainkey3600v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0w9Z8fGk3wIDAQAB
TXT_dmarc3600v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Total de registros: 4Postura: B (65/100)
Límite de consultas (RFC 7208)
1 / 10Sin PermError
Seguridad de clave criptográfica
RSA-2048Cadena única
Política contra suplantación
p=none100% Despliegue gradual

Procesamiento en el cliente

Cálculo de alto rendimiento ejecutado íntegramente en la memoria del navegador.

Privacidad total sin servidor

Todas las cargas útiles permanecen estrictamente locales sin comunicación externa.

Exportación para producción

Formatos de salida limpios y optimizados listos para su despliegue inmediato.

Referencia técnica y guía de arquitectura

Generador DNS Email (SPF DKIM & DMARC) — Guía de referencia

Genera registros DNS de correo (SPF, DKIM, DMARC, MX y BIMI). Exporta zonas BIND, previene la suplantación de identidad y asegura máxima entregabilidad.

Generador DNS Email (SPF DKIM & DMARC) — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos
Generador DNS Email (SPF DKIM & DMARC) — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos

Parámetros clave y controles

v=spf1 (Versión de Sender Policy Framework)String ("v=spf1")

Designa el registro TXT como una directiva SPF versión 1 (RFC 7208). Debe figurar obligatoriamente como el primer prefijo de la cadena; cualquier carácter previo o variante en minúsculas hará que los servidores MTA rechacen la sintaxis con un error permanente PermError.

Por defecto: v=spf1
include (Delegados de dominio autorizados SPF)Lista de dominios String ("include:dominio.com")

Delega la autorización SPF en el registro de un proveedor de correo saliente externo. Cada directiva include desencadena una consulta DNS recursiva que computa dentro del límite estricto de 10 consultas exigido por la RFC 7208.

Por defecto: _spf.google.com
all (Calificador de contingencia SPF)Enum ("-all" | "~all" | "?all" | "+all")

Establece la política de filtrado para los mensajes procedentes de direcciones IP no autorizadas. -all impone un rechazo estricto (Hard Fail); ~all aplica un fallo suave o Soft Fail (sospechoso pero aceptable); ?all define una disposición neutral.

Por defecto: ~all
k & p (Algoritmo y clave pública DKIM)Enum ("rsa" | "ed25519") y cadena Base64

Publicado en el registro TXT bajo <selector>._domainkey.<dominio>. Define el algoritmo criptográfico k y la clave pública p codificada en Base64 utilizada por los MTA receptores para verificar firmas de cabecera DKIM-Signature según RFC 6376 y RFC 8463.

Por defecto: k=rsa; p=...
p & sp (Política de dominio y subdominios DMARC)Enum ("none" | "quarantine" | "reject")

Determina cómo deben procesar los servidores de correo los mensajes que no superan la alineación DMARC bajo la norma RFC 7489. none recopila telemetría sin filtrar; quarantine desvía los fallos a la carpeta de spam o cuarentena; reject bloquea la entrega por completo.

Por defecto: none
rua & ruf (URIs para informes DMARC)Lista de URIs (mailto:[email protected])

rua recopila informes de telemetría agregada diarios en formato XML con volúmenes de entrega y tasas de autenticación; ruf recibe notificaciones forenses individuales en tiempo casi real bajo el formato AFRF de la RFC 6591 ante cada fallo de autenticación.

Por defecto: mailto:[email protected]
aspf & adkim (Modos de alineación de identificadores DMARC)Enum ("r" | "s")

r (relajado) permite que los subdominios se alineen con el dominio organizativo raíz; s (estricto) exige una coincidencia exacta byte por byte entre el dominio visible From (RFC 5322) y el Return-Path de SPF o la etiqueta d= de DKIM.

Por defecto: r
Ubicación y autoridad BIMI (etiquetas l= y a=)Cadena URI HTTPS

Se publica bajo default._bimi.<dominio>. La etiqueta l= enlaza a un logotipo vectorial cuadrado en formato SVG Tiny Portable/Secure; la etiqueta a= vincula opcionalmente un Certificado de Marca Verificada (VMC) en formato PEM.

Por defecto: Ninguno

Consejos profesionales y mejores prácticas

Evita el límite fatal de 10 consultas DNS en SPF

La norma RFC 7208 limita estrictamente la evaluación de un registro SPF a 10 consultas DNS mediante las directivas include, a, mx, ptr y redirect. Superar este límite genera un error permanente (PermError), lo que provoca que proveedores como Gmail, Microsoft 365 o Yahoo marquen los correos como no autenticados o spam. Emplea rangos IP en formato CIDR (ip4/ip6) en lugar de mecanismos a o mx, y aplana periódicamente las cadenas anidadas de include.

Divide claves DKIM de 2048 bits para BIND y Cloudflare

Los registros DNS TXT imponen un límite de longitud máxima de 255 octetos por cadena individual (RFC 1035). Una clave pública RSA estándar de 2048 bits genera unos 400 caracteres en Base64. Nunca trunques la clave; en su lugar, encapsula el contenido en comillas concatenadas: ("v=DKIM1; k=rsa; p=PRIMEROS_200_CARACTERES" "RESTO_DE_CARACTERES"). Cloudflare y paneles modernos gestionan esta división automáticamente, pero los archivos de zona BIND en bruto exigen la concatenación explícita entre paréntesis.

Implementa un despliegue progresivo de DMARC en 3 fases

Nunca apliques p=reject de forma directa en dominios de producción. Comienza con p=none; rua=mailto:... durante 2 a 4 semanas para auditar y descubrir todos los servicios legítimos no catalogados (CRM, pasarelas de pago, helpdesks). Avanza a p=quarantine; pct=25 incrementando progresivamente hasta pct=100, y finalmente migra a p=reject; sp=reject una vez que todos los flujos de correo legítimos alineen con SPF y DKIM.

Frena la suplantación en subdominios con sp=reject

Los ciberdelincuentes suelen suplantar la identidad en subdominios inactivos o no monitorizados (por ejemplo, facturacion.tudominio.com). Si tu dominio raíz opera bajo p=none durante la fase de análisis, añade explícitamente sp=reject: bloquearás inmediatamente el abuso y phishing en subdominios no configurados sin afectar el tráfico legítimo de tu dominio principal.

Problemas comunes y soluciones

⚠️DMARC falla la alineación a pesar de que SPF y DKIM indican PASS

Aprobar la autenticación no es suficiente; DMARC exige la alineación estricta de identificadores. Comprueba que el dominio visible en la cabecera From: (RFC 5322) coincida con el dominio del Return-Path (Mail From, RFC 5321) para SPF, o con la etiqueta d= de la firma DKIM. Si envías a través de plataformas de terceros (como Mailchimp, SendGrid o Zendesk), configura registros DKIM personalizados y un CNAME propio para el Return-Path, garantizando que las cabeceras firmen con tu propio dominio corporativo y no con el compartido del proveedor.

⚠️Gmail y Yahoo rechazan correos con el error 550-5.7.26 authentication checks failed

Desde febrero de 2024, Google y Yahoo exigen obligatoriamente SPF, DKIM y DMARC a todos los remitentes masivos (más de 5.000 mensajes diarios). Asegúrate de que tu dominio cuente con una política DMARC activa (mínimo p=none), resolución DNS inversa (rDNS/PTR) que coincida con el hostname del servidor MTA emisor, y cabeceras de baja en un solo clic (RFC 8058). Además, valida que el registro SPF no sobrepase las 10 consultas DNS.

⚠️El proveedor de DNS devuelve el error String exceeds 255 characters o sintaxis de registro TXT no válida

Este error surge al pegar claves DKIM de 2048 o 4096 bits en paneles DNS que no fragmentan cadenas de texto automáticamente. Activa la opción de división segura a 255 bytes de esta herramienta para exportar el registro particionado en subcadenas delimitadas por comillas, o bien configura tu agente de transferencia de correo para emplear claves RSA de 1024 bits o el algoritmo moderno Ed25519 si tu proveedor lo soporta.

Preguntas frecuentes (FAQ)

¿Cómo afecta el límite de 10 consultas DNS de SPF a la entregabilidad del correo?▼

La norma RFC 7208 estipula que la evaluación de un registro SPF no debe superar las 10 consultas DNS directas o anidadas a través de mecanismos como include:, a, mx, ptr, exists: y redirect. Si un mensaje entrante activa una undécima consulta, el servidor MTA receptor detiene de inmediato el análisis emitiendo un error permanente (PermError). Los principales proveedores de correo (Google Workspace, Microsoft 365, Yahoo) tratan el PermError como un fallo crítico de autenticación, desviando los mensajes a la carpeta de correo no deseado o rechazándolos en origen. Para mantenerse bajo el límite, elimina directivas a y mx prescindibles, declara directamente bloques IP en formato CIDR mediante ip4: e ip6:, y evita anidar múltiples plataformas SaaS en el dominio raíz.

¿Por qué los correos fallan la alineación DMARC si SPF y DKIM están aprobados?▼

La autenticación DMARC no solo requiere que SPF o DKIM superen sus comprobaciones criptográficas o de red, sino que exige que el dominio autenticado esté alineado con el dominio visible en la cabecera From: (RFC 5322) que ve el usuario. Al enviar correos mediante proveedores externos como SendGrid, Salesforce o Shopify sin una configuración personalizada, SPF se valida para el dominio del proveedor (por ejemplo, sendgrid.net en el Return-Path) y DKIM puede firmarse con las claves del proveedor, pero ninguno coincide con tuempresa.com. Dado que ambos dominios discrepan, la alineación DMARC falla. Para solucionarlo, debes crear un subdominio Return-Path de marca propia para SPF y dar de alta registros CNAME DKIM dedicados para que los correos salgan firmados con tu propio dominio.

¿Cómo dividir claves públicas DKIM de 2048 bits que superan 255 caracteres en registros TXT?▼

Según la RFC 1035, una cadena de texto individual dentro de un registro DNS TXT no puede exceder los 255 octetos. Una clave pública RSA de 2048 bits codificada en Base64 contiene aproximadamente 400 caracteres, lo que obliga a fraccionar el registro en dos o más fragmentos. En archivos de zona BIND y en servidores como PowerDNS, esto se implementa encerrando el registro entre paréntesis y entrecomillando cada bloque: ( "v=DKIM1; k=rsa; p=PARTE_1" "PARTE_2" ). Al resolver la consulta, los servidores recursivos concatenan automáticamente las cadenas contiguas sin añadir espacios en blanco. Plataformas como Cloudflare, AWS Route 53 o Google Cloud DNS gestionan esta partición de forma transparente, mientras que paneles más antiguos como cPanel requieren introducir manualmente los bloques o las comillas multilínea.

¿Cuál es la diferencia entre las políticas DMARC p=none, p=quarantine y p=reject?▼

La etiqueta p= define la acción que los servidores de correo receptores deben ejecutar cuando un mensaje que dice proceder de tu dominio no supera la alineación de SPF ni de DKIM. La directiva p=none actúa como modo de monitorización pasiva: los correos se entregan normalmente y se envían informes de telemetría agregada en XML a la dirección configurada en rua=. La política p=quarantine ordena a los servidores desviar los correos no alineados a la carpeta de spam o cuarentena del destinatario, mitigando el phishing pero permitiendo su inspección. Por último, p=reject aplica la máxima restricción: ordena a los MTA rechazar los mensajes no alineados durante la propia sesión SMTP (error 550 SMTP reject), impidiendo de raíz que cualquier correo falsificado llegue al buzón del usuario.

¿Cómo configurar registros BIMI con certificados VMC para Gmail y Apple Mail?▼

BIMI (Brand Indicators for Message Identification) permite mostrar el logotipo oficial de una marca junto a los correos en clientes compatibles como Gmail, Apple Mail y Yahoo. Para implementarlo: 1) Tu dominio debe tener una política DMARC estricta en p=quarantine (pct=100) o p=reject; 2) Diseña un logotipo vectorial en formato SVG Tiny Portable/Secure (proporción cuadrada, sin scripts externos ni animaciones); 3) Adquiere un Certificado de Marca Verificada (VMC) emitido por una Autoridad de Certificación reconocida (como DigiCert o Entrust) que acredite tu marca registrada ante organismos oficiales (como la OEPM, EUIPO o USPTO); 4) Publica un registro TXT en default._bimi.tudominio.com con el valor v=BIMI1; l=https://tudominio.com/logo-bimi.svg; a=https://tudominio.com/certificado-vmc.pem. Aunque Yahoo muestra logotipos sin VMC, Gmail y Apple Mail exigen obligatoriamente un certificado VMC válido para desplegar la imagen corporativa.

Herramientas y utilidades relacionadas

Todas las herramientas →