La autenticación del correo con SPF, DKIM y DMARC ya es una tarea básica. Si tu dominio envía correo empresarial en 2025 o 2026, estos registros influyen en el tratamiento que recibe, junto con muchas otras señales. Para entender primero el conjunto de herramientas, consulta correo empresarial para pequeñas empresas.
El problema es que muchos equipos creen que el correo falla solo por el contenido. A veces es así, pero con frecuencia el dominio está mal configurado: un SPF incorrecto, una clave DKIM ausente o una política DMARC sin publicar. Entonces pueden aparecer incidentes: rechazos en Outlook, limitación de frecuencia en Gmail, campañas en spam de Yahoo y complicaciones con el reenvío.
La solución es sencilla en teoría y laboriosa en la práctica. SPF indica qué IP puede enviar para el dominio de sobre real. DKIM acredita que el mensaje fue firmado y que los datos firmados no cambiaron fuera de lo admitido por su canonicalización. DMARC solicita un tratamiento cuando fallan las comprobaciones y evalúa si el dominio From visible está alineado con el dominio autenticado. Una configuración correcta mejora la base técnica, sin garantizar entrega ni bandeja de entrada.
Qué hacen realmente SPF, DKIM y DMARC
Es un sistema de tres capas que los proveedores de buzones usan entre otras señales para evaluar mensajes. SPF comprueba la ruta, DKIM la firma y DMARC la alineación y la política. En los contextos donde las reglas de envío masivo lo exigen, conviene publicar los tres; para que DMARC pase basta con un resultado SPF o DKIM satisfactorio y alineado.
| Protocolo | Función principal | Qué comprueba | Fallo habitual |
|---|---|---|---|
| SPF | Autorización | Si la IP de envío está permitida para el dominio de sobre | Demasiadas consultas DNS o cambios producidos por el reenvío |
| DKIM | Integridad | Si el mensaje fue firmado y conservaron su validez los datos firmados | Selector incorrecto, clave obsoleta o contenido modificado en tránsito |
| DMARC | Política y alineación | Si SPF o DKIM pasó y quedó alineado con el dominio From visible | Una herramienta SaaS envía con su dominio y no se alinea |
Recuerda esto: DMARC no exige que SPF y DKIM pasen a la vez. Exige que uno pase y esté alineado con el dominio From que ve el destinatario.
SPF: quién puede enviar correo para tu dominio
La primera capa es SPF, una lista de autorización para remitentes. El servidor receptor examina el dominio MAIL FROM, o dominio de sobre, consulta su registro SPF TXT y determina si la IP conectada está autorizada. Es rápido y útil, pero también frágil: el reenvío y las cadenas include excesivas pueden hacerlo fallar.
SPF se publica en DNS como registro TXT. Un ejemplo es:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allEsta línea significa:
v=spf1declara el tipo de registro.include:remite a la infraestructura de envío publicada por otro dominio.-allindica que todo lo demás debe fallar.
Muchas configuraciones encuentran aquí su primer límite: las 10 consultas de RFC 7208. En la cuenta intervienen mecanismos y modificadores que generan consultas, además de la evaluación anidada detrás de un include. Al superar el límite, el receptor puede devolver PermError; la evaluación SPF no se ha completado correctamente.
Cancelaste un CRM hace dos años, pero dejaste su
include:. La plataforma de marketing añadió tres y el soporte añadió otro. Todo parecía correcto hasta que los receptores evaluaron toda la cadena.
SPF también puede fallar al reenviar. Si una universidad reenvía tu mensaje a Gmail, Gmail puede ver como origen el servidor de la universidad. Un SPF correcto en la ruta directa puede fallar tras el reenvío. Por eso SPF por sí solo no basta.
Si utilizas TrekMail para enviar, su documentación muestra el include requerido y cómo integrarlo sin duplicar registros: registros DNS necesarios.
DKIM: quién firmó el mensaje y si cambió
La segunda capa es DKIM. Firma el mensaje con una clave privada y permite validar la firma mediante una clave pública en DNS. A diferencia de SPF, DKIM puede conservarse al reenviar si la firma sigue siendo válida y los datos firmados respetan la canonicalización. Si el cuerpo o los encabezados firmados cambian demasiado, DKIM falla.
Los registros DKIM se publican bajo un selector, como selector1._domainkey.example.com o dkim._domainkey.example.com. El remitente firma con el selector correspondiente y el receptor obtiene la clave pública de DNS para validar la firma.
Un valor DNS típico es:
Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...Los fallos operativos suelen ser previsibles:
- Rotaste las claves, pero el servidor sigue usando el selector antiguo.
- Cambiaste de proveedor y no publicaste la nueva clave pública.
- El proveedor DNS alteró el valor TXT largo.
- Una lista de correo reescribió el cuerpo y rompió la firma.
En una configuración sólida conviene usar claves de 2048 bits como valor predeterminado cuando el servicio y el DNS sean compatibles, salvo que exista un motivo concreto para otra opción. Todavía hay sistemas heredados de 1024 bits, pero es preferible planificar su sustitución compatible en 2026.
En los planes de pago de TrekMail, el correo del dominio se firma con su clave DKIM al usar SMTP administrado, según la configuración vigente. Esto puede dar a DMARC una ruta alineada tras ciertos reenvíos si la firma permanece válida. Para investigar fallos, consulta Mis mensajes van a spam.
DMARC: las reglas que orientan al receptor
La capa final es la política DMARC. Se apoya en SPF y DKIM, solicita al receptor un tratamiento cuando falla la autenticación y comprueba la alineación entre From visible y los dominios usados por SPF o DKIM. Sin una ruta satisfactoria y alineada, DMARC no pasa.
Publica el registro en _dmarc.example.com. Empieza de forma prudente:
v=DMARC1; p=none; rua=mailto:dmarc@example.comAvanza cuando dispongas de pruebas suficientes:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comv=DMARC1; p=reject; rua=mailto:dmarc@example.comp=none solicita no aplicar restricciones DMARC, pero los filtros locales siguen activos. p=quarantine solicita tratar los fallos como sospechosos. p=reject solicita su rechazo. Son políticas solicitadas, no garantías de la acción ni de la entrega.
La otra dificultad es la alineación. Por ejemplo:
Visible From:
newsletter@yourcompany.com
Return-Path:bounce.vendor.com
DKIM domain:vendor.com
SPF puede pasar. DKIM puede pasar. DMARC aun así falla porque ninguno se alinea con yourcompany.com.
Es un fallo común con Mailchimp, HubSpot, Zendesk y CRM: el panel del servicio aparece correcto, pero el dominio no está alineado en mensajes reales. Las directrices actuales de Google para remitentes masivos a cuentas personales de Gmail exigen configurar SPF y DKIM y alinear al menos uno con From para el correo directo. También piden un registro DMARC mínimo, aunque sea p=none: preguntas frecuentes de Google para remitentes. Comprueba siempre la aplicabilidad y versión vigentes.
SPF frente a DKIM y DMARC: ¿cuál importa más?
Cada protocolo desempeña una función diferente, así que no hay uno que sustituya a los demás. En la práctica, una firma DKIM válida suele resistir mejor ciertos reenvíos, SPF sigue siendo necesario en muchos requisitos y DMARC añade política y alineación. La configuración adecuada depende de las rutas y de las reglas aplicables.
| Pregunta | SPF | DKIM | DMARC |
|---|---|---|---|
| ¿Comprueba la IP de envío? | Sí | No | Indirectamente mediante SPF |
| ¿Comprueba la integridad del mensaje? | No | Sí | Indirectamente mediante DKIM |
| ¿Resiste bien el reenvío? | No | Normalmente, si la firma conserva su validez | Solo si SPF o DKIM permanece alineado |
| ¿Publica una política para receptores? | No | No | Sí, como política solicitada |
| ¿Ayuda a frenar la suplantación? | Parcialmente | Parcialmente | Sí, cuando se aplica junto con otras señales |
En configuraciones sencillas, los tres mecanismos son manejables. Con un solo servidor y sin remitentes SaaS, SPF y DKIM suelen ser directos. Al combinar soporte, boletines, CRM y reenvío en un dominio, los informes DMARC ayudan a descubrir qué está alineado realmente.
Por qué el reenvío y las listas todavía provocan fallos extraños
El reenvío puede romper SPF porque el servidor reenviador entrega el mensaje. DKIM puede conservar una ruta válida, pero también falla si un intermediario modifica el cuerpo o un encabezado firmado de forma incompatible. El resultado depende de la ruta y de la firma concreta.
Por eso una configuración correcta sobre el papel puede fallar en destinatarios reales. SPF puede fallar al cambiar la IP, DKIM porque una lista añadió un pie y DMARC porque desaparecieron ambas rutas alineadas.
Cuando los tres fallan en un mensaje reenviado, ARC permite que intermediarios registren el historial que observaron. El receptor puede usarlo en su decisión local, pero ARC no conserva ni convierte automáticamente un resultado DMARC. Las directrices de Google tratan de forma específica el alineamiento DMARC en tráfico indirecto y recomiendan encabezados ARC para ese correo. Como remitente, normalmente no configuras ARC: mantén DKIM válido y evita cadenas frágiles. Si el reenvío es central, consulta reenvío de correo.
Comprobaciones ocultas que aún perjudican la entrega
Publicar registros válidos no garantiza la bandeja de entrada. Los proveedores también consideran DNS inverso, TLS, quejas y mecanismos de baja. SPF, DKIM y DMARC son la base, no todo el sistema.
- DNS inverso confirmado hacia delante: la IP necesita PTR y ese nombre debe resolver de vuelta a la misma IP. Google incluye DNS directo e inverso válidos entre sus requisitos aplicables.
- TLS: los grandes proveedores esperan correo mediante TLS; Google menciona el correo sin TLS entre las posibles causas de fallos temporales o permanentes.
- Quejas por spam: la orientación actual de Google para el tráfico aplicable recomienda mantener la tasa por debajo de 0.1% y evitar que alcance 0.3%.
- Baja con un clic: para correo promocional sujeto a esos requisitos, los proveedores esperan encabezados compatibles con RFC 8058, además del enlace visible.
Al preparar un dominio nuevo, estas señales importan aún más. Una campaña brusca y una lista deficiente pueden perjudicar una reputación que todavía tiene poco historial.
Cómo configurar SPF, DKIM y DMARC sin afectar a producción
Primero inventaría todos los remitentes, publica registros coherentes, verifícalos con mensajes reales y pasa gradualmente de observación a aplicación. Omitir el inventario puede interrumpir una herramienta SaaS olvidada.
- Enumera cada servicio que envía con el dominio: buzones, CRM, soporte, boletines, formularios, facturación y servidores.
- Integra los remitentes en un solo registro SPF. No publiques dos TXT de SPF.
- Publica DKIM para cada remitente que necesite su selector.
- Publica primero DMARC con
p=noney revisa informes de varios periodos representativos. - Corrige la alineación de cada remitente externo activando el dominio personalizado y comprobándolo con mensajes reales.
- Pasa por etapas a
p=quarantiney luegop=rejecttras validar rutas normales y poco frecuentes y preparar una reversión.
Para un dominio TrekMail con envío administrado, los registros base pueden adoptar esta forma según la configuración actual:
MX @ mail.trekmail.net. priority 10
TXT @ v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.netLa documentación explica el diseño y la verificación en registros DNS necesarios y comprobación del estado DNS. Si estás en una etapa anterior, consulta configurar correo en mi dominio.
Enfoque anterior y enfoque actual
Un enfoque tradicional consiste en pagar por usuario por una suite amplia o mantener un servidor propio, DNS, TLS, selectores y reputación. Otro enfoque separa el alojamiento de buzones del envío y usa una plataforma que facilita registros, validación y migración sin vincularlo todo al número de usuarios. La conveniencia depende de cada entorno.
Ahí puede encajar TrekMail. Según las condiciones descritas por la fuente, Nano permite hasta 10 dominios, 5 GB compartidos y SMTP propio. Los planes de pago parten de $3.50 al mes, incluyen SMTP administrado y se ofrecen sin precio por buzón según las condiciones actuales. Según el plan actual, también puede haber dominios personalizados, IMAP, catch-all, reenvío, migración IMAP y acceso API en niveles superiores. Los planes de pago ofrecen una prueba gratuita de 14 días que requiere tarjeta de crédito. Nano se presenta como gratuito y sin tarjeta. Verifica precios, funciones y límites vigentes.
Este modelo puede facilitar el trabajo operativo con varios dominios: un panel, almacenamiento compartido, registros DNS para copiar y una migración en el servidor, según el plan. La migración IMAP copia correo, no DNS, aplicaciones ni rutas. Consulta alojamiento de correo multidominio y comprueba las cifras actuales en precios de TrekMail.
Conclusión: SPF, DKIM y DMARC son hoy una base técnica
Ya no son controles reservados a configuraciones avanzadas. SPF autoriza la IP para el dominio de sobre, DKIM valida la firma y DMARC vincula una ruta autenticada con From y publica una política solicitada.
Si esta semana solo puedes abordar una tarea, publica un único SPF válido, un DKIM operativo y DMARC con p=none. Después verifica cada remitente con mensajes reales, revisa informes incompletos durante varios periodos, prueba rutas raras y avanza gradualmente con un plan de reversión. Así reduces incidentes evitables sin prometer resultados de entrega.
