Verificador de SPF, DKIM y DMARC
Comprueba en segundos si tu dominio tiene los registros de autenticación configurados correctamente. SPF, DKIM y DMARC son lo que separa tu correo de la bandeja de entrada de la carpeta de spam, y lo que impide que los estafadores falsifiquen mensajes en nombre de tu empresa.
Qué hace cada registro
SPF — quién puede enviar
El SPF (Sender Policy Framework) es un registro TXT que lista los servidores autorizados a enviar correo en nombre de tu dominio. Cuando el proveedor del destinatario recibe el mensaje, comprueba si el servidor de origen está en esa lista. Un SPF bien configurado termina en -all (estricto) o ~all (suave); terminar en +all o ?all deja la puerta abierta a la falsificación.
DKIM — la firma digital
El DKIM (DomainKeys Identified Mail) firma cada mensaje con una clave criptográfica privada. La clave pública correspondiente se publica en el DNS, en selector._domainkey.tudominio. El destinatario usa esa clave para confirmar que el mensaje no fue alterado en el camino y que realmente salió de tu dominio. Por eso la verificación de DKIM necesita el selector: cada proveedor de correo usa un nombre distinto.
DMARC — la regla de decisión
El DMARC (Domain-based Message Authentication, Reporting and Conformance) une SPF y DKIM y le dice al proveedor qué hacer cuando un mensaje falla en ambas verificaciones: ignorar (p=none), mandar a spam (p=quarantine) o rechazar (p=reject). También genera reportes que muestran quién está intentando enviar correo en nombre de tu dominio. Sin DMARC, estás a ciegas ante el abuso.
Los 6 errores más comunes — y cómo corregir cada uno
La mayoría de los dominios que reprueban la verificación no carecen de autenticación: la tienen rota por un detalle. Estos son los casos que aparecen con más frecuencia en migraciones y al contratar un servicio de envío.
1. Dos registros SPF en el mismo dominio
La RFC 7208 admite un único registro TXT que comience con v=spf1. Con dos, la evaluación devuelve permerror y cuenta como falla, aunque ambos sean correctos por separado. Corrección: unir todo en un solo registro, usando include: para cada servicio.
2. Superar el límite de 10 consultas DNS
Cada include, a, mx, ptr y redirect consume una consulta, y los includes anidados cuentan también a sus hijos. Si pasas de 10, es permerror. Corrección: quitar los servicios que ya no envían, aplanar los includes innecesarios y evitar ptr, que la propia RFC desaconseja.
3. Terminar el SPF en +all
+all autoriza a cualquier servidor del mundo a enviar en nombre del dominio: es tener SPF publicado y ninguna protección. Corrección: usar -all cuando el inventario de remitentes esté completo, o ~all durante la fase de observación.
4. DMARC detenido en p=none para siempre
p=none solo observa: un dominio con esa política sigue siendo falsificado a gusto. La política es un escalón, no un destino. Corrección: publicar rua= para recibir los reportes agregados, leer lo que aparece durante algunas semanas y evolucionar a quarantine y luego a reject.
5. Alineación rota con un servicio de envío
DMARC no mira solo si SPF o DKIM pasaron: exige alineación con el dominio que el destinatario ve en el campo From. Las plataformas de envío suelen usar un Return-Path propio, que pasa el SPF y reprueba la alineación. Corrección: configurar el dominio de envío personalizado de la plataforma y firmar en DKIM con tu dominio: un DKIM alineado sostiene a DMARC por sí solo.
6. Selector de DKIM huérfano tras una migración
Quien cambia de proveedor suele publicar el selector nuevo y olvidar el antiguo en el DNS, o al revés: borrar el antiguo antes del corte y quedarse sin una firma válida durante algunas horas. Corrección: mantener publicados los dos selectores durante la ventana de migración y quitar el antiguo solo cuando los reportes DMARC dejen de citarlo.
Conviene recordar por qué esto dejó de ser opcional: desde febrero de 2024, Google y Microsoft empezaron a exigir SPF, DKIM y DMARC a quienes envían grandes volúmenes a Gmail y Outlook; sin los tres, el mensaje ni siquiera llega a ser evaluado por el filtro de contenido. El paso a paso completo de configuración está en la guía de mejores prácticas de seguridad de correo (en portugués).
¿Quieres recomendar esta herramienta?
Si escribes sobre correo, seguridad o TI, puedes recomendar este verificador a tus lectores. Copia el enlace de abajo:
<a href="https://meile.com.br/es/herramientas/verificador-spf-dkim-dmarc/" target="_blank" rel="noopener">
Verifica el SPF, DKIM y DMARC de tu dominio (herramienta gratuita)
</a>Para revendedores: la entregabilidad es un servicio gestionado recurrente
Configurar y mantener SPF, DKIM y DMARC para cada cliente es justo el tipo de trabajo que separa a un revendedor profesional de uno que solo revende buzones de correo. Quien opera una cartera de dominios con autenticación correcta entrega en la bandeja de entrada, bloquea la falsificación y tiene reportes para mostrar, y lo cobra como servicio todos los meses.
Revender correo es un modelo de ingreso recurrente y predecible: contratas la operación como servicio gestionado y la revendes con tu marca, mes a mes, a diferencia de revender Google Workspace o Microsoft 365, donde la ganancia es una comisión fija definida por el fabricante. Y además con datacenter en Brasil y cumplimiento de la LGPD (Ley General de Protección de Datos de Brasil) como diferencial. Conoce el programa de reventa white label de Meile.
Quiero ser socio