La autenticación del correo con SPF, DKIM y DMARC puede marcar la diferencia entre un mensaje aceptado y una factura que nadie encuentra. Si el dominio no acredita su identidad, los proveedores disponen de menos señales para confiar en el mensaje. Hoy forma parte del trabajo operativo diario.
Muchos equipos no omiten los tres protocolos, sino que los configuran en un orden arriesgado, publican pronto una política estricta y bloquean su propio correo. Si todavía estás resolviendo decisiones básicas de correo empresarial, hazlo primero. Después aborda la autenticación.
Esta guía propone una secuencia operativa prudente: inventario, SPF, DKIM, DMARC con p=none, corrección de alineación y aplicación gradual. No es la única secuencia posible para todos los entornos, pero ayuda a evitar que el reenvío, las herramientas de marketing y el soporte legítimo se interrumpan.
Si utilizas TrekMail, la plataforma ofrece comprobaciones DNS y, según el plan y la configuración, dominios personalizados, IMAP, catch-all, reenvío, migración y SMTP propio o administrado. Para añadir un dominio, consulta la guía de configuración de dominios. Para empezar desde cero, lee cómo crear correo con un dominio.
Qué hacen realmente SPF, DKIM y DMARC
Son tres mecanismos relacionados. SPF autoriza IP para el dominio MAIL FROM real, DKIM valida la firma y los datos firmados, y DMARC solicita un tratamiento cuando las comprobaciones fallan o no se alinean con From visible.
| Protocolo | Función | Qué comprueba | Fallo principal |
|---|---|---|---|
| SPF | Autorización | Si la IP de envío está permitida para el dominio de sobre | Demasiadas consultas, remitente ausente o cambio de IP por reenvío |
| DKIM | Integridad | Si encabezados y cuerpo firmados siguen validando la firma | Selector incorrecto, clave ausente o proveedor sin firma alineada |
| DMARC | Política y alineación | Si SPF o DKIM pasa y está alineado con From | Aplicar una política antes de validar SPF y DKIM |
Piensa en SPF como una lista de acceso, en DKIM como un precinto y en DMARC como una política. Los tres pueden ser necesarios por requisitos actuales, pero conviene implantarlos por etapas después de conocer las rutas reales.
Un orden de configuración prudente
Una secuencia habitual es inventariar remitentes, publicar SPF, activar DKIM, publicar DMARC sin restricciones, revisar la alineación y después avanzar gradualmente. Reduce el riesgo de rechazar correo legítimo antes de saber qué sistemas envían.
- Inventaría todos los sistemas que envían como el dominio.
- Publica un registro SPF que incluya los remitentes legítimos.
- Activa DKIM en cada proveedor compatible.
- Publica DMARC con
p=noney reúne informes de varios periodos. - Corrige los fallos de alineación.
- Avanza a
p=quarantiney después ap=rejectsi las pruebas lo respaldan.
La dificultad no suele estar en la longitud de los registros, sino en que el conjunto real de remitentes es más complejo de lo esperado.
Fase 1: inventario y SPF
SPF suele ser un primer cambio útil porque responde a quién puede enviar para el dominio MAIL FROM. No resuelve todo, pero ofrece un punto de partida y revela proveedores antiguos aún autorizados.
Antes de tocar DNS, enumera el correo corporativo, facturación, CRM, soporte, marketing, formularios, impresoras y cualquier sistema que envíe como @yourdomain.com. Confirma también qué dominio de sobre usa en mensajes reales.
Publica un solo SPF, no uno para Google y otro para marketing. Varios registros TXT SPF para el mismo dominio generan un estado de error. La documentación de TrekMail lo recoge en sus ejemplos DNS.
Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com ~allUsa ~all o -all según una política evaluada y las rutas verificadas; ninguno sustituye un inventario completo.
El gran límite de SPF son las consultas. Según RFC 7208, la evaluación tiene un límite de 10 consultas DNS originadas por los mecanismos y modificadores correspondientes, incluida la evaluación anidada. Acumular include:, a o mx puede causar permerror y dejar incompleta la evaluación.
Añades Google, HubSpot, Zendesk, QuickBooks, Mailchimp y un sistema antiguo. SPF parece completo, pero un receptor alcanza el límite durante la evaluación y obtiene un error.
Con muchos dominios, esta gestión se vuelve operativa. Audita proveedores, elimina include solo tras confirmar que no se usan y separa tráfico por subdominio únicamente si la ruta MAIL FROM está configurada y probada. Para clientes múltiples puede ayudar un alojamiento de correo multidominio con comprobaciones centralizadas.
Fase 2: DKIM y alineación
DKIM viene después porque SPF es frágil. El reenvío puede cambiar la IP y romper SPF, mientras que DKIM puede seguir pasando si la firma alineada permanece válida y los datos firmados respetan la canonicalización. No ocurre en todas las rutas.
Activa DKIM en cada servicio compatible que envíe: buzones, plataforma transaccional, marketing y soporte. Si alguno no admite firma con tu dominio, evalúa su riesgo y alternativas; no asumas que existe una opción personalizada.
Un DNS DKIM típico es:
Type: TXT
Host: trek._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...Algunos proveedores usan DKIM mediante CNAME si lo admiten. Cambia el método, pero sigue siendo necesario activar la función y probar mensajes reales.
Usa selectores separados cuando el proveedor lo permita. Facilita retirar una plataforma sin afectar la firma del servidor principal.
La alineación es donde muchas configuraciones fallan. La autenticación no basta: DMARC comprueba que el dominio autenticado se relacione con From visible. Las directrices actuales de Google para el tráfico aplicable exigen alineación SPF o DKIM con el dominio organizativo de From y pueden exigir ambos protocolos publicados. Consulta las preguntas frecuentes para remitentes.
Si Mailchimp firma con su dominio y usa su propio Return-Path, SPF y DKIM pueden pasar, pero DMARC fallar para tu From. Cuando el proveedor lo admita, activa su autenticación de dominio personalizada y verifica el resultado real. No hay una corrección universal fuera de las funciones que ofrezca.
El reenvío es un caso habitual. Si tu equipo lo usa mucho, consulta configuración y corrección del reenvío. El resultado depende de la ruta, de la firma y de cualquier modificación intermedia.
Fase 3: DMARC sin restricciones solicitadas
DMARC suele empezar con p=none, que solicita no aplicar restricciones DMARC mientras recopilas evidencia parcial. No convierte al analizador en un modo especial ni desactiva los filtros locales del receptor.
Un registro inicial es:
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=sPuedes usar la alineación relajada predeterminada o la estricta según dominios y rutas probadas. La estricta no es universalmente mejor. No pases directamente al rechazo sin conocer todos los remitentes legítimos y su alineación.
Los informes DMARC son útiles, pero incompletos, y conviene usar un analizador. SPF fail con una firma DKIM válida y alineada aún puede producir DMARC pass, especialmente tras ciertos reenvíos. Si ambos fallan, investiga: puede ser suplantación o un remitente legítimo olvidado. Para TrekMail, consulta la guía de problemas de spam.
En esta fase aparecen sistemas olvidados, escáneres mal configurados, boletines antiguos y posibles intentos de suplantación. Contrasta cada clasificación con inventario, registros y mensajes reales antes de decidir.
Fase 4: corregir lo que muestran los informes
Los informes aportan evidencia sobre alineación y autenticación, pero no determinan por sí solos qué fuente es falsa. Separa fallos legítimos y posibles abusos, y valida el tráfico real durante varios periodos representativos.
La mayoría de los fallos entra en estos grupos:
- Un remitente real falta en SPF.
- Un proveedor firma DKIM, pero no con tu dominio.
- Marketing usa un dominio bounce predeterminado y SPF no se alinea.
- Un dispositivo envía directamente en lugar de usar un relay autenticado.
- Una IP desconocida intenta suplantar el dominio From.
Impresoras y escáneres suelen enviar directamente. Encaminarlos por un relay SMTP configurado puede ser más controlable. Los planes de pago de TrekMail incluyen SMTP administrado según las condiciones actuales; Nano se ofrece con SMTP propio según esas condiciones. La guía de configuración IMAP y SMTP documenta hosts y puertos vigentes. TrekMail se presenta como servicio IMAP, no POP3.
Cuando los informes, registros, pruebas reales y rutas críticas poco frecuentes estén validados durante varios periodos representativos, avanza con cautela y prepara una reversión.
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.comEmpieza por quarantine si corresponde al riesgo y después considera reject cuando confíes en el inventario y la alineación. Son políticas solicitadas; el receptor conserva su criterio.
Cómo verificar los registros desde la línea de comandos
La verificación importa porque los paneles pueden mostrar datos desactualizados, las cachés persisten y los proveedores tardan en actualizarse. Consulta DNS directamente y envía mensajes de prueba por cada sistema.
Comprueba SPF:
dig txt example.com +shortComprueba DKIM para un selector:
dig txt trek._domainkey.example.com +shortComprueba DMARC:
dig txt _dmarc.example.com +shortBusca un solo SPF, una clave DKIM válida y la política DMARC que pretendías publicar. Si el cambio no aparece, considera TTL y consulta un resolvedor externo, sin asumir que una sola vista refleja a todos los receptores.
Comprueba también DNS inverso, TLS y tasas de quejas. La autenticación es una base, no una solución mágica, y no compensa listas deficientes ni prácticas arriesgadas.
Enfoque anterior y enfoque actual
Un enfoque tradicional paga por buzón por una suite amplia o mantiene un servidor propio con DNS, TLS, selectores y reputación. Otro permite controlar el dominio, el trayecto SMTP y la autenticación con una plataforma independiente del número de buzones, según sus condiciones.
Según la fuente y sujeto a cambios, Starter comienza en $3.50 al mes, Nano se ofrece a $0 con SMTP propio y los planes de pago incluyen SMTP administrado. Las funciones disponibles pueden incluir dominios personalizados, IMAP, catch-all, reenvío, migración IMAP en servidor y API en niveles superiores. Comprueba siempre plan, configuración, precios y límites actuales; la migración IMAP copia correo, no DNS ni aplicaciones.
Ese es el enfoque operativo: configura la autenticación, mantenla y evalúa el modelo de costes sin asumir ahorros automáticos. Para entender la oferta, lee configurar correo en mi dominio y revisa los planes en precios de TrekMail.
Conclusión
SPF, DKIM y DMARC forman un sistema relacionado. SPF autoriza una IP para MAIL FROM, DKIM valida la firma y DMARC evalúa la alineación y publica una política solicitada. Una implantación por etapas reduce el riesgo de interrupciones autoinfligidas.
En resumen: inventaría remitentes, publica un SPF, activa DKIM donde se admita, usa DMARC con p=none, corrige alineación y avanza gradualmente tras pruebas. Es una ruta operativa prudente para 2025 y 2026, no una garantía universal. Para consultar las condiciones actuales de TrekMail, visita TrekMail.
