Cambiás el asunto, acortás el mensaje y quitás una imagen, pero los correos siguen apareciendo en spam. Antes de atribuirle el problema al copy, revisá si el receptor puede comprobar qué servicio está enviando por tu dominio y si esa identidad coincide con el remitente que ve la persona.

SPF, DKIM y DMARC ayudan a autenticar el envío y definir cómo tratar fallas de autenticación. No garantizan la bandeja principal: también importan reputación, calidad de la base, expectativas y comportamiento de envío. Este procedimiento permite separar una falla técnica de otros problemas y preparar cambios sin interrumpir correos legítimos.

Empezá por un mensaje concreto

Elegí un correo que haya llegado a spam y registrá desde qué sistema salió, a qué dominio se envió, cuándo y con qué dirección visible. Diferenciá una campaña, una respuesta personal, un comprobante y una notificación del formulario web. Pueden compartir marca y salir por infraestructuras distintas.

Pedí el original del mensaje o sus encabezados completos mediante la función del proveedor receptor. Una captura de la carpeta spam no muestra cómo se autenticó. Si vas a compartir el archivo, tratá direcciones, contenido e identificadores como información de acceso restringido.

Repetí con una pequeña muestra de cada circuito relevante. Si una campaña funciona y las notificaciones de la web fallan, cambiar el DNS de toda la organización sin distinguir sistemas puede empeorar un recorrido que ya estaba bien.

Anotá todos los servicios que envían por el dominio

Incluí correo del equipo, plataforma de campañas, CRM, tienda, sistema de reservas, facturación y formularios. Para cada uno, registrá responsable, dominio visible del remitente, dominio de retorno o MAIL FROM, dominio de firma DKIM y dónde se configura la autenticación.

El hosting de la web y el proveedor del correo pueden ser empresas diferentes. El DNS también puede administrarse en otro lugar. Identificá quién controla cada capa antes de pedir que alguien “agregue los registros”, porque publicar un valor en una zona que no es la activa no cambia lo que consultan los receptores.

Comprobá si el proveedor ya configuró parte de la autenticación y qué valores pide específicamente para tu cuenta. No uses registros encontrados en un tutorial de otro dominio: los selectores, claves y servicios autorizados pueden ser distintos.

Qué comprobación hace cada mecanismo

SPF

Permite al receptor comprobar si la infraestructura que envía está autorizada para el dominio usado en esa comprobación, normalmente el del remitente de sobre o MAIL FROM. No equivale a verificar directamente el nombre visible del correo.

DKIM

Agrega una firma que el receptor verifica con una clave pública publicada en DNS. El encabezado de firma identifica dominio y selector. La firma necesita estar activada en el servicio que realmente envía, además de contar con el registro correcto.

DMARC

Relaciona el dominio visible de From con una autenticación SPF o DKIM válida y alineada. Puede aprobar cuando al menos uno de esos mecanismos pasa y cumple la alineación aplicable. La política expresa cómo solicita el dominio que se traten las fallas.

Que SPF y DKIM aprueben usando dominios del proveedor no demuestra por sí solo que DMARC apruebe para tu From. Ese desajuste explica algunos casos en los que todos creen haber “autenticado la plataforma”, pero la identidad visible de la marca sigue sin alinearse.

Leé los resultados del receptor

En el original buscá Authentication-Results y los detalles que aporta el sistema receptor. Este fragmento está simplificado para mostrar los campos; los dominios de ejemplo no corresponden a una configuración para instalar:

From: Equipo <hola@marca.example>
Authentication-Results: mx.receptor.example;
  spf=pass smtp.mailfrom=envios.proveedor.example;
  dkim=pass header.d=marca.example;
  dmarc=pass header.from=marca.example

En este caso didáctico, DKIM firma con el mismo dominio visible y permite una alineación directa. SPF pasa para un dominio diferente del proveedor. El resultado DMARC del receptor indica aprobación; no necesitás que ambos mecanismos se alineen para que DMARC pase.

Leé los encabezados desde el contexto del receptor confiable, porque un mensaje puede transportar varios resultados de distintas etapas. No tomes cualquier línea agregada en el recorrido como una certificación de entrega. Si no podés identificar cuál corresponde, pedí ayuda al administrador del correo antes de concluir.

Si SPF falla: revisá autorizaciones y registros duplicados

