DMARC y el cifrado resuelven diferentes riesgos del correo electrónico. DMARC ayuda a un sistema receptor a evaluar si un dominio se está utilizando a través de una ruta alineada y autenticada. El cifrado protege los datos del mensaje a lo largo de un salto de transporte o, con un diseño diferente, entre puntos finales del mensaje. Ninguno de los controles suministra automáticamente al otro.
Esa distinción es importante porque el mismo mensaje puede estar bien autenticado y aun así viajar sin la seguridad de transporte que pretendía. Un mensaje también puede viajar a través de una conexión cifrada mientras reclama un dominio De que no tiene autenticación alineada.
Comience con la pregunta de protección
Pregunte qué se debe proteger antes de seleccionar el control:
- Pregunta de protección: ¿Un dominio autenticado de paso está alineado con el dominio en Desde?; Mecanismo relevante: DMARC con SPF o DKIM; Lo que no establece: Confidencialidad, intención del remitente o contenido seguro
- Pregunta de protección: ¿El mensaje fue firmado por un titular de una clave privada DKIM para el dominio d=?; Mecanismo relevante: DKIM ; Lo que no establece: identidad humana, secreto o ubicación de la bandeja de entrada
- Pregunta de protección: ¿Era necesario este salto de entrega SMTP para utilizar TLS aceptable?; Mecanismo relevante: MTA-STS u otra política de transporte; Lo que no establece: Confidencialidad de extremo a extremo o Desde-dominio alineación
- Pregunta de protección: ¿Puede un destinatario descifrar el contenido destinado a ese destinatario?; Mecanismo relevante: cifrado a nivel de mensaje; Lo que no establece: alineación DMARC a menos que se configure por separado
Esta matriz describe los límites de control, no una clasificación de productos. Una arquitectura completa puede utilizar más de un mecanismo porque las amenazas no son intercambiables.
Siga una ruta de mensaje sintética
Considere una factura ficticia enviada desde billing@shop.example.com a accounts@buyer.example.org mediante entrega SMTP directa. El servicio de envío utiliza un dominio de sobre en bounce.mailer.example.net y firma con d=shop.example.com. Asuma una política DMARC aplicable y verificaciones de identidad completadas. En este escenario sintético, el envío MTA descubre y recupera una política MTA-STS en modo obligatorio válida para el dominio receptor buyer.example.org de https://mta-sts.buyer.example.org/.well-known/mta-sts.txt. Comprueba que el destino seleccionado, mx1.buyer.example.org , coincida con la política, luego se conecta y negocia TLS , validando el certificado MX antes de transferir el mensaje.
Bajo RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2 y RFC 8461 §5, los controles hipotéticos respaldarían estas afirmaciones:
- DKIM puede proporcionar una ruta de paso alineada porque la firma verifica y su dominio d= coincide con el dominio De en este ejemplo.
- DMARC puede pasar a nivel de mensaje a través de esa ruta DKIM alineada.
- El salto SMTP receptor utilizó TLS de acuerdo con la política de transporte publicada del dominio receptor, asumiendo que la política era válida, estaba actualizada y se aplicaba correctamente.
- Ninguno de esos hechos prueba que la factura sea genuina, que la cuenta del remitente no haya sido comprometida o que cada copia anterior y posterior del mensaje permanezca encriptada.
Ahora cambie solo el dominio de firma a d=mailer.example.net. DKIM aún podría aprobarse, pero ese dominio no relacionado no se alinearía con shop.example.com . Un salto de entrega protegido por TLS no repara ese error de alineación.
Mantenga la firma y el cifrado DKIM separados
Bajo RFC 6376 §3.7, DKIM aplica una firma criptográfica sobre los datos del mensaje seleccionado. El verificador utiliza una clave pública publicada para el selector y d= dominio. La firma proporciona evidencia sobre el contenido firmado y el dominio de firma. No oculta el mensaje.
El cifrado tiene un propósito diferente. Bajo RFC 3207 §6, SMTP TLS protege los datos en una conexión negociada entre sistemas, no la ruta completa del mensaje de un extremo a otro. MTA-STS permite que un dominio receptor publique una política que los remitentes compatibles pueden usar al validar la entrega TLS a sus hosts MX . Los informes TLS pueden proporcionar comentarios agregados sobre fallas de transporte en RFC 8460 §4.1, RFC 8460 §4.2 y RFC 8460 §4.3. Estos controles no convierten el correo SMTP en un objeto cifrado de un extremo a otro.
El cifrado a nivel de mensaje es otra capa, ilustrada por S/MIME en RFC 8551 §1 y RFC 8551 §3.3. Puede proteger el contenido para que sólo los puntos finales previstos con claves adecuadas puedan leerlo, pero la distribución de claves y el procesamiento de certificados, como RFC 8551 §4 asunto. La capacidad del destinatario, la recuperación y el acceso a los archivos también necesitan un diseño operativo explícito. DMARC sigue siendo una evaluación separada del dominio De origen visible y la autenticación alineada.
Definir cada decisión de confianza
Un registro de diseño útil nombra cuatro cosas para cada control:
- Control: DMARC ; Identidad o activo: Dominio en Desde; Ancla de confianza: política DNS más resultado SPF o DKIM alineado; Evidencia a conservar: resultado del receptor confiable y política aplicable
- Control: DKIM ; Identidad o activo: Dominio de firma y selector; Ancla de confianza: clave pública DNS ; Evidencias a conservar: firma, resultado de la verificación y registro clave
- Control: MTA-STS ; Identidad o activo: Dominio receptor y transporte MX ; Ancla de confianza: descubrimiento DNS más política HTTPS; Evidencia a conservar: ID de política, política obtenida y resultado de entrega
- Control: Cifrado de mensajes; Identidad o activo: claves de destinatario o punto final; Ancla de confianza: clave elegida y modelo de confianza del certificado; Evidencia a conservar: estado de cifrado, asignación de destinatarios y ciclo de vida de la clave
No los traduzcas en una única insignia verde. Cada respuesta tiene un significado más limitado y un modo de falla diferente.
Asignar controles a amenazas
DMARC puede hacer que el uso no autorizado de un dominio De protegido sea más fácil de identificar y manejar para los receptores participantes. No impide que se haga un mal uso de una cuenta legítima, ni inspecciona si una solicitud de pago es verdadera ni cifra el correo almacenado.
TLS puede reducir la exposición a la interceptación pasiva en un salto protegido. No autentica el dominio De. Un sistema que negocia TLS con un destino incorrecto o que no es de confianza no ha logrado la misma seguridad que una conexión validada y aplicada por políticas.
El cifrado de mensajes puede proteger el contenido más allá de la sesión de transporte, según su diseño. Por sí solo no crea una alineación DMARC , no autoriza una transacción comercial ni elimina el compromiso de los terminales.
Construya evidencia sin exagerar
Para la identidad, capture un mensaje recibido representativo y registre De, la identidad del sobre, cada dominio DKIM d=, los resultados de autenticación sin procesar, la alineación y la disposición DMARC . Para el transporte, conserve la política MTA-STS , el alcance MX y la evidencia de informes TLS . Para el cifrado de mensajes, documente quién posee las claves, cómo se inscriben los destinatarios, qué sucede cuando se pierde una clave y qué sistemas pueden acceder al texto sin formato.
Una prueba de laboratorio debe etiquetarse como prueba. No prueba que todas las rutas de producción se comporten de manera idéntica. Valide servicios de bajo volumen, rutas de reenvío, hosts MX de respaldo y acceso móvil o a archivos cuando afecten el objetivo de control.
Asignar propietarios y rutas de recuperación independientes
Las operaciones de correo suelen poseer autenticación y transporte SMTP . La arquitectura de seguridad puede poseer políticas, cobertura de amenazas y estándares de cifrado. Los equipos de aplicaciones son propietarios de las rutas de envío que generan el correo comercial. Los equipos legales y de registros pueden influir en los requisitos de retención de contenido y recuperación de claves.
Asigne a cada control un desencadenante de escalada. Una regresión de alineación se aplica a la propiedad del remitente y a las operaciones de correo. Un error en la política TLS afecta a los propietarios DNS y de transporte. Una clave de cifrado de mensaje perdida pasa al proceso de recuperación de administración de claves. Una cola genérica de "seguridad del correo electrónico" oculta la decisión que se debe tomar.
Haga explícita la decisión de compra
Antes de aprobar un proyecto, escriba una oración para el resultado requerido. "Reducir el uso no autorizado de nuestros dominios De" apunta hacia DMARC y la autenticación alineada. "Requerir TLS aceptable para la entrega a nuestro dominio" apunta a la política de transporte. "Mantener el contenido del mensaje ilegible fuera de los puntos finales aprobados" requiere un diseño de cifrado de mensajes.
Esos resultados pueden coexistir. La decisión importante es financiar la protección que falta en lugar de asumir que un acrónimo familiar de seguridad del correo electrónico cubre la identidad, la confidencialidad y la legitimidad empresarial al mismo tiempo.
Mantenga la conclusión dentro de la evidencia.
Para la fijación de facturas, mantenga la alineación DKIM exitosa y el salto SMTP validado en diferentes campos de evidencia. Si solo d= cambia al dominio del proveedor no relacionado mientras SPF permanece sin alinear, TLS aún no crea una identidad alineada. La búsqueda de políticas, la negociación TLS y la verificación de firmas que se describen aquí se suponen aportaciones didácticas, no pruebas de mensajes o de red realizadas.