Configurar SPF, DKIM y DMARC: correo que llega
«¿Por qué mi propio correo de empresa acaba en spam?» casi nunca tiene que ver con nada de lo que escribiste. Tiene que ver con tres registros DNS que nadie te dijo que configuraras: SPF, DKIM y DMARC. Con ellos, los proveedores de correo pueden verificar que tu correo es realmente tuyo; sin ellos, un mensaje perfectamente legítimo es — para un filtro automático — indistinguible de alguien suplantando tu nombre.
Tres registros, tres trabajos distintos
SPF — quién puede enviar en tu nombre — un registro TXT publicado en tu dominio que enumera los servidores de correo autorizados a enviar mensajes que dicen ser tuyos. Un servidor receptor comprueba el origen real contra esa lista; una discrepancia es una señal fuerte — aunque no por sí sola un rechazo automático — de que el mensaje quizá no sea realmente tuyo.
DKIM — prueba de que nada se manipuló — el servidor emisor firma criptográficamente cada mensaje con una clave privada que solo él posee; la clave pública correspondiente se publica en tu DNS. Una firma válida demuestra dos cosas a la vez: que quien tiene tu clave envió el mensaje, y que nada se alteró en el trayecto después de firmarlo.
DMARC — la política que los une — indica si SPF y DKIM deben coincidir con el dominio de la dirección «De» visible, le dice a los servidores receptores qué hacer cuando un mensaje falla ambas comprobaciones (nada, cuarentena o rechazo), y pide informes periódicos sobre lo que se envía en tu nombre, tanto si pasa como si no.
De dónde salen realmente estos registros
1
Descubre qué envía realmente tu correo
No el proveedor de alojamiento de tu web, sino el servicio de correo o de envío desde el que sale realmente el mensaje: Google Workspace, Microsoft 365, Zoho, Proton o similares.
2
Publica SPF para ese remitente
Tu proveedor de correo publica su propia línea SPF exacta en su documentación de configuración; tú la pegas en el DNS de tu dominio, en el mismo panel que usas para cualquier otro registro DNS.
3
Activa la firma DKIM en ese proveedor
La mayoría de los proveedores generan el par de claves por ti y te dan el registro DNS exacto que hay que publicar: la configuración de DKIM la lleva el proveedor, no es algo que construyas a mano.
4
Añade un registro DMARC, empezando en solo monitorización
Escribe tú mismo un registro TXT de DMARC, empezando por p=none, y endurécelo solo cuando los informes confirmen que todos tus remitentes reales pasan limpiamente.
Cómo lo resuelve Olmira
El SMTP por inquilino es la respuesta de Olmira a esto exactamente: conecta tu propia cuenta de correo para cada finalidad — transaccional, marketing, soporte, facturación y más — así un mensaje sale de verdad a través de una cuenta que ya controlas, con la dirección «de» que tú fijas. Tu capacidad de entrega depende entonces del SPF, DKIM y DMARC que ya tiene el dominio de esa cuenta: conecta un buzón de empresa real desde el que ya envías, y su autenticación existente cubre también el correo que envía Olmira.
Una regla es la que más importa: fija la dirección «de» de una finalidad en el mismo dominio desde el que la cuenta conectada está realmente autorizada a enviar — que los dos no coincidan es la causa más común de un fallo que parece suplantación, en cualquier plataforma. Una finalidad que dejas sin configurar simplemente recurre al relé propio de Olmira en vez de fallar al enviar. El resto de lo que cubre Integraciones: Integraciones.
Técnicamente el correo se enviará, pero el SPF y el DKIM de un proveedor de webmail de consumo autentican su dominio, no uno personalizado que pongas en el campo «de»: el correo que dice venir de tu dominio de empresa pero se envía a través de los servidores autenticados de otro suele fallar la alineación. Merece la pena montar un buzón real en tu propio dominio antes de necesitar parecer creíble a escala.
SPF y DKIM son ya casi obligatorios: varios grandes proveedores de correo exigen al menos uno para los remitentes masivos. DMARC es lo que realmente une a los dos e indica a los receptores qué hacer cuando algo falla; saltárselo no rompe nada de inmediato, pero es la pieza que convierte «autenticado» en «exigido».
La autenticación demuestra que el mensaje viene realmente de ti; no lo exime del filtrado antispam habitual. El contenido, el volumen de envío, la interacción de los destinatarios y la reputación del dominio siguen contando, además de que la autenticación pase limpiamente.
El mismo retardo de propagación DNS que con cualquier otro registro: consulta conectar los registros DNS del dominio para ver qué está pasando realmente mientras esperas y por qué «todavía no» no es lo mismo que «mal».
Toda fuente de envío legítima —tu buzón del día a día, una plataforma de marketing, un formulario de contacto del sitio web— debe incluirse en el mismo registro SPF y, cuando el proveedor lo permita, tener su propia firma DKIM. Olvidar una es el motivo más habitual de que una herramienta legítima empiece a fallar las comprobaciones después de que «ya estaba todo configurado».