DMARC: cómo pasar de observar a proteger sin rechazar correo legítimo
Cómo revisar fuentes autorizadas y alineación antes de endurecer DMARC. Prepare pruebas, seguimiento y una forma de revertir cambios.
Publicar p=none puede aportar visibilidad, pero no solicita al receptor que rechace los mensajes que fallen DMARC. Cambiar inmediatamente a p=reject tampoco es una buena prueba: podría descubrir sus remitentes legítimos a través de facturas que dejaron de llegar.
El cambio necesita una condición de salida clara: conocer las fuentes autorizadas y comprobar que sus mensajes pasan DMARC antes de endurecer la política.
Cuando SPF pasa y DMARC falla
Ejemplo ficticio: una factura muestra From: [email protected], pero el servicio la envía con Return-Path: [email protected] y firma con d=example.net. SPF y DKIM podrían pasar para example.net y, aun así, no estar alineados con example.com. En ese caso, esos resultados no permiten pasar DMARC para el remitente visible.
Si el servicio permite configurar una firma DKIM válida con d=example.com, esa firma puede aportar el pase alineado que DMARC necesita. No hace falta que SPF y DKIM pasen ambos alineados: basta uno de los dos. Configure el dominio siguiendo las instrucciones de la plataforma y compruebe un mensaje real antes de endurecer la política.
Separe autenticación y alineación
DMARC no se satisface porque un panel muestre por separado “SPF configurado” y “DKIM configurado”. Debe pasar al menos uno de esos mecanismos y estar alineado con el dominio visible de From, según el modo aplicable.
Una plataforma puede firmar correctamente con su propio dominio sin que esa firma quede alineada con el de su empresa. Por eso hay que revisar mensajes reales. Microsoft describe la relación entre estas identidades.
Haga que los reportes respondan una pregunta
La pregunta no es “¿qué porcentaje sale verde?”, sino “¿qué sistemas autorizados siguen fallando y por qué?”. Asigne cada origen conocido a un responsable: facturación, campañas, usuarios o aplicaciones. Investigue lo desconocido sin autorizarlo automáticamente.
Los reportes agregados ayudan a observar tráfico, pero dependen de los receptores que los envían y pueden llegar con retraso. No equivalen a un registro completo de todos los mensajes ni contienen necesariamente la explicación que necesita para un caso individual.
Acuerde quién tendrá acceso a esos reportes y dónde se conservarán. Si utiliza un servicio externo para analizarlos, revise antes qué información recibirá.
El calendario lo marca su operación
Una semana puede no incluir el cierre de facturación, una campaña mensual o un proceso que solo se ejecuta ocasionalmente. Observe un periodo representativo de sus envíos, no un plazo elegido solo para terminar el proyecto.
Google recomienda un despliegue gradual. Utilice ese principio junto con su inventario y pruebas: corregir fuentes legítimas, aplicar una política más exigente de forma controlada y revisar las incidencias antes de ampliar el alcance.
p=none no garantiza entrega: otros filtros siguen actuando. Del mismo modo, una política solicitada no obliga a todos los receptores a tratar cada mensaje de forma idéntica.
Qué comprobar antes del siguiente paso
Pida muestras de cada ruta relevante y conserve sus resultados de SPF, DKIM y DMARC. Incluya sistemas que reenvían o modifican mensajes cuando existan: no se comportan necesariamente como un envío directo.
Antes del cambio, registre la configuración anterior, la persona que puede revertir y el canal para recibir incidencias. Si aparecen fallos legítimos, identifique el origen y corrija el problema; no añada autorizaciones amplias sin entenderlas.
Lo que DMARC no promete
La política ayuda a tratar el uso no autenticado de su dominio. No impide que alguien copie el nombre de un gerente, registre un dominio parecido o envíe desde una cuenta legítima comprometida. El control de pagos y la protección de las cuentas siguen siendo necesarios.
