SPF, DKIM y DMARC explicados: por qué se rechaza el correo

Tres mecanismos con responsabilidades distintas

SPF publica qué sistemas pueden enviar en nombre de un dominio y se comprueba respecto al dominio técnico Envelope-From. DKIM añade una firma criptográfica cuya clave pública se publica en DNS. DMARC vincula la autenticación con el dominio visible From y publica la política solicitada en caso de fallo.

Un mensaje supera DMARC cuando al menos SPF o DKIM tiene éxito y ese dominio autenticado se alinea con el dominio visible del remitente. La alineación impide que un atacante utilice un remitente visible ajeno simplemente porque controla otro dominio de envío autenticado.

Leer estos registros DNS ilustrativos

Estos registros de example.com ilustran la sintaxis; no son una configuración para copiar a ciegas. La clave DKIM abreviada no es funcional. Los registros reales deben corresponder a los servicios y claves autorizados para el dominio.

• SPF: example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all"
• DKIM: default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
• DMARC: _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
• p=none solicita supervisión sin una política de cuarentena o rechazo basada en DMARC; p=quarantine solicita tratar el mensaje como sospechoso; p=reject solicita rechazarlo.

No establezca reject sin comprobar los remitentes

Un despliegue controlado suele empezar con p=none y un buzón de informes. Los informes revelan fuentes legítimas, sistemas de boletines olvidados y abusos. Corrija las fuentes y la configuración DKIM; después introduzca quarantine o reject gradualmente, con un porcentaje limitado cuando proceda. Endurezca la política solo cuando el tráfico legítimo se alinee de forma fiable.

Publique un solo registro SPF por dominio y respete su límite de consultas DNS. Las cadenas largas de include representan un riesgo operativo. Utilice claves DKIM suficientemente robustas y planifique su rotación. Los subdominios, los reenvíos y los remitentes externos requieren un diseño deliberado, no cambios DNS aislados. Los registros SPF múltiples, los include incorrectos y la falta de alineación son fallos habituales.

La autenticación refuerza la confianza, pero no es un filtro antispam

SPF, DKIM y DMARC mejoran la base para la confianza del destinatario. La autenticación actúa junto con patrones de envío coherentes, listas mantenidas y tasas de quejas reducidas. Superar las comprobaciones no garantiza llegar a la bandeja de entrada, mientras que una configuración incorrecta puede interrumpir gravemente el correo legítimo.

Supervise los cambios DNS, las firmas DKIM y los informes DMARC. Un nuevo servicio de envío solo debe entrar en producción tras probar el dominio del remitente, Return-Path, DKIM y los rebotes. Una firma no válida o ausente requiere investigar el contexto, en lugar de asumir que todo mensaje sin DKIM ha sido necesariamente modificado.