Buscá el TXT SPF del dominio que realmente usa ese envío. Tiene que contemplar los servicios legítimos correspondientes y mantener una sintaxis válida. Publicar varios registros SPF independientes para el mismo nombre no es una forma de sumar proveedores: necesitás una configuración única y coherente para ese nombre.

Pedí los valores al proveedor y revisá lo existente antes de reemplazarlo. Una plataforma nueva no debería borrar la autorización del correo del equipo. También evitá acumular inclusiones de servicios que ya no usás; complican la lectura y pueden afectar los límites de evaluación de SPF.

Para consultar sin modificar, podés usar una herramienta DNS o un comando como este, reemplazando el dominio por el que estés investigando:

dig TXT marca.example

Que el registro exista no prueba que el mensaje esté saliendo desde una infraestructura autorizada. Después de cualquier cambio, volvé a enviar una muestra desde el sistema real y revisá el resultado en el receptor. Considerá también los tiempos de caché DNS al interpretar pruebas consecutivas.

Si DKIM falta o falla: seguí el selector correcto

Revisá el dominio de firma y el selector del encabezado DKIM-Signature. Ese selector permite localizar la clave publicada. No supongas que todos los proveedores usan el mismo nombre ni que el registro de otra plataforma sirve para esta.

El proveedor puede pedir un TXT o una delegación mediante CNAME según su implementación. Copiá los valores exactos y verificá cómo tu panel agrega el dominio al nombre del registro. Una duplicación accidental del dominio puede dejar la clave publicada en un lugar que el receptor no consulta.

Confirmá que la firma esté habilitada después de publicar el registro. Durante una rotación de claves, coordiná cuándo se usan y retiran los selectores para no cortar la verificación de mensajes en tránsito. No modifiques una clave a partir de una captura parcial.

Si DMARC falla: compará identidades antes de endurecer la política

Tomá el dominio visible de From y comparalo con el dominio de SPF y el de la firma DKIM que pasó. Revisá si la relación cumple el modo de alineación configurado. Dominios distintos pueden pertenecer a una misma organización y aun así necesitar una configuración específica para alinearse.

La solución puede estar en configurar un dominio de retorno propio o una firma DKIM alineada dentro de la plataforma. Cambiar solamente Reply-To no corrige la identidad de From usada por DMARC.

Antes de aplicar una política más restrictiva, identificá todos los emisores legítimos y observá sus resultados. Una etapa de monitoreo puede ayudar a detectar fuentes faltantes; no constituye por sí sola una protección equivalente al rechazo de mensajes fallidos. Revisá los informes con alguien que pueda distinguir servicios legítimos, errores y posibles usos indebidos.

El registro DMARC se consulta en el nombre correspondiente del dominio. Este comando es solo de lectura:

dig TXT _dmarc.marca.example

No publiques una política de rechazo para “salir de spam” sin evaluar los circuitos. Podrías afectar facturas, confirmaciones o mensajes del sitio que todavía no se autentican correctamente. El objetivo es corregir la identidad del envío y comprobar cada recorrido.

Un caso habitual: el formulario usa al visitante como remitente

Una web puede intentar enviar notificaciones con la dirección que escribió el visitante en From. Eso hace que el servidor de tu sitio intente presentarse como otro dominio, sobre el que no tiene autorización.

Configurá un remitente propio autenticado en el servicio de envío y usá la dirección del visitante como Reply-To cuando corresponda. Probá que el equipo pueda responder y que el mensaje mantenga los datos necesarios para atender la consulta. Recibir una respuesta técnica de “enviado” no demuestra que haya llegado a la casilla prevista.

La revisión de una web con visitas y pocas consultas incluye la comprobación del contacto. Si medís envíos como conversiones, distinguí la acción del usuario de la recepción efectiva por el equipo.

Si todo aprueba y el mensaje sigue en spam

Continuá con expectativas de la base, permisos, rebotes, quejas, cambios bruscos de volumen, enlaces y reputación. Compará los sistemas afectados y los receptores antes de editar todos los mensajes. Un problema localizado en una plataforma no tiene por qué requerir rehacer la comunicación completa.

La guía de email marketing útil ayuda a ordenar promesa, frecuencia y contenido. La autenticación y la pertinencia del mensaje trabajan juntas, pero sus comprobaciones son distintas.

Dejá un registro de muestras antes y después: circuito, fecha, dominio visible, resultados SPF, DKIM y DMARC, ubicación observada y cambio realizado. Cerrá la tarea cuando los envíos legítimos estén comprobados y quede claro qué parte de la entrega todavía requiere seguimiento.