📧 Verificar Auth Email
Introduce un dominio para obtener MX, SPF, DMARC, MTA-STS, TLS-RPT y validarlos.
📚 Fundamentos
• SPF: Declara qué IPs/hosts pueden enviar email del dominio (TXT)
• DKIM: Añade firma digital — el selector es necesario, no se puede auto-detectar
• DMARC: Política sobre SPF/DKIM
• MTA-STS: El receptor declara que TLS es obligatorio
• TLS-RPT: A dónde enviar informes de fallos TLS
📖 Qué te dice este diagnóstico
Este diagnóstico sólo lee DNS e informa de MX, SPF, DMARC y MTA-STS / TLS-RPT. DKIM no está incluido: su clave pública no puede consultarse sin saber el nombre del selector, y los selectores no se pueden enumerar desde DNS. Además, todo en verde no significa que tu correo llegue a la bandeja de entrada. La entregabilidad la determinan sobre todo la reputación de tu IP y tu dominio; los registros de autenticación son sólo la condición previa.
| Elemento | Qué significa | Cómo corregirlo |
|---|---|---|
| SPF puede pasar en correo falsificado | SPF valida el remitente del sobre, el Return-Path, y nunca mira la cabecera From: que ve el destinatario. Un atacante puede configurar SPF perfectamente en un dominio propio y aun así poner tu empresa en From:. SPF por sí solo no detiene la suplantación. |
DMARC cierra esto con la alineación, que exige que el dominio de From: coincida con el que pasó SPF o DKIM. Si envías por un SaaS, el Return-Path por defecto es el dominio del proveedor, así que la alineación falla. Usa el ajuste de Return-Path personalizado o de autenticación del dominio remitente para llevarlo a un subdominio tuyo, como bounce.example.com. |
| DMARC estancado en p=none | p=none dice: no hagas nada cuando la autenticación falle. El registro existe y no se bloquea ni un solo mensaje falsificado. Como hay registro, los verificadores lo muestran en verde, y por eso este estado se confunde con estar resuelto. |
Recoge informes agregados con rua=mailto:… y dedica de dos a cuatro semanas a identificar todos los remitentes legítimos: una herramienta de marketing, un sistema de facturación, un script interno olvidado. Cuando todos autentiquen, empieza en p=quarantine; pct=10, sube el porcentaje hasta 100 y termina en p=reject. |
| El reenvío siempre rompe SPF | Cuando el correo pasa por una lista o un reenvío automático, la IP de origen pasa a ser la del reenviador, así que SPF falla siempre. Es inherente al mecanismo, no un error de configuración. DKIM firma cuerpo y cabeceras, así que sobrevive mientras el reenviador no los reescriba. | Configura siempre DKIM. DMARC pasa si se alinea SPF o DKIM, así que con DKIM la autenticación sobrevive al reenvío. Subir a p=reject sólo con SPF hace que se rechace todo el correo reenviado. Las listas que añaden un prefijo al asunto también rompen DKIM, y ahí sólo queda confiar en receptores compatibles con ARC. |
Un dominio que sólo envía y nunca recibe también necesita configuración. En vez de dejar MX vacío, publica un null MX (0 ., RFC 7505) y declara v=spf1 -all con p=reject, para que el spam que dice venir de ese dominio se rechace de plano. La otra trampa que conviene conocer es que la verificación del remitente en un proveedor se hace por coincidencia exacta de dominio: verificar example.com no autoriza necesariamente el correo desde mail.example.com. Eso fue lo que detuvo nuestro propio correo saliente hasta que unificamos el remitente en el dominio padre.