Verificador de Email Auth - SPF, DKIM y DMARC

Q: ¿Cuál es la diferencia entre SPF, DKIM y DMARC?

Tres mecanismos en capas basados en DNS. SPF (RFC 7208 Kitterman, 2014) es un registro TXT que lista qué direcciones IP o hosts están autorizados a enviar correo desde tu dominio — los servidores receptores comparan la IP que conecta con la lista. DKIM (RFC 6376 Crocker, Hansen y Kucherawy, 2011) adjunta una firma criptográfica a los mensajes salientes usando una clave privada; los receptores obtienen la clave pública correspondiente de tu DNS (basado en selector) y verifican la firma. DMARC (RFC 7489 Kucherawy y Zwicky, 2015) añade la política de alineación: especifica qué deben hacer los receptores (none, quarantine, reject) cuando SPF y/o DKIM no alinean con la cabecera From — y dónde enviar reportes agregados (rua) o forenses (ruf). Usados juntos, SPF autoriza al remitente, DKIM firma el contenido, y DMARC los ata a la identidad visible del From.

Q: ¿Qué es la alineación en DMARC y por qué SPF solo falla?

Alineación significa que el dominio que pasa SPF o DKIM debe coincidir con el dominio de la cabecera From visible. SPF autentica el Return-Path (remitente del sobre), no la cabecera From — así un atacante puede pasar SPF usando un remitente tercero que controla legítimamente mientras suplanta tu From. DMARC cierra esa brecha requiriendo que SPF o DKIM alineen: mismo dominio (alineación estricta) o mismo dominio organizacional (relajada, por defecto). Por ejemplo, un correo de `from@ejemplo.com` con Return-Path `bounces@ejemplo.com` alinea SPF; con Return-Path `service@mailer.com`, SPF pasa pero no alinea. La alineación DKIM compara el dominio firmante d= con el dominio From. Al menos uno — SPF o DKIM — debe pasar Y alinear para que DMARC pase. Por eso SPF solo es insuficiente para prevenir spoofing.

Q: ¿Qué hace ARC y por qué se añadió?

ARC (Authenticated Received Chain, RFC 8617 Andersen, Long, Blank y Kucherawy, julio 2019) conserva la evidencia de autenticación a través de saltos de forwarding. El problema: forwarders legítimos (listas de correo, alumni forwarders, relays de tenant Microsoft 365) a menudo modifican el mensaje — añadiendo prefijos al asunto, texto de footer, o reescribiendo el Subject — lo que rompe las firmas DKIM. SPF también se rompe porque el forwarder no es el remitente autorizado original. Sin ARC, el correo de una lista forwardeada a un usuario Gmail suele fallar DMARC y caer en spam, aunque el remitente original fuera legítimo. ARC añade tres cabeceras — ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal — que capturan la evaluación de autenticación del servidor receptor en cada salto. El receptor final puede confiar en la cadena hasta el remitente verificado original, permitiendo el paso del mensaje a pesar de las modificaciones posteriores.

Q: ¿Qué cambió para remitentes masivos en febrero 2024?

Google y Yahoo introdujeron requisitos más estrictos para remitentes masivos efectivos el 1 de febrero de 2024 (anunciado en octubre 2023). Los remitentes que envían ≥5.000 mensajes por día a cuentas Gmail o Yahoo deben: (1) publicar un registro DMARC (requisito inicial p=none monitorizando; mínimo de cumplimiento junio 2024); (2) autenticar con SPF y DKIM, con al menos uno alineado a la cabecera From; (3) mantener DNS forward y reverse válido (registros PTR) para las IPs de envío; (4) transmitir sobre conexiones TLS cifradas; (5) incluir List-Unsubscribe en un clic (RFC 8058 mailto: + HTTP POST) para correo de marketing; (6) mantener la tasa de spam de Postmaster Tools por debajo del 0,10% (evitando el umbral de blocklist de 0,30%). El fallo en cumplir esto dispara retrasos de entrega temporales, eventualmente rechazo. El cambio refleja un movimiento de varios años de la industria de 'autenticación es mejor práctica' a 'autenticación es requerida para colocación en inbox en los principales proveedores de buzón'.

Q: ¿Por qué mi correo legítimo sigue cayendo en spam?

