SPF, DKIM y DMARC: por qué no bastan los indicadores verdes

Autenticación del correo: por qué configurar SPF, DKIM y DMARC no basta

Hiciste el trabajo. Pasaste horas en el DNS copiando cadenas de texto crípticas de tus proveedores de correo. Ejecutaste los validadores y obtuviste marcas verdes en todos ellos. Entonces, ¿por qué caen las tasas de apertura? ¿Por qué los mensajes transaccionales, como restablecimientos de contraseña, facturas y alertas, terminan en spam o desaparecen por completo?

Esta es la realidad de la autenticación del correo con SPF, DKIM y DMARC: una configuración válida no equivale a una buena reputación. Un documento de identidad válido no permite que una persona ebria pase al portero. Desde febrero de 2024, proveedores como Google, Yahoo y Microsoft aplican requisitos técnicos más estrictos, además de valorar si un mensaje parece spam. Si tu panel muestra indicadores verdes pero tus ingresos encienden las alarmas, probablemente estés chocando con uno de los controles que existen más allá de las siglas básicas.

La trampa del remitente masivo: el umbral es menor de lo que crees

La idea equivocada más peligrosa es esta: «Envío menos de 5,000 mensajes al día, así que las reglas para remitentes masivos no me afectan».

No es así por dos motivos, y configurar correctamente SPF, DKIM y DMARC no te protege de esta trampa. Primero, Google contabiliza el volumen en el nivel del dominio principal. Si envías 2,000 mensajes de marketing desde news.example.com, 2,000 mensajes transaccionales desde app.example.com y 1,500 alertas internas desde corp.example.com, se te considera remitente masivo. El volumen de los subdominios se suma al del dominio raíz.

En segundo lugar está el máximo histórico. Si superas una vez el umbral de 5,000 mensajes, por ejemplo con una campaña de Black Friday o una actualización puntual de la base de datos, Google puede clasificar tu dominio permanentemente como remitente masivo conforme a sus reglas vigentes. Esa clasificación no desaparece aunque el volumen baje a 50 mensajes diarios, por lo que deberás seguir cumpliendo los requisitos más estrictos.

Microsoft aplica criterios distintos. Tus registros de SPF, DKIM y DMARC pueden ser impecables, pero la antigüedad de la IP también influye. Si estrenas un dominio y una IP y envías de inmediato 2,000 mensajes, Microsoft puede limitar el tráfico con errores 4xx aunque SPF sea correcto. Aún no conoce tu tráfico, y eso puede bastar para activar la limitación.

Fallos de SPF, DKIM y DMARC: el triángulo de hierro

Muchos administradores configuran SPF, DKIM y DMARC, comprueban la sintaxis y dan el trabajo por terminado. Sin embargo, una sintaxis correcta no garantiza que todo funcione. Estos son los puntos donde suele fallar.

SPF: el agujero negro del reenvío

SPF funciona como una lista de IP autorizadas: indica que «la IP 1.2.3.4 puede enviar correo para example.com». Todo va bien hasta que alguien activa el reenvío automático.

Envías una factura a client@smallbiz.com. Ese cliente reenvía todo su correo a client@gmail.com. Gmail ve la conexión desde la IP de smallbiz.com, no desde la tuya. Al consultar tu registro SPF, smallbiz.com no aparece y la comprobación falla. Si dependes solo de SPF, el mensaje reenviado puede acabar en spam o ser rechazado. Necesitas DKIM para que la autenticación sobreviva a ese salto. Para configurar SPF por completo, consulta nuestra guía de registros SPF.

DKIM: el problema de la alineación

DMARC comprueba dos cosas: si SPF o DKIM, conforme a RFC 6376, ha superado la validación y si los dominios están alineados. La alineación significa que el dominio del encabezado From coincide con los dominios de los encabezados técnicos: Return-Path para SPF y d= para DKIM.

Este es el caso temido en un servicio de soporte: utilizas un CRM como Zendesk o HubSpot para enviar como support@yourcompany.com. El CRM gestiona los rebotes, así que Return-Path es bounces.zendesk.com y la alineación SPF falla. No configuraste un CNAME personalizado, por lo que DKIM firma con d=zendesk.com y también falla su alineación. El mensaje está autenticado técnicamente, pues procede de Zendesk y Zendesk lo firmó, pero DMARC no encuentra ningún protocolo alineado con tu dominio. Si tu política es p=reject, el mensaje se rechaza.

El límite de 10 consultas

SPF, tal como se define en RFC 7208, impone un máximo estricto de 10 consultas DNS por registro. Si trabajas en una agencia cuyos clientes utilizan muchas herramientas SaaS, seguramente ya lo has visto. Google Workspace puede consumir por sí solo 4 consultas. Añade Mailchimp, HubSpot, un sistema de tickets y una herramienta de RR. HH.:

