Le mandaste la cotización a un cliente y a los dos días te llama para preguntar por qué nunca la recibió. La buscás en la carpeta de spam de su casilla y ahí está. No es mala suerte ni un problema puntual de ese cliente: es casi siempre una consecuencia directa de cómo está (o no está) configurado el dominio que usás para enviar correo.

Gmail, Outlook y el resto de los proveedores grandes usan tres registros DNS para decidir si un correo es legítimo o si lo mandan directo a spam: SPF, DKIM y DMARC. Ninguno de los tres es complicado en el fondo, pero rara vez alguien se sienta a explicarlos en criollo. Acá va.

SPF: quién tiene permiso para enviar en tu nombre

SPF (Sender Policy Framework) es una lista de servidores autorizados a mandar correo usando tu dominio. Vive como un registro TXT en tu DNS y dice algo como "estos son los servidores que pueden decir que son @tuempresa.com, cualquier otro es sospechoso".

El problema típico: cuantos más servicios usás (tu proveedor de email, tu CRM, tu sistema de facturación, tu herramienta de newsletters), más servidores necesitás sumar a esa lista. Si te olvidás de agregar uno, los correos que salen desde ahí van a fallar la verificación SPF y van a perder puntos de confianza frente al filtro antispam del destinatario.

DKIM: la firma digital de cada correo

DKIM (DomainKeys Identified Mail) agrega una firma criptográfica a cada correo que sale de tu dominio. El servidor receptor usa una clave pública, publicada también en tu DNS, para verificar que el correo salió realmente de donde dice y que nadie lo modificó en el camino.

A diferencia de SPF, que autoriza servidores completos, DKIM firma cada mensaje individualmente. Esto lo hace más robusto contra reenvíos y algunos tipos de suplantación, pero también significa que cada servicio que envía en tu nombre necesita su propia clave DKIM configurada correctamente.

DMARC: la política que junta todo

DMARC (Domain-based Message Authentication, Reporting and Conformance) le dice al servidor receptor qué hacer cuando un correo falla SPF o DKIM: dejarlo pasar igual, mandarlo a spam, o rechazarlo directamente. También te manda reportes periódicos con quién está intentando enviar correo usando tu dominio, lo cual es útil tanto para detectar errores de configuración como intentos de suplantación (phishing con tu marca).

Sin DMARC, SPF y DKIM funcionan como referencias sueltas: existen, pero nadie les da una instrucción clara de qué hacer cuando algo no cuadra. Es la pieza que la mayoría de las PyMEs directamente no tiene configurada.

Cómo revisar los tuyos hoy mismo

No hace falta pagar nada para chequear esto. Dos herramientas gratuitas alcanzan:

  • Google Admin Toolbox Check MX: pegás tu dominio y te muestra en segundos si tenés SPF, DKIM y DMARC publicados, y si están bien formados.
  • MXToolbox: además de los tres registros, revisa si tu dominio o tu IP de envío aparecen en alguna lista negra (blacklist), algo que también hunde tu entregabilidad aunque SPF, DKIM y DMARC estén perfectos.

Cinco minutos con cualquiera de las dos te dicen exactamente dónde estás parado.

Los errores que vemos una y otra vez

  • Dos registros SPF en el mismo dominio. El estándar solo permite uno; si hay dos, muchos servidores los ignoran a ambos o toman el resultado como inválido. Pasa mucho cuando dos proveedores distintos (por ejemplo tu hosting y tu CRM) te piden "agregar este SPF" y terminás con dos líneas TXT separadas en lugar de una sola combinada.
  • Migrar de proveedor de correo y olvidarse de DKIM. Cuando una empresa cambia de Exchange a Google Workspace, o de un hosting genérico a otro proveedor, suele actualizar el MX y el SPF, pero se olvida de publicar la nueva clave DKIM. Los correos salen sin firmar y la entregabilidad cae de un día para el otro.
  • Dejar DMARC en p=none para siempre. p=none es el modo "solo observar": no bloquea nada, solo te manda reportes. Está bien como primer paso, pero si te quedás ahí indefinidamente estás recibiendo la información y no actuando sobre ella. Después de revisar los reportes durante unas semanas y confirmar que todo lo legítimo pasa, conviene subir a p=quarantine y eventualmente a p=reject.

Qué cambia cuando migrás a Google Workspace

Pasar de un correo genérico del hosting a Google Workspace es, en general, una mejora de entregabilidad: Google mantiene una reputación de infraestructura mucho más sólida que la mayoría de los hostings compartidos. Pero la migración no arregla SPF, DKIM y DMARC sola. Necesitás publicar el SPF que incluye los servidores de Google, generar y publicar la clave DKIM específica de Workspace, y revisar que tu política DMARC siga alineada con el nuevo esquema de envío, sobre todo si seguís usando otras herramientas (facturación, CRM, marketing) que envían en nombre del mismo dominio.

Es exactamente el tipo de trabajo que suele quedar a mitad de camino: alguien activa las casillas nuevas, importa el correo viejo, y da por hecho que el resto "ya venía configurado". Nuestro equipo hermano en TecnoMagallanes arma la configuración de Google Workspace con SPF, DKIM y DMARC como parte del mismo proceso de migración, para que no dependa de acordarse después.

La parte que no se ve, hasta que se nota

SPF, DKIM y DMARC no tienen una pantalla bonita ni un dashboard que revisás todos los días. Funcionan bien cuando nadie los nota: los correos llegan, nadie pregunta, nadie reclama. El problema es que casi siempre se descubren mal configurados recién cuando ya costaron una cotización perdida o un cliente que se cansó de preguntar "¿me mandaste algo?". Diez minutos con Check MX o MXToolbox hoy valen más que la próxima factura que termine en spam.