Incluso el correo correctamente autenticado puede caer en spam por razones de contenido o reputación. Causas comunes: (1) la alineación DMARC pasa pero la firma DKIM está en un dominio de tracking-redirector, no en la marca visible; (2) la IP de envío tiene un historial de reputación pobre (adquirida de un tenant anterior); (3) el dominio From es nuevo (<30 días) y carece de historial de engagement; (4) los patrones de URL o adjuntos coinciden con heurísticas de phishing (acortadores de URL, adjuntos .zip/.exe); (5) el cuerpo del correo contiene palabras clave de spam emparejadas con HTML estilo marketing; (6) el destinatario marcó correo previo de tu dominio como spam, entrenando su filtro personal. La autenticación es necesaria pero no suficiente — la calidad del contenido, higiene de listas, IP warming y métricas de engagement también cuentan.

Verificador Email Auth — SPF, DKIM, DMARC, ARC + Reglas Bulk Sender 2024

La autenticación de correo usa mecanismos basados en DNS para comprobar que los mensajes que dicen venir de tu dominio realmente estaban autorizados. Los tres pilares son SPF (RFC 7208 Kitterman, 2014), DKIM (RFC 6376 Crocker, Hansen y Kucherawy, 2011) y DMARC (RFC 7489 Kucherawy y Zwicky, 2015). SPF lista las IPs autorizadas para enviar; DKIM firma criptográficamente los mensajes salientes; DMARC requiere que SPF o DKIM alineen con la cabecera From visible y dice a los receptores (none/quarantine/reject) qué hacer cuando la alineación falla. ARC (RFC 8617 Andersen, Long, Blank y Kucherawy, julio 2019) conserva la evidencia de autenticación a través de forwarders legítimos que de otro modo romperían SPF/DKIM. Desde el 1 de febrero de 2024, Google y Yahoo imponen requisitos más estrictos para remitentes masivos (≥5.000 mensajes/día): DMARC publicado, SPF y DKIM alineados, registros PTR válidos, TLS, List-Unsubscribe en un clic (RFC 8058), tasa de spam <0,10%. Esta herramienta consulta el DNS público para los tres registros y los analiza — los mismos datos que cualquier servidor receptor de correo usa para puntuar tu dominio.

Cómo comprobar autenticación de correo

Introduce un dominio (no una dirección de correo — solo example.com).
La herramienta consulta los registros DNS SPF, DKIM y DMARC vía Cloudflare DoH y los analiza.
Revisa cada registro y el resumen 'cómo autentica tu dominio el correo', incluyendo la política de alineación y endpoints de reporting.
Arregla ajustes débiles — un DMARC ausente o un SPF con '+all' deja tu dominio abierto al spoofing; no cumplir las reglas de remitentes masivos Google/Yahoo 2024 degradará la entrega a esos buzones.

Casos de uso comunes

Auditar SPF, DKIM y DMARC de un dominio nuevo antes de enviar marketing desde él (especialmente relevante bajo la aplicación de reglas Google/Yahoo 2024 para remitentes ≥5.000 msg/día).
Depurar por qué correo legítimo de un dominio cae en spam — alineación, reputación de IP, patrones de contenido, todo cuenta.
Comprobar la autenticación de correo de un proveedor antes de depender de su transaccional (DMARC p=reject + DKIM alineado = señal fuerte).
Endurecer DMARC de p=none a p=quarantine tras unas semanas de reporting rua= confirmando que no rompe ninguna fuente legítima.

Preguntas frecuentes

¿Cuál es la diferencia entre SPF, DKIM y DMARC?

Tres capas DNS. SPF (RFC 7208) lista IPs autorizadas para enviar. DKIM (RFC 6376) firma el correo saliente con tu clave privada. DMARC (RFC 7489) requiere que SPF o DKIM ALINEEN con la cabecera From — y dice a los receptores qué hacer (none/quarantine/reject) cuando la alineación falla.

¿Qué es la alineación en DMARC y por qué SPF solo falla?

SPF autentica el Return-Path (sobre), no el From visible. Un atacante puede pasar SPF vía un dominio tercero mientras suplanta tu From. DMARC requiere que SPF o DKIM ALINEEN con From — mismo dominio (estricto) o mismo dominio organizacional (relajado). Al menos uno debe pasar Y alinear.

¿Qué hace ARC y por qué se añadió?

ARC (RFC 8617, julio 2019) conserva la autenticación a través de forwarders que modifican mensajes — listas de correo, relays M365. Tres cabeceras (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) capturan el veredicto de cada salto. Los receptores pueden confiar en la cadena hasta el remitente verificado original.

¿Qué cambió para remitentes masivos en febrero 2024?

Google + Yahoo aplican reglas más estrictas para remitentes ≥5.000 msg/día a sus cuentas: DMARC publicado, SPF + DKIM alineados, registros PTR válidos, conexiones TLS, List-Unsubscribe en un clic (RFC 8058), tasa de spam <0,10%. Efectivo 1 feb 2024.

¿Por qué mi correo legítimo sigue cayendo en spam?

La autenticación es necesaria pero no suficiente. La reputación de IP, antigüedad del dominio del remitente, patrones de contenido (acortadores de URL, adjuntos sospechosos), historial de engagement del destinatario y marcas de spam previas, todo cuenta junto a la verificación SPF/DKIM/DMARC.

Cómo SPF, DKIM y DMARC se complementan en capas — y por qué ARC importa para forwarders

Cuando un servidor entrante recibe un mensaje, comprueba: (1) ¿Está la IP que conecta autorizada por el registro SPF del remitente? (2) ¿Verifica la firma DKIM contra la clave pública del dominio d= en la cabecera de firma? (3) ¿Requiere la política DMARC alineación de SPF o DKIM con la cabecera From visible — y qué debe hacer el receptor (none/quarantine/reject) cuando la alineación falla? Sin DMARC, un SPF que pasa en un Return-Path de tercero no prueba que la cabecera From sea legítima; este hueco es lo que hace que SPF por sí solo sea insuficiente contra el spoofing de nombre visible. La capa de reporting también importa: la URI rua= agregada en el registro DMARC recibe reportes XML diarios de los principales proveedores mostrando qué IPs enviaron en nombre de tu dominio y sus resultados de autenticación — invaluable para cazar remitentes no autorizados o servicios mal configurados. La aplicación de remitentes masivos Google/Yahoo de 2024 subió el listón: remitentes ≥5.000 msg/día a esos proveedores deben publicar DMARC y alinear SPF/DKIM o enfrentar degradación de entrega. La tendencia es clara: la autenticación pasó de 'recomendado' a 'requerido para inbox' en los proveedores que gestionan la mayoría del volumen mundial de correo. Los forwarders complican el panorama; las tres cabeceras de ARC (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) conservan el veredicto upstream para que el correo legítimo a través de listas de correo o relays alumni siga pasando DMARC en el destino final.

Detección y validación de registro SPF según RFC 7208 (qualifiers, límite ~10 lookups)
Descubrimiento de selectores DKIM (9 selectores comunes) según RFC 6376
Análisis de política DMARC según RFC 7489 (none / quarantine / reject + alineación + URIs reporting)
Detección de cadena ARC según RFC 8617 (consciente de forwarders)
Comprobación de requisitos remitentes masivos Google/Yahoo 2024 (cumplimiento ≥5.000 msg/día)
Lookup Cloudflare DNS-over-HTTPS con texto íntegro del registro

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (6)

Kitterman, S. (2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. RFC 7208, IETF.
Crocker, D., Hansen, T., & Kucherawy, M. (Eds.) (2011). DomainKeys Identified Mail (DKIM) Signatures. RFC 6376, IETF.
Kucherawy, M., & Zwicky, E. (Eds.) (2015). Domain-based Message Authentication, Reporting, and Conformance (DMARC). RFC 7489, IETF.
Andersen, K., Long, B. (Ed.), Blank, S. (Ed.), & Kucherawy, M. (Ed.) (2019). The Authenticated Received Chain (ARC) Protocol. RFC 8617, IETF (July 2019).
Levine, J. (2017). Signaling One-Click Functionality for List Email Headers. RFC 8058, IETF.
Google + Yahoo Postmaster (2024). Bulk Sender Requirements (≥5,000 messages/day). Effective 1 February 2024 — DMARC + aligned SPF/DKIM + valid PTR + TLS + one-click unsubscribe + spam rate <0.10% (support.google.com/mail/answer/81126).

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Guías relacionadas

Autenticación de email — SPF, DKIM y DMARC explicados correctamenteCómo SPF, DKIM y DMARC funcionan juntos para autenticar email de verdad, con los gotchas que rompen la entregabilidad en producción.

Por Marco B. · Última verificación junio 2026 — corre en tu navegador