La autenticación de correo es una de las partes más importantes de la ejecución de entrega de correos y, a la vez, una de las más malentendidas.
La mayoría de los remitentes sabe que necesita SPF, DKIM y DMARC, pero pocos entienden qué hace exactamente cada uno, cómo trabajan juntos o por qué un correo puede acabar en spam aunque los tres estén configurados.
Parte de la confusión viene de tratar la autenticación como una solución de entregabilidad cuando no lo es. La autenticación ayuda a los proveedores de correo a verificar quién envió un mensaje y si es de confianza. Sin ella, tus correos pueden ser rechazados o filtrados. Con ella, simplemente cumples con un requisito básico.
En esta guía aprenderás qué hace cada método de autenticación, cómo funcionan en conjunto, cómo configurarlos bien y los errores comunes que provocan fallos de autenticación aunque los registros parezcan estar bien configurados.
¿Qué es la autenticación de correo electrónico?
La autenticación de correo electrónico es un conjunto de métodos que permiten a los proveedores receptores, como Gmail y Outlook, verificar que un correo proviene realmente del dominio que dice ser y que no ha sido suplantado ni alterado en el camino.
Funciona mediante registros DNS que publica el dominio remitente:
- El SPF enumera los servidores autorizados para enviar.
- El DKIM añade una firma criptográfica que confirma que el mensaje no ha sido modificado.
- El DMARC establece la directiva que vincula ambos a la dirección De (From) visible y dice a los receptores qué hacer cuando falla una comprobación.
Juntos, estos protocolos confirman la identidad del remitente, una de las señales que los proveedores valoran antes de decidir si aceptan, filtran o rechazan el correo entrante.
| Lo que demuestra la autenticación |
Lo que no demuestra la autenticación |
| El servidor de envío está autorizado para tu dominio (SPF). |
Que los proveedores confían en tu dominio (reputación). |
| El mensaje no fue alterado durante el envío (DKIM). |
Que los destinatarios quieren tus correos o interactúan con ellos (reputación). |
| Tu dominio De (From) coincide con lo que pasó el filtro (DMARC). |
Que tu contenido no activará los filtros de spam (contenido). |
| Cumples con los requisitos mínimos de entrada del proveedor. |
Que tu correo llegará a la bandeja de entrada. |
Los 3 métodos principales de autenticación de correo
La autenticación de correos se basa en tres protocolos que trabajan juntos para comprobar quién envía un email y si se puede confiar en ese mensaje. Cada uno cumple una función diferente, y entender cómo se combinan es clave para solucionar problemas de entregabilidad y autenticación.
SPF (Sender Policy Framework)
SPF (Sender Policy Framework) es un método de autenticación de correos que usa un registro TXT de DNS para indicar qué servidores y direcciones IP tienen autorización para enviar emails en nombre de tu dominio.
Cuando llega un correo, el proveedor de la bandeja de entrada consulta el registro SPF del dominio remitente y compara la dirección IP del servidor que lo envía con la lista de remitentes autorizados. Si el servidor está autorizado, el SPF se aprueba. Si no lo está, el SPF falla.
El propósito del SPF es confirmar que el servidor que envía el correo tiene permiso para hacerlo en nombre de ese dominio. No verifica el contenido del mensaje, la reputación, la interacción ni si el correo debe llegar a la bandeja de entrada.
DKIM (DomainKeys Identified Mail)
DKIM (DomainKeys Identified Mail) es un método de autenticación de correos que añade una firma criptográfica a tus emails salientes mediante un par de claves (pública y privada), para que los proveedores receptores puedan confirmar que el mensaje fue firmado por tu dominio y no sufrió alteraciones en el camino.
Cuando llega un correo, el proveedor de la bandeja de entrada busca la clave pública publicada en el DNS de tu dominio bajo un selector específico y la usa para verificar la firma que añadió tu plataforma de envío. Si la firma es válida y el mensaje no ha cambiado, el DKIM se aprueba. Si las claves no coinciden o el mensaje fue alterado, el DKIM falla.
El propósito del DKIM es confirmar que el email fue firmado por un dominio autorizado en la firma DKIM y que las partes firmadas del mensaje no se modificaron después de enviarlo. Por sí solo, no demuestra que el dominio visible del campo De (From) coincida con el dominio autenticado. De esa alineación se encarga DMARC.
DMARC (y la duda entre MAIL FROM y la cabecera From:)
DMARC (Domain-based Message Authentication, Reporting and Conformance) es un método de autenticación de correos que utiliza un registro DNS para vincular los resultados de tu SPF y DKIM con el dominio que aparece en tu dirección De (From), y para indicar a los proveedores receptores qué hacer cuando la autenticación falla.
Cuando llega un correo, el proveedor de la bandeja de entrada comprueba si el dominio que pasó el SPF o el DKIM coincide con el dominio del campo De (From) que ve el destinatario. Si coinciden, DMARC se aprueba. Si no, DMARC falla y el proveedor aplica la política que hayas publicado: p=none (solo monitorizar), p=quarantine (enviar a spam) o p=reject (bloquear el mensaje).
El propósito de DMARC es confirmar que el dominio autenticado coincide con el que ve tu destinatario (lo que evita que otros suplanten tu identidad) y darte el control sobre cómo se manejan los fallos.
| Factor |
SPF |
DKIM |
DMARC |
| Nombre completo |
Sender Policy Framework |
DomainKeys Identified Mail |
Domain-based Message Authentication, Reporting & Conformance |
| Propósito principal |
Verifica que el servidor de envío está autorizado para enviar correo en nombre del dominio |
Verifica que el mensaje no ha sido alterado durante el tránsito |
Verifica la alineación de dominios e indica a los receptores cómo gestionar los fallos de autenticación |
| Qué verifica |
Servidor de envío o dirección IP |
Integridad del mensaje e identidad del remitente mediante una firma criptográfica |
Si SPF y/o DKIM se aprobaron y coinciden con el dominio visible del campo De (From) |
| Protege contra |
Envios no autorizados desde servidores no aprobados |
Manipulación de mensajes y firmas falsificadas |
Suplantación de identidad y de dominio |
| Publicado como |
Registro DNS TXT |
Registro DNS TXT (clave pública) |
Registro DNS TXT |
| Evalúa |
Infraestructura de envío |
Contenido del mensaje y firma |
Resultados de autenticación y alineación de dominios |
| ¿Usa DNS? |
Sí |
Sí |
Sí |
| Es válido cuando |
El servidor de envío está autorizado en el registro SPF |
La firma DKIM es válida con la clave publicada |
SPF o DKIM son válidos y coinciden con el dominio del campo De (From): |
| Falla cuando |
El servidor de envío no está autorizado |
Falta la firma, no es válida o ha sido modificada |
Ni SPF ni DKIM coinciden con el dominio del campo De (From): |
| ¿Visible para los destinatarios? |
No |
No |
No |
| ¿Ofrece informes? |
No |
No |
Sí, a través de informes agregados y forenses |
| Opciones de aplicación |
Ninguno |
Ninguno |
p=none, p=quarantine, p=reject |
| ¿Puede funcionar solo? |
Sí, pero ofrece protección limitada |
Sí, pero ofrece protección limitada |
No. DMARC depende de SPF y/o DKIM |
| Problema más común |
Falta de fuentes de envío o límites de consultas SPF |
Selector o configuración de firma incorrectos |
Fallos de alineación entre los dominios autenticados y los visibles |
| Responde a esta pregunta |
¿Tiene este servidor permiso para enviar en nombre de este dominio? |
¿Se ha alterado este mensaje y lo ha firmado este dominio? |
¿Coinciden los dominios autenticados con el dominio que ve el destinatario? |
| Su papel en la deliverability moderna |
Base de la autenticación |
Base de la autenticación |
Capa de directivas y cumplimiento exigida por los principales proveedores de correo |
| Requerido por las normas para envíos masivos de Gmail, Yahoo y Outlook |
Sí |
Sí |
Sí |
Comprueba que tus registros realmente funcionen, no solo que existan.
Una consulta DNS solo confirma que un registro está publicado. No te dice si SPF y DKIM pasan cuando Gmail y Outlook reciben tu correo. El comprobador de SPF y el comprobador de DKIM gratuitos de MailReach realizan pruebas de extremo a extremo y señalan los problemas de SPF, DKIM, DMARC, listas negras y DNS inverso en un solo informe.
BIMI (y por qué es opcional para el cold email B2B)
BIMI (Brand Indicators for Message Identification) es un estándar de correo electrónico que muestra el logotipo verificado de tu marca junto a tus mensajes en las bandejas de entrada compatibles, pero solo una vez que tu dominio aplica DMARC.
Cuando se recibe un correo, los proveedores compatibles comprueban que tu dominio aplica DMARC (p=quarantine o p=reject) y buscan un registro BIMI en tu DNS que apunte a tu logotipo. Si se cumplen esas condiciones, tu logotipo aparece junto al mensaje. La mayoría de los proveedores principales también exigen un Certificado de Marca Verificada (VMC) que demuestre que eres dueño del logotipo antes de mostrarlo.
El propósito de BIMI es el reconocimiento visual de la marca en la bandeja de entrada, no la deliverability. No afecta a la reputación del remitente, a tus resultados de autenticación ni a si tu correo llega a la bandeja de entrada. Para el cold email B2B es opcional y de baja prioridad. Es una capa de branding, no una palanca de deliverability, así que si eres un remitente saliente y estás decidiendo dónde invertir tiempo, BIMI está casi al final de la lista.
Cómo funcionan juntos SPF, DKIM y DMARC
SPF, DKIM y DMARC están diseñados para funcionar como una cadena, donde cada uno resuelve una parte diferente del problema de la autenticación de correos.
- SPF verifica que el servidor que envía el correo esté autorizado para hacerlo en nombre del dominio.
- DKIM verifica que el mensaje no haya sido alterado después de ser enviado.
- DMARC se sitúa por encima de ambos y comprueba si el dominio que pasó SPF o DKIM coincide con el dominio que el destinatario ve en la dirección De (From:).
Un correo no necesita pasar tanto SPF como DKIM para que DMARC sea exitoso. Solo necesita que uno de ellos pase y se alinee con el dominio visible del campo De (From:). Si ninguno se alinea, DMARC falla, incluso si SPF o DKIM pasaron por separado.
Por esto los problemas de autenticación pueden resultar confusos. Un mensaje puede pasar SPF, pasar DKIM y aun así fallar en DMARC porque los dominios autenticados no se alinean con la dirección De (From:). Al revés, un mensaje puede fallar en SPF pero aun así pasar DMARC si DKIM pasa y se alinea correctamente.
Juntos, estos tres estándares ayudan a los proveedores de correo a verificar quién envió el mensaje, si fue modificado en tránsito y si se puede confiar en la identidad del remitente. Si los tres no trabajan en conjunto, los proveedores confían menos en el mensaje y es más probable que lo filtren, lo manden a spam o lo rechacen.
Requisitos de los proveedores: Google, Yahoo y Microsoft
Desde febrero de 2024, Google y Yahoo han convertido la autenticación en un requisito básico para los remitentes masivos. Los remitentes masivos necesitan SPF y DKIM, una política DMARC de al menos p=none, autenticación alineada, tasas bajas de quejas por spam y un proceso de baja funcional para correos de marketing o suscripciones.
Microsoft también ha introducido requisitos para remitentes de alto volumen que envían más de 5,000 correos al día a direcciones de usuarios de Outlook.com, incluidos outlook.com, hotmail.com, live.com y msn.com. Estos requisitos incluyen el cumplimiento de SPF, DKIM y DMARC.
La conclusión práctica es sencilla: aunque técnicamente no superes los límites de envío masivo, la autenticación ya es imprescindible. Debes tener configurados correctamente SPF, DKIM y DMARC antes de escalar cualquier envío importante.
Cómo configurar y verificar la autenticación de correos (Paso a paso)
La autenticación de correos funciona mejor cuando SPF, DKIM y DMARC se configuran juntos. Como cada protocolo se basa en los demás, lo lógico es configurarlos en un orden específico.
Paso 1: Identifica tus fuentes de envío de correos
Empieza por hacer una lista de todas las plataformas que envían correos usando tu dominio. Esto normalmente incluye:
- Tu proveedor de correo (Google Workspace, Microsoft 365, etc.)
- Plataformas de marketing
- Sistemas de CRM
- Herramientas de prospección en frío
- Plataformas de asistencia y soporte
- Sistemas de facturación y cobros
- Cualquier otra aplicación que envíe correos en tu nombre
Tener un inventario completo facilita configurar la autenticación correctamente y evita que se pasen por alto remitentes legítimos.
Paso 2: Configura SPF
Publica un registro SPF en tu DNS que autorice a los servidores permitidos para enviar correos desde tu dominio.
Al crear tu registro SPF:
- Publica un único registro TXT de SPF para el dominio
- Añade cada plataforma de envío legítima
- Usa los mecanismos de inclusión recomendados por el proveedor cuando estén disponibles
- Revisa el registro cada vez que añadas una nueva herramienta de envío
- Mantén el registro preciso y actualizado
El registro debe incluir todas las fuentes de envío legítimas y mantenerse preciso y actualizado a medida que incorpores nuevas herramientas.
Paso 3: Configura DKIM
Activa DKIM en cada plataforma que envíe correos en tu nombre.
DKIM permite que los proveedores de correo verifiquen que un mensaje no ha sido modificado después de ser enviado.
Para cada plataforma de correo:
- Genera un par de claves DKIM dentro de la plataforma
- Publica la clave pública en el DNS
- Usa el selector proporcionado por el proveedor
- Activa la firma DKIM para los correos salientes
- Comprueba que las firmas DKIM se validen correctamente en los mensajes entregados
La mayoría de los proveedores generan un registro DKIM que publicas en el DNS. Una vez configurado, los correos salientes se firman automáticamente para que los servidores de recepción puedan verificar que el mensaje está íntegro.
Paso 4: Configura DMARC
Publica un registro DMARC para indicar a los proveedores cómo deben tratar los mensajes que no pasen la autenticación.
Empieza con:
Antes de pasar a una política más estricta:
- Confirma que todos los remitentes legítimos estén autenticados
- Soluciona los fallos de alineación
- Valida los resultados de SPF y DKIM en todas las plataformas de envío
La mayoría de las organizaciones empiezan con una política de supervisión (p=none) para revisar los resultados de autenticación antes de pasar a políticas más estrictas como p=quarantine o p=reject.
Paso 5: Verifica los resultados de la autenticación
Tras la configuración, comprueba que SPF, DKIM y DMARC estén funcionando correctamente en los correos entregados.
Verifica que:
- SPF se supere en los mensajes entregados
- DKIM se valida correctamente en los correos entregados
- DMARC se valida y se alinea correctamente
- La autenticación se mantiene en buen estado después de añadir nuevas herramientas o proveedores
Un registro DNS por sí solo solo confirma que la configuración existe. La verificación confirma que los proveedores de correo pueden autenticar con éxito tu email en condiciones reales de recepción.
Verificar en el DNS no es lo mismo que verificar en la bandeja de entrada.
Este es el paso que la mayoría de los remitentes se saltan. La prueba de deliverability gratuita de MailReach envía tu correo a bandejas de entrada de prueba en entornos de Google, Microsoft y Yahoo, y luego te muestra dónde cae: en la bandeja de entrada, en spam o en carpetas filtradas específicas de cada proveedor, como Promociones de Gmail. También obtienes los resultados de SPF, DKIM y DMARC del mensaje recibido, además de una lista priorizada con lo que debes solucionar primero.
Errores comunes de autenticación de email (y cómo solucionarlos)
La mayoría de los fallos de autenticación de correo se deben a pequeños errores de configuración que pasan desapercibidos hasta que los emails empiezan a caer en spam, fallan en las comprobaciones de autenticación o son rechazados por completo.
Los errores que se muestran a continuación son los que los remitentes encuentran más a menudo. Entender cómo ocurren hace que sea mucho más fácil identificarlos, solucionarlos y prevenirlos antes de que afecten a tu deliverability.
El registro SPF supera el límite de 10 búsquedas
SPF permite un máximo de 10 búsquedas DNS. Cada plataforma de email que autorizas mediante una declaración include: consume parte de ese límite. A medida que se añaden más herramientas con el tiempo, es fácil superar el tope sin darte cuenta.
Cuando se supera el límite, los proveedores de correo ya no pueden evaluar completamente el registro SPF, lo que hace que las comprobaciones SPF fallen aunque el registro siga existiendo en el DNS.
Cómo solucionarlo:
- Revisa cada plataforma que actualmente envíe correos para tu dominio.
- Elimina las declaraciones include: obsoletas o que ya no uses.
- Consolida los servicios de envío que se solapen siempre que sea posible.
- Monitorea el número de búsquedas cada vez que añadas una nueva herramienta de envío.
- Prueba el SPF después de cada cambio para confirmar que sigue pasando.
Faltan registros DKIM para las nuevas plataformas de envío
DKIM se configura por separado para cada plataforma de envío. Un registro DKIM que funciona para Google Workspace no autentica automáticamente el correo enviado a través de tu CRM, plataforma de outreach, sistema de facturación o helpdesk.
Esto suele pasar cuando se conecta una herramienta nueva y empieza a enviar de inmediato, pero nunca se completa su configuración DKIM. Algunos correos pasan la autenticación mientras que otros fallan, lo que hace que el problema sea difícil de detectar.
Cómo solucionarlo:
- Crea un registro DKIM para cada plataforma de envío que use tu dominio.
- Publica el selector exacto y la clave pública proporcionados por cada plataforma.
- Verifica DKIM después de la configuración en lugar de dar por hecho que el registro funciona.
- Lleva un inventario de todos los sistemas de envío y sus selectores DKIM.
- Vuelve a comprobar DKIM siempre que un proveedor rote o actualice sus claves.
Publicar un registro DMARC sin comprobar la alineación
DMARC solo se aprueba cuando SPF o DKIM se alinean con el dominio en la dirección De: visible.
Un registro puede existir en el DNS y aun así fallar en DMARC si el dominio autenticado no coincide con el dominio que ven los destinatarios.
Cómo solucionarlo:
- Confirma que SPF se alinea con el dominio De: visible.
- Confirma que DKIM firma usando el mismo dominio que se muestra en la cabecera De:.
- Revisa los informes DMARC para detectar fallos de alineación.
- Prueba correos reales para verificar que DMARC se aprueba en la entrega.
- Soluciona los problemas de alineación antes de pasar de p=none.
Pasar a p=Reject demasiado pronto
La aplicación de DMARC está diseñada para ser gradual. Pasar directamente a p=reject antes de entender cada fuente de envío legítima puede bloquear los correos reales de la empresa.
El problema suele aparecer cuando herramientas olvidadas, sistemas de terceros o aplicaciones internas siguen enviando correos que no se han autenticado correctamente.
Cómo solucionarlo:
- Empieza con p=none y recopila informes de DMARC.
- Identifica cada sistema que envía correos bajo tu dominio.
- Resuelve primero los fallos de autenticación y alineación.
- Considera usar p=quarantine o un despliegue gradual antes de p=reject si quieres una transición más segura.
- Aplica el rechazo solo después de que un monitoreo constante confirme que todo el correo legítimo pasa.
Confiar únicamente en las comprobaciones de DNS
Una consulta de DNS solo confirma que un registro existe. No demuestra que los proveedores de correo autentiquen con éxito tus correos cuando los reciben.
Esto crea una falsa sensación de seguridad. Todo se ve correcto en el DNS mientras los mensajes siguen cayendo en spam o fallando en las comprobaciones de autenticación durante la entrega.
Cómo solucionarlo:
- Envía correos de prueba a bandejas de entrada de Gmail y Outlook.
- Verifica los resultados de SPF, DKIM y DMARC en el mensaje recibido.
- Haz pruebas después de cada cambio en el DNS o en la plataforma de envío.
- Monitorea los resultados de autenticación regularmente, no solo durante la configuración.
- Usa pruebas de ubicación en la bandeja de entrada y de autenticación para validar el rendimiento en el mundo real.
Usar un subdominio para la prospección en frío
Muchos emisores usan un subdominio para el cold outreach pensando que así aíslan por completo el riesgo. Aunque la separación ayuda a nivel operativo, los proveedores de correo siguen pudiendo asociar los subdominios con el dominio principal.
Si tu outreach genera quejas o poca interacción, las señales de reputación pueden acabar afectando a otros correos de la marca.
Cómo solucionarlo:
- Usa un dominio secundario independiente para el cold outreach en lugar de tu dominio principal de empresa. Mantenlo limpio: evita guiones, números y extensiones (TLD) extrañas, y autentícalo por tu cuenta antes de empezar a enviar.
- Autentica el dominio secundario de forma independiente.
- Haz el email warmup del dominio de outreach antes de subir el volumen.
- Mantén separados el tráfico de marketing, el transaccional y el de outreach.
- Protege el dominio principal de tu negocio de riesgos innecesarios en la reputación.
Preocuparse por las listas negras en lugar de arreglar la reputación
Estar en una lista negra suele asustar, pero la mayoría de las listas públicas influyen muy poco en si tus correos llegan a la bandeja de entrada de Gmail y Outlook. Los proveedores de correo modernos se fían sobre todo de sus propios sistemas de reputación, de las señales de interacción y de los datos de quejas.
Muchos pasan días investigando por qué están en una lista negra cuando el verdadero problema es una mala reputación como remitente.
Cómo solucionarlo:
- Comprueba si la lista negra en cuestión es realmente la que usan los grandes proveedores de correo.
- Céntrate primero en la tasa de quejas, la interacción y la calidad de tus listas.
- Mejora la autenticación y tus prácticas de envío.
- Controla dónde aterriza tu correo en vez de obsesionarte solo con las listas negras.
- Tómate las revisiones de listas negras como una señal para diagnosticar, no como tu métrica principal de entregabilidad.
Autenticación de correo frente a llegada a la bandeja de entrada
Los proveedores de correo tratan cada vez más la autenticación como un requisito básico y no como una muestra de confianza. A medida que los filtros se vuelven más listos, la brecha entre el correo autenticado y el que llega a la bandeja de entrada seguirá creciendo. Hoy en día, los proveedores prestan más atención que nunca a la reputación, la interacción, la consistencia y el comportamiento de envío.
Por eso los que consiguen mejores resultados ven la autenticación de emails como parte de un proceso continuo de entregabilidad. Cada nueva plataforma de envío, cambio de dominio, herramienta de marketing o campaña de outreach es una nueva oportunidad para que la autenticación se desconfigure sin que nadie se dé cuenta.
El siguiente paso es comprobar sin parar que todo sigue funcionando bien en condiciones reales de recepción y pillar los fallos antes de que lo hagan los proveedores.
Cada nueva herramienta, dominio o campaña es una ocasión para que SPF, DKIM o DMARC dejen de estar alineados sin que te enteres. Haz un test de entregabilidad gratuito con MailReach para ver dónde caen tus correos ahora mismo, y combínalo con un email warmup para crear esa reputación de remitente que la autenticación por sí sola no te da.
Preguntas frecuentes
¿Cuáles son los tres métodos principales de autenticación de correo?
SPF, DKIM y DMARC. SPF lista qué servidores pueden enviar en nombre de tu dominio, DKIM añade una firma que demuestra que el mensaje no ha sido modificado, y DMARC vincula ambos a tu dominio visible De: (From:) y le dice a los receptores qué hacer si algo falla.
¿Necesito DMARC si solo envío desde Google Workspace?
Sí. Se recomienda para cualquier emisor y es obligatorio si envías en gran volumen. Google Workspace es la plataforma desde la que envías; publicar una directiva DMARC es cosa tuya, no algo que Workspace haga automáticamente.
¿Qué diferencia hay entre SPF, DKIM y DMARC?
El SPF autoriza a los servidores de envío. El DKIM firma el mensaje para que los receptores puedan verificar que no ha sido alterado. El DMARC establece la política y exige que haya alineación entre lo que pasó la validación y el dominio del campo From: que ve tu destinatario.
¿Cuánto tiempo debo estar en p=none antes de pasar a p=reject?
Quédate en p=none hasta que los reportes de DMARC demuestren que tienes controlado cada sistema legítimo que envía correos bajo tu dominio. Cambiarse antes de tiempo arriesga a bloquear correos reales de la empresa.
¿La autenticación de correos mejora la deliverability?
Es obligatoria para competir y no puedes llegar a la bandeja de entrada sin ella, pero por sí sola no mejora el posicionamiento. De eso se encargan la reputación y el contenido. La autenticación abre la puerta; la reputación y el contenido ganan la bandeja de entrada.
Mejores Prácticas de Email
