SPF, DKIM y DMARC: qué comprueba cada mecanismo
SPF, DKIM y DMARC ayudan a verificar la identidad del envío desde funciones diferentes; no son una garantía de interés ni de inbox.
| Mecanismo | Qué aporta | Qué no demuestra |
|---|---|---|
| SPF | Autorización de servidores para el dominio usado en el envío | Que el mensaje sea relevante |
| DKIM | Firma asociada al dominio y verificación del mensaje | Que todos los destinatarios lo quieran |
| DMARC | Política y alineación de identidad con SPF o DKIM | Ubicación garantizada en la bandeja |
Google exige SPF o DKIM a todos los remitentes y requisitos adicionales, incluidos SPF, DKIM y DMARC, a remitentes masivos según su definición. Consulta la versión vigente y el alcance exacto antes de configurar: el tipo de remitente y el destinatario importan. Google: directrices para remitentes ↗
La revisión debe mirar cabeceras y resultados reales, no solo que exista un registro DNS. Si una plataforma envía con una identidad distinta de la prevista, añadir más registros sin entender la alineación puede ocultar el problema.
La autenticación es una parte del diagnóstico; el síntoma indica qué evidencia falta.
Cómo clasificar una incidencia de envío
Clasifica primero qué ocurrió: rechazo, aplazamiento, queja, dirección inválida o duda sobre ubicación.
| Síntoma | Evidencia necesaria | Primera acción |
|---|---|---|
| Rechazo de autenticación | Código, cabeceras y dominio | Revisar identidad y configuración |
| Aplazamiento temporal | Respuesta y momento del servidor | Investigar causa; no reintentar sin control |
| Direcciones inválidas | Tipo de rebote y procedencia | Revisar fuente y excluir registros inválidos |
| Quejas o baja relevancia | Feedback disponible y segmento | Pausar y revisar selección/mensaje |
| Sin respuesta | Aceptación y contexto de campaña | No inferir spam solo por silencio |
Conserva una muestra de evidencia y la fecha. No mezcles incidentes de dominios, fuentes o cohortes distintas en una sola tasa. El diagnóstico debe conducir a una modificación concreta que puedas observar, no a cambiar todas las variables de golpe.
Si la causa está en los registros, revisa cómo validar procedencia y actualidad de los datos antes de volver a utilizarlos.
Clasificar la evidencia permite elegir una acción distinta para cada incidente.
Tres incidencias y decisiones diferentes
Una misma caída de respuestas puede esconder problemas técnicos, de datos o de propuesta.
Las decisiones de los ejemplos se convierten en controles antes de reanudar.
Checklist antes de reanudar un flujo
Reanuda solo cuando puedas explicar el fallo observado, la corrección y cómo detectar una recaída.
- Identifica dominio, plataforma, cohorte y periodo afectados.
- Comprueba la autenticación con un envío de prueba y evidencia de cabeceras.
- Revisa exclusiones y tratamiento de rebotes y respuestas.
- Documenta el cambio y el responsable de observar su resultado.
- Consulta requisitos actuales del proveedor; no uses cuotas universales de envío como garantía.
Los cambios de políticas requieren revisar las fuentes oficiales. Esta guía ofrece un marco de diagnóstico, no asesoramiento legal ni una receta que funcione para cualquier infraestructura. Google: directrices para remitentes ↗
Una vez descartado el problema técnico, vuelve al contexto y estructura del cold email y a las reglas de seguimiento.
Los controles necesitan incorporarse a las reglas de pausa del sistema.
Cómo conectar el diagnóstico con la operación
El diagnóstico debe formar parte del mantenimiento del sistema y de sus condiciones de pausa.
Las reglas de parada de una secuencia evitan que un fallo conocido siga produciendo acciones.
Si necesitas revisar datos, herramientas y seguimiento como conjunto, explora el sistema outbound B2B.
En resumen
Diagnostica con evidencia del servidor y del segmento. Autenticación, datos y relevancia son problemas distintos: cambia la variable que explica el fallo, no la que sea más fácil modificar.