La búsqueda «SPF DKIM DMARC» suele aparecer cuando una empresa quiere reducir la suplantación de su dominio o entender por qué algunos mensajes legítimos llegan al correo no deseado. Los tres mecanismos se publican como registros DNS, pero no hacen lo mismo. SPF identifica servidores autorizados para enviar, DKIM permite comprobar una firma del mensaje y DMARC indica cómo evaluar la alineación de esos resultados con el dominio que ve el destinatario.
Activarlos sin inventariar los sistemas que envían correo puede bloquear facturas, campañas o notificaciones automáticas. Antes de cambiar políticas, localiza todas las plataformas autorizadas, mide los resultados y avanza gradualmente. La meta es proteger el dominio sin castigar los mensajes válidos que usan proveedores externos.
SPF DKIM DMARC cumplen funciones diferentes
SPF publica una lista de remitentes autorizados para un dominio en un registro TXT. El servidor receptor compara la dirección de origen de la conexión con esa política. SPF no comprueba por sí solo que el campo “De” que ve la persona coincida con el dominio autorizado. Un atacante puede aprovechar esa diferencia si el receptor no aplica otras comprobaciones.
DKIM añade una firma criptográfica a determinados encabezados y partes del contenido. El sistema que recibe el mensaje consulta en DNS una clave pública asociada al selector de la firma y comprueba que la firma corresponde al dominio. Si un intermediario modifica partes firmadas, la validación puede fallar; por eso conviene revisar las plataformas que reescriben mensajes o añaden pies legales.
DMARC utiliza el resultado de SPF o DKIM y exige que el dominio autenticado esté alineado con el dominio visible en el campo “De”. También publica una política que orienta al receptor sobre qué hacer si el mensaje no supera las verificaciones. Un mensaje pasa DMARC si al menos uno de los mecanismos SPF o DKIM pasa con la alineación requerida.
| Mecanismo | Qué verifica | Qué publica el dominio |
| SPF | Si el servidor que envía figura como autorizado | Registro TXT SPF con los remitentes permitidos |
| DKIM | Si el mensaje mantiene una firma vinculada al dominio | Clave pública asociada al selector en DNS |
| DMARC | Si SPF o DKIM se alinean con el dominio visible y qué política aplicar | Registro TXT en _dmarc con política e informes opcionales |
Empieza por inventariar los remitentes
Antes de crear registros, anota todos los sistemas que envían correo con tu dominio: Microsoft 365, formularios web, facturación, plataformas de soporte, marketing, gestión de clientes, impresoras o aplicaciones antiguas. No supongas que todo sale desde el proveedor principal. Un servicio que se usa una vez al mes también puede enviar mensajes importantes.
Para cada remitente, identifica quién administra la plataforma, qué dominio utiliza y si permite firmar DKIM con tu dominio. Solicita a cada proveedor sus instrucciones oficiales. No copies el registro SPF de otra empresa ni añadas direcciones IP que no se hayan confirmado. Una política demasiado amplia reduce la utilidad del control.
Comprueba también los subdominios. Un boletín puede usar un subdominio diferente del correo corporativo. Decide si cada uno necesita su propia política SPF, firma DKIM y registro DMARC. La política de un dominio no siempre se aplica de la manera que esperas a todos sus subdominios; revisa las etiquetas y la documentación del DNS actual.
Publica SPF sin romper el envío legítimo
Un dominio debe tener una política SPF válida y coherente con todos sus remitentes. Varias entradas SPF separadas para el mismo nombre pueden provocar errores de evaluación. Microsoft recomienda consolidar los mecanismos autorizados en un único registro y comprobar los límites de consultas DNS definidos por la especificación SPF.
No añadas “include” de proveedores que ya no se usan. Cada mecanismo puede generar consultas adicionales y una política extensa puede superar el límite de evaluación. Revisa los remitentes que ya no pertenecen a la organización y mantén un registro interno de por qué se autorizó cada uno.
Durante la implantación, prueba el envío desde cada plataforma y revisa el encabezado Authentication-Results en los mensajes recibidos. Una conexión puede salir desde una IP distinta a la prevista por el proveedor, especialmente si el servicio usa varios centros de datos. Una prueba desde una sola cuenta no garantiza que todas las rutas funcionen.
Activa DKIM en los proveedores que envían por ti
La mayoría de las plataformas de correo empresarial permite habilitar la firma DKIM para un dominio personalizado. El panel suele indicar uno o más registros CNAME o TXT que deben publicarse en DNS. Copia el nombre y el valor exactos desde el proveedor y confirma que el registro se resuelve desde fuera de la red corporativa.
El selector aparece en la firma DKIM y permite al destinatario localizar la clave pública. Puede haber selectores distintos por proveedor o por rotación de claves. Guarda quién administra cada selector y cómo se cambia. No elimines un registro antiguo si todavía hay mensajes en tránsito que pueden estar firmados con él.
Después de activar DKIM, envía mensajes de prueba desde cada plataforma y comprueba la firma. Si el mensaje pasa DKIM pero DMARC falla, revisa la alineación del dominio d= de la firma con el campo “De”. Un resultado de autenticación correcto y una alineación incorrecta no significan lo mismo.
Despliega DMARC paso a paso
DMARC permite publicar políticas como none, quarantine o reject. La política none solicita informes sin ordenar el rechazo ni el aislamiento de mensajes; sirve para observar el tráfico al inicio. Quarantine pide tratar como sospechosos los mensajes que fallan y reject pide rechazarlos. La aplicación exacta depende del receptor y de su configuración.
Empieza recopilando informes agregados para detectar remitentes desconocidos y errores de alineación. Los informes pueden contener gran cantidad de registros, así que planifica cómo almacenarlos y quién los revisará. No cambies a una política restrictiva hasta que los sistemas legítimos estén identificados y se haya comprobado SPF o DKIM con la alineación necesaria.
Avanza de manera gradual. Corrige primero los remitentes válidos, valida cada proveedor y observa los informes durante un periodo representativo que incluya ciclos de facturación y notificaciones. Luego puedes aumentar la política de forma controlada. No copies un valor “p=reject” de una plantilla sin entender qué sistemas podrían fallar.
La etiqueta rua indica dónde se reciben informes agregados. Usa una dirección preparada para procesar estos mensajes y comprueba que el buzón no se convierte en una cuenta desatendida. Los informes ayudan a identificar fuentes, pero no certifican por sí solos que el dominio esté protegido contra todos los fraudes.
Problemas habituales de alineación
Un proveedor externo puede superar SPF con su propio dominio, pero no alinearlo con el dominio que aparece en “De”. La solución suele ser configurar una ruta de envío con el dominio autorizado o activar una firma DKIM personalizada que se alinee. Un dominio compartido del proveedor no se convierte automáticamente en una identidad válida de tu empresa.
El reenvío de correo también puede alterar el resultado SPF porque el mensaje sale desde un servidor intermedio. DKIM puede conservarse si nadie cambia el contenido firmado, pero una lista de correo que añade un pie o reescribe el asunto puede invalidar la firma. DMARC depende de la alineación, así que revisa los informes antes de cambiar la política global.
Si un mensaje legítimo falla, comprueba primero el dominio del campo “De”, el MAIL FROM, el dominio d= de DKIM y los resultados Authentication-Results. No añadas a toda una plataforma a una lista de permitidos sin revisar el alcance. La excepción amplia puede permitir que otros remitentes suplanten el dominio.
| Síntoma | Causa posible | Comprobación inicial |
| SPF pasa pero DMARC falla | Dominio MAIL FROM distinto al del remitente visible | Revisar alineación SPF |
| DKIM falla | Clave DNS ausente, firma no habilitada o mensaje modificado | Verificar selector y proveedor |
| DMARC pasa en unos mensajes y falla en otros | Múltiples plataformas o rutas de envío | Comparar informes por IP y fuente |
| Mensajes reenviados fallan SPF | El reenvío cambia el servidor que entrega el correo | Revisar encabezados y DKIM conservado |
Seguridad y límites de SPF DKIM DMARC
SPF, DKIM y DMARC reducen ciertos tipos de suplantación, pero no impiden todo phishing. Un atacante puede usar un dominio parecido, una cuenta legítima comprometida o una dirección de un tercero. Mantén también autenticación multifactor, filtros antiphishing, formación y procedimientos para verificar cambios bancarios o solicitudes urgentes.
Una política DMARC no cifra el correo. La confidencialidad depende de otros controles de transporte y de los sistemas usados por remitente y destinatario. Tampoco demuestra que el contenido sea verdadero: solo aporta señales de autenticación del dominio y de alineación.
Revisa los registros después de cambiar de proveedor, añadir una aplicación o mover el DNS. Controla los informes de forma periódica y retira remitentes que ya no se usan. El objetivo no es alcanzar una configuración estricta en una tarde, sino reducir la posibilidad de suplantación sin perder mensajes válidos.
Preguntas frecuentes sobre autenticación de correo
Qué diferencia hay entre SPF DKIM y DMARC
No. SPF valida remitentes autorizados por el dominio de envío, DKIM comprueba una firma y DMARC evalúa la alineación con el campo visible “De” y establece una política para fallos.
DMARC evita todos los correos fraudulentos
No. Ayuda a los receptores a tratar mensajes que suplantan tu dominio, pero no evita que se use un dominio parecido o una cuenta real comprometida. Debe formar parte de una estrategia más amplia de seguridad del correo.
Debo empezar directamente con una política reject
No si todavía no sabes qué sistemas envían con tu dominio. Primero inventaría remitentes, valida SPF y DKIM y observa los informes con una política de monitorización. Endurece la política cuando las fuentes legítimas estén comprobadas.
Puedo tener varios registros SPF
La publicación de varios registros SPF para el mismo nombre puede causar un error de evaluación. Consolida los mecanismos autorizados en la política correspondiente y revisa el límite de consultas de la especificación.
Qué significa alineación DMARC
La alineación compara el dominio autenticado por SPF o el dominio firmante de DKIM con el que aparece en el campo “De”. La configuración puede permitir coincidencia relajada o estricta, según los parámetros publicados.
Los informes DMARC muestran cada mensaje
Los informes agregados suelen resumir resultados por fuente y volumen, no ofrecer una copia completa de cada mensaje. La disponibilidad y el detalle de informes forenses varían entre receptores.
SPF DKIM DMARC funcionan mejor cuando se despliegan con inventario de remitentes, pruebas y revisión de informes. Una política más estricta solo protege el dominio si las plataformas legítimas ya están autorizadas y alineadas.
Revisar cambios en DNS sin interrumpir el correo
Los registros DNS pueden tardar en propagarse según el TTL y la caché de los resolvers. Antes de cambiar la política DMARC, comprueba que el registro publicado sea el que esperabas desde más de una herramienta de consulta y que no exista una entrada anterior con el mismo nombre. Un error de sintaxis puede hacer que los receptores ignoren la política o la interpreten de forma inesperada.
Conserva una copia del registro anterior y anota quién pidió el cambio, qué proveedor lo necesita y cómo se verificó. Si se añade una nueva plataforma de correo, prueba primero mensajes internos y externos. Asegúrate de que no se publica un segundo registro SPF en lugar de integrar el nuevo remitente en la política ya existente.
El equipo que recibe los informes agregados debe distinguir los fallos legítimos de los intentos de suplantación. No uses una cifra aislada de fallos para endurecer la política de toda la organización: agrupa por proveedor, volumen, dominio alineado y fecha. Si un envío legítimo falla, corrige su autenticación antes de crear una excepción general.
Un despliegue gradual de SPF DKIM DMARC evita bloquear notificaciones importantes mientras mejora la protección del dominio.
Cuando se revisa SPF DKIM DMARC después de una migración de correo, compara el dominio visible, los registros DNS y las cabeceras Authentication-Results de mensajes reales. Un cambio de plataforma puede alterar las direcciones de envío y las firmas aunque el usuario siga viendo el mismo remitente. Documenta las fuentes legítimas antes de endurecer la política.