Publicar un Registro DMARC cambia la política y la información de informes que los receptores participantes pueden descubrir para un dominio. No configura SPF, agregar DKIM firmas, inventariar remitentes legítimos o obligar a todos los destinatarios a tomar la misma decisión de entrega.
Trate el cambio DNS como un paso en un programa controlado. El cambio seguro depende de la evidencia de las rutas de envío reales del dominio.
Separe la publicación de la preparación
Referencias del protocolo: RFC 9989 §4.5, RFC 9989 §4.4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.8. Las listas de verificación operativas y las decisiones que aparecen a continuación son orientación editorial.
Un registro DMARC se publica en un nombre DNS _dmarc aplicable. Su política puede solicitar ninguno, poner en cuarentena o rechazar el manejo de mensajes que no cumplan con el DMARC evaluación. El registro también puede solicitar informes y establecer otros parámetros activos.
La publicación no alinea al remitente. SPF alineación Depende de la identidad del sobre autenticado y del dominio De. La alineación DKIM depende del dominio d= de una firma que pasa y del dominio De. Al menos una ruta alineada que pasa puede satisfacer un resultado a nivel de mensaje. La participación total requiere tanto SPF como DKIM alineados bajo RFC 9989 §8; Los dominios rechazados NO DEBEN depender únicamente de SPF y DEBEN aplicar firmas DKIM válidas según RFC 9989 §7.4.
Un récord que solicita el rechazo antes de que las rutas legítimas estén listas puede exponer esas rutas a la acción del receptor. Un registro que no solicita un manejo específico de una política puede respaldar el monitoreo, pero no se garantiza que los informes cubran todos los mensajes o receptores.
Cree una matriz de preparación remitente por remitente
La siguiente es una plantilla operativa ilustrativa, no una afirmación sobre un entorno real:
- Remitente: Correo corporativo; Propietario de la empresa: TI en el lugar de trabajo; Del dominio: example.com ; SPF alineado observado: Sí; DKIM alineado observado: Sí; Prueba representativa: actual; Preparación para la aplicación de la ley: pruebas disponibles; sujeto a revisión completa de preparación
- Remitente: Plataforma de facturación; Propietario del negocio: Sistemas financieros; Del dominio: billing.example.com ; SPF alineado observado: No; DKIM alineado observado: Sí; Prueba representativa: actual; Preparación para la aplicación de la ley: ruta alineada a nivel de mensaje observada; revisión más amplia de las necesidades de preparación
- Remitente: alertas heredadas; Propietario del negocio: Infraestructura; Del dominio: example.com ; SPF alineado observado: No; DKIM alineado observado: No; Prueba representativa: actual; Preparación para la aplicación de la ley: no listo
- Remitente: encuesta estacional; Propietario del negocio: Marketing; Del dominio: news.example.com ; SPF alineado observado: Desconocido; DKIM alineado observado: Desconocido; Prueba representativa: faltante; Preparación para hacer cumplir la ley: retener e investigar
"Sí" debe provenir de la evidencia del mensaje recibido, no de una afirmación del panel de control. "Desconocido" no es lo mismo que "No". Significa que el propietario del cambio carece de pruebas suficientes para tomar la decisión de hacer cumplir la ley.
Registre la diferencia de política
Capture el nombre exacto del propietario DNS , el valor anterior, el valor propuesto, las observaciones del solucionador, el cambio de propietario y la aprobación. Una diferencia ficticia simple podría ser:
- Campo: Propietario; Antes: _dmarc.example.com ; Propuesto: _dmarc.example.com
- Campo: Política; Antes: p=none; Propuesto: p=quarantine
- Campo: Informes agregados; Antes: Destino autorizado existente; Propuesto: Sin cambios
- Campo: Política de subdominio; Antes: Heredado de p; Propuesto: Revisado explícitamente
- Campo: Bandera de prueba; Antes: No presente; Propuesto: No presente
No se trata de promover una política específica. Es hacer visible cada cambio semántico. Si el registro también cambia los destinos de los informes, los modos de alineación, el tratamiento del subdominio o un indicador de prueba, revise esas decisiones por separado.
Comprenda lo que pide la política
Referencias del protocolo: RFC 9989 §4.7, RFC 9989 §5.4. Las listas de verificación operativas y las decisiones que aparecen a continuación son orientación editorial.
Una política es la evaluación solicitada por el propietario del dominio para el correo que no pasa DMARC . Los receptores conservan su discreción y pueden utilizar políticas locales, pruebas adicionales y excepciones. Un publicado p=reject Por lo tanto, el valor no garantiza que todos los mensajes defectuosos sean rechazados, y un valor p=none no garantiza la entrega.
El receptor también determina si implementa las especificaciones y los comportamientos de notificación relevantes. Supervise los resultados reales en lugar de convertir una cadena DNS en una promesa universal.
RFC 9989 incluye la bandera de prueba t activa. Cuando se aplica t=y , su efecto definido es una reducción de un nivel en la evaluación de p, sp o np declarada: el rechazo se trata como cuarentena y la cuarentena como ninguna. No es una implementación porcentual arbitraria y no cambia una evaluación nula declarada. La implementación del receptor sigue siendo importante.
Sepa qué publicación no soluciona
La publicación DMARC no:
- fusionar múltiples políticas SPF ;
- agregar un firma DKIM a una solicitud;
- cambiar el sobre de un servicio o el dominio de firma;
- demostrar que cada fuente observada es legítima;
- proteger nombres para mostrar en dominios no relacionados;
- reparar reenvíos o transformaciones de listas de correo;
- garantizar la entrega del informe;
- establecer la ubicación de la bandeja de entrada;
- autorizar una transacción comercial.
Cada hueco necesita su propio dueño. El registro DMARC describe una política de dominio; no es un comando de orquestación para cada aplicación de envío.
Aprobar la ejecución a partir de pruebas representativas
Un registro de aprobación útil nombra los dominios dentro del alcance, la versión del inventario del remitente, la fecha de la evidencia, las excepciones no resueltas, la política de destino, los criterios de reversión y el aprobador responsable. Incluya remitentes de bajo volumen, programados y de emergencia. Una semana sin fallas observadas no es suficiente si nunca se ejercieron los sistemas trimestrales o anuales.
Utilice un mensaje recibido por un representante de cada ruta. Registre el dominio De, la identidad del sobre, los valores DKIM d=, los resultados confiables y la alineación. Informes agregados pueden ayudar a identificar patrones, pero no reemplazan la confirmación del propietario ni las pruebas a nivel de mensaje.
Los flujos de correo indirecto merecen una atención especial. El reenvío y la modificación de mensajes pueden afectar SPF y DKIM de forma diferente. No resuelva una excepción de reenvío conocida debilitando la autenticación de un remitente no relacionado sin evidencia.
Verificar después del cambio DNS
Después de la publicación:
- Consulta el nombre exacto del propietario a través de solucionadores independientes.
- Confirme que se pueda descubrir un registro de política DMARC coherente.
- Permita el almacenamiento en caché DNS antes de interpretar observaciones mixtas.
- Envío de pruebas controladas a través de rutas representativas.
- Verifique los resultados del receptor, no solo los registros de aplicaciones salientes.
- Compare las fallas con el inventario de remitentes aprobados.
- Esté atento a los canales de soporte empresarial para detectar rutas retrasadas o intermitentes.
La ventana de observación debería abarcar ciclos económicos significativos. Establezca condiciones de parada explícitas en lugar de esperar un número arbitrario de días.
Definir la reversión antes de la aplicación
Referencias del protocolo: RFC 9990 §4. Las listas de verificación operativas y las decisiones que aparecen a continuación son orientación editorial.
La reversión es un cambio DNS controlado, no una eliminación sin análisis. Registre el valor anterior y la condición que justifica una reducción de la póliza. Una reversión puede reducir la política mientras se repara el remitente afectado, pero debe preservar la evidencia y evitar la introducción de múltiples registros.
Si los destinos de los informes son externos al dominio de políticas, asegúrese de que exista la autorización requerida. Se debe investigar una falla en la presentación de informes, pero la ausencia de informes por sí sola no prueba que la política no esté siendo evaluada.
Trate la publicación como una decisión gobernada
El propietario DNS ejecuta el cambio. Las operaciones de correo validan la autenticación. Los propietarios de las aplicaciones confirman rutas legítimas. La seguridad acepta riesgos residuales de suplantación y entrega. Los dueños de negocios aprueban el efecto en las comunicaciones críticas.
Esa separación evita que una única edición TXT asuma silenciosamente la responsabilidad de las aplicaciones que no puede configurar y las decisiones del receptor que no puede controlar.
Aplicar la evidencia sin exagerarla
En la matriz de preparación ficticia, mantenga las rutas heredadas y estacionales para la investigación. La observación DKIM alineada de facturación demuestra una posible ruta a nivel de mensaje, no una participación completa ni la aprobación del propietario. Registre la evidencia que falta antes de elegir la política. No se realizó ninguno de los cambios o envíos DNS ilustrados.