SPF, DKIM y DMARC sin humo: cómo validar tu correo y dejar de caer en spam

El correo corporativo tiene una mala costumbre: a veces parece funcionar bien hasta que alguien importante deja de recibirlo, Gmail lo manda a spam o Microsoft decide mirarlo con sospecha. Ahí recién aparece la conversación sobre SPF, DKIM y DMARC, normalmente acompañada de una captura de pantalla, un registro DNS mal puesto y bastante frustración acumulada.

La idea de fondo es simple: si tu dominio va a enviar correo, tiene que poder demostrar identidad. No basta con que el mensaje salga; también importa que el receptor pueda verificar que quien dice enviarlo está autorizado para hacerlo. Cuando eso está mal resuelto, el correo no siempre rebota: a veces llega tarde, a veces cae en spam y a veces simplemente deja de inspirar confianza.

Qué hace SPF y qué no hace

SPF define qué servidores pueden enviar correo en nombre de tu dominio. Ayuda a decir "estos sí, estos no", pero no firma el mensaje ni evita por sí solo todo el spoofing. Su función es útil, pero limitada: si lo conviertes en una lista infinita de includes, más que protección terminas construyendo una fuente bastante creativa de errores.

Un registro SPF bien formado para Google Workspace con hosting adicional se ve así:

Copiarv=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

Límite crítico: SPF tiene un tope de 10 DNS lookups por evaluación. Cada include: consume uno. Si lo superas, el registro falla silenciosamente en algunos servidores. Puedes validarlo con:

bashCopiardig TXT tudominio.com | grep spf

Qué hace DKIM y por qué suele quedar a medias

DKIM agrega una firma criptográfica que permite verificar que el mensaje no fue alterado y que salió de un origen que conoce la clave correcta. En la práctica, muchas configuraciones fallan por cosas muy poco glamorosas: selector mal configurado, clave antigua, dominio equivocado o firma que no alinea con la identidad visible del remitente.

Para verificar que el registro DKIM existe y está bien publicado:

bashCopiardig TXT google._domainkey.tudominio.com

El output esperado debería incluir v=DKIM1; k=rsa; p=... con la clave pública. Si el campo p= está vacío, la firma está revocada.

Lo que suele fallar: la alineación. El header From: visible en el correo debe coincidir con el dominio usado en la firma DKIM. Cuando una plataforma de envío externo firma con su propio dominio y el From dice el tuyo, la alineación falla y DMARC lo penaliza.

Qué hace DMARC sin romper todo

DMARC se apoya en SPF y DKIM para definir política, alinear identidad y decirle al receptor qué hacer cuando algo no cuadra. El error más simpático aquí es publicar p=reject como gesto de autoridad antes de entender el flujo real de envío. Eso no disciplina mágicamente al correo; normalmente solo rompe entrega legítima y deja a alguien preguntándose por qué desaparecieron mensajes válidos.

El registro DMARC mínimo que todo dominio debería tener en modo observación:

Copiar_dmarc.tudominio.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reportes@tudominio.com"

Los reportes rua llegan en XML y muestran qué servidores están enviando correo en nombre de tu dominio, con qué resultado SPF/DKIM. Antes de pasar a p=quarantine o p=reject, conviene leer al menos 2-4 semanas de reportes.

Errores comunes al configurar estos registros

• Creer que basta con copiar registros sugeridos por Internet y pegarlos en DNS
• Mezclar múltiples plataformas de envío sin inventario previo
• Inflar SPF con demasiados include (recuerda el límite de 10 lookups)
• Dejar DKIM a medias o con selector incorrecto
• Activar DMARC con política agresiva antes de observar
• Asumir que el hosting "ya lo deja bien" sin validar nada
• No configurar rua en DMARC y quedarse sin visibilidad de flujo

Escenario real: dominio con múltiples plataformas de envío

Este es el escenario que más rompe configuraciones que "parecían correctas":

• Google Workspace → correo corporativo diario
• Mailchimp → newsletter mensual
• Formulario web (hosting) → notificaciones automáticas
• CRM externo → correos transaccionales

Cada plataforma necesita estar en SPF y tener DKIM configurado con su propio selector. Si el CRM firma con dominio-crm.com y el From: dice tudominio.com, DMARC falla. La solución no es p=none permanente; es resolver la alineación en cada plataforma antes de subir la política.

Herramientas útiles para validar

Conviene validar con herramientas concretas:

• dkimvalidator.com → envía un correo de prueba a su dirección temporal y muestra cómo llega firmado, con resultado DKIM, SPF y DMARC
• mxtoolbox.com → revisa registros DNS, SPF (con conteo de lookups), DMARC y blacklists
• mail-tester.com → da un score de entregabilidad sobre 10 con detalles por criterio
• Google Postmaster Tools → para dominios que envían volumen a Gmail, muestra reputación real del dominio

Ninguna reemplaza criterio técnico, pero sí ayudan a detectar errores evidentes antes de que el problema lo descubra un cliente.

Qué conviene revisar antes de tocar DNS

Si el dominio usa Google Workspace, Microsoft 365, un hosting tradicional, un formulario web y además una plataforma externa de envío, lo responsable es revisar la película completa. No solo los registros. También hay que mirar qué plataforma envía qué, con qué identidad visible, con qué Return-Path, con qué alineación y con qué reputación probable. Ahí es donde muchas configuraciones "correctas" en teoría siguen fallando en la práctica.

Lo que este artículo no cubre (y por qué)

Este artículo no entra en configuración específica por plataforma (Google Workspace paso a paso, cPanel, Plesk), ni en análisis avanzado de reportes DMARC en XML, ni en BIMI (el estándar que muestra el logo de tu marca en clientes de correo). Esos temas merecen artículos propios porque cada uno tiene suficiente complejidad operativa como para no despacharlos en un párrafo. Lo que sí cubre este artículo es el criterio para entender qué está pasando antes de tocar registros a ciegas.

Si solo vas a revisar cinco cosas

• Identifica todas las plataformas que envían correo por tu dominio
• Corrige SPF sin convertirlo en un árbol genealógico interminable (máximo 10 lookups)
• Asegúrate de que DKIM firme desde donde corresponde y que el selector esté activo
• Parte DMARC en modo monitoreo (p=none + rua) antes de castigar
• Valida con herramientas reales y con correos de prueba antes de declarar que está listo

Conclusión corta

SPF, DKIM y DMARC no son decoración DNS. Son parte de la identidad operativa del correo corporativo. Si están mal, el correo pierde credibilidad. Si están bien, mejora la entregabilidad, baja el ruido y reduces el riesgo de que tu dominio parezca estar enviando mensajes que en realidad no controlas del todo.

Si hoy no tienes claro quién envía correo por tu dominio, si no sabes si DKIM está firmando bien o si DMARC está realmente alineado con tu operación, ese ya es motivo suficiente para revisar la configuración completa antes de que el problema lo diagnostique otro por ti.