Cada include: obliga a realizar una consulta DNS, y esos elementos pueden contener otros anidados. Si se superan 10 consultas en total, el servidor receptor devuelve PermError, que se trata como si no existiera un registro SPF. En la práctica, el intento de ser exhaustivo termina dejando tu correo sin autenticar.

Controles ocultos más allá de SPF, DKIM y DMARC

Además de los tres protocolos principales, existen requisitos técnicos sin nombres comerciales llamativos que pueden bloquear el correo con la misma rapidez.

FCrDNS (DNS inverso confirmado hacia delante)

Cada IP remitente necesita un registro PTR, o DNS inverso, que resuelva a un nombre de host. A su vez, ese nombre debe tener un registro A que apunte a la IP original. Esta verificación de ida y vuelta ayuda a demostrar el control de la infraestructura. Si creas una máquina virtual en la nube, instalas Postfix y envías correo sin registro PTR, Gmail puede tratar el servidor como parte de una red de bots y devolver de inmediato 550 5.7.1.

RFC 8058: cancelación de suscripción con un clic

Desde junio de 2024, para el correo de marketing sujeto a los requisitos actuales de los grandes proveedores no basta con un enlace en el pie. Debes incluir dos encabezados específicos:

El endpoint HTTPS debe aceptar una solicitud POST, no GET. Los bots antispam analizan los mensajes «pulsando» los enlaces. Si la cancelación utiliza GET, pueden dar de baja por accidente a usuarios reales. Además, cuando un usuario no encuentra una salida sencilla, suele pulsar «Marcar como spam», lo que acerca al remitente al umbral de quejas del 0.3%.

El umbral del 0.3%: la economía de la reputación

Una autenticación SPF, DKIM y DMARC perfecta, un FCrDNS impecable y unos encabezados correctos no sirven de nada si los destinatarios detestan el contenido.

La métrica decisiva es la tasa de quejas por spam. Según las políticas vigentes descritas al publicar este artículo, el límite relevante es 0.3%, es decir, 3 quejas por cada 1,000 mensajes. Si lo superas, Google puede llegar a bloquear el dominio por completo.

La trampa del denominador de la bandeja de entrada de Yahoo

Yahoo puede calcular la tasa de spam a partir de los mensajes que llegan a la bandeja de entrada, no del total enviado. Envías 1,000 mensajes. La reputación de tu dominio ya es débil, así que 900 terminan en spam y 100 llegan a la bandeja de entrada. Una persona presenta una queja. El cálculo es 1/100 = 1.0%, una tasa 3x superior al límite de aplicación. Una sola queja puede iniciar una espiral de la que resulta muy difícil salir.

El problema de los malos vecinos

Incluso con SPF, DKIM y DMARC bien configurados, en un alojamiento compartido convencional o una plataforma de correo «ilimitado» barata tus mensajes salen desde la misma IP que los de miles de clientes. Si uno de ellos envía una estafa con criptomonedas, Spamhaus puede incluir la IP en su lista de bloqueo. Tu correo queda bloqueado aunque no hayas hecho nada malo. Compartes edificio con el problema y las consecuencias alcanzan a todos.

Lista del viernes para corregir SPF, DKIM y DMARC

1. Revisa los encabezados: Envía un mensaje a una cuenta personal de Gmail. Ábrelo, pulsa los tres puntos y selecciona «Mostrar original». Busca Authentication-Results. ¿SPF se valida? ¿DKIM se valida? ¿El dominio de dkim= coincide con el de header.from? Si no es así, existe un problema de alineación.

2. Comprueba FCrDNS: Ejecuta dig -x <your-sending-ip>. ¿Devuelve un nombre de host? Ejecuta dig <that-hostname>. ¿Devuelve la IP? Si no se completa el circuito, detén los envíos y corrige el DNS.

3. Separa el tráfico: No envíes marketing desde el dominio corporativo principal. Utiliza team@company.com para el correo entre personas y newsletter@marketing.company.com para las campañas. Si el marketing alcanza el umbral del 0.3%, la dirección ejecutiva aún podrá escribir a los inversores desde el dominio principal.

4. Sigue leyendo: Para conocer el proceso de recuperación, consulta nuestra guía sobre la reputación del remitente y el análisis detallado de la reputación del dominio de correo.

Planes de TrekMail

Según las condiciones vigentes, todos los planes de pago incluyen una prueba de 14-day (se requiere tarjeta). Free no exige tarjeta.

Conclusión

La autenticación del correo mediante SPF, DKIM y DMARC no es una tarea que se configura una vez y se olvida. Es un requisito operativo continuo. Superar las comprobaciones solo permite entrar en juego. Para permanecer realmente en la bandeja de entrada hacen falta una alineación estricta, una higiene de red impecable, incluido FCrDNS y los encabezados de cancelación con un clic, y una estrategia de reputación que te proteja de otros remitentes. No te conformes con la configuración predeterminada. Controla tu infraestructura.

Obtener indicadores verdes para SPF, DKIM y DMARC es el precio de entrada, no la meta. Prueba TrekMail gratis y toma el control real de la autenticación de tu correo.