Una política de rechazo puede ser una parte útil para proteger un dominio de envío. No puede establecer que cada mensaje que recibe una persona es seguro, que cada receptor realizará la misma acción o que un remitente autenticado está actuando con honestidad.
La cuestión práctica no es si un dominio ha alcanzado una etiqueta de política particular. Se trata de a qué ruta de suplantación se dirige el control y qué evidencia respalda la siguiente decisión. Un programa de seguridad necesita que esos límites se establezcan claramente antes de que un porcentaje del tablero se convierta en un reclamo de la gerencia.
Describir la identidad controlada
Bajo RFC 9989 §5.3.5, DMARC evalúa el uso del dominio en la dirección De visible frente al paso, alineado SPF o DKIM evidencia. Se aplica una política a esa relación de dominio. No autentica un nombre para mostrar, no aprueba una solicitud de pago ni juzga un sitio web vinculado; RFC 9989 §5.4 deja claro que el uso de dominio validado no es una afirmación de valor sobre un mensaje.
Una política de rechazo expresa la evaluación solicitada por el propietario del dominio para los mensajes que no superan la validación. El tratamiento final por parte del receptor depende también de su propio análisis. RFC 9989 RFC 9989 §7.4 requiere específicamente que los destinatarios consideren más que una política de rechazo publicada, particularmente cuando se trata de correo indirecto legítimo.
Estos límites no hacen que el control carezca de importancia. Hacen que su cobertura sea medible. Usar la guía de selección de políticas para conectar la política con el propósito real del dominio.
Pruebe cuatro historias de ataques diferentes
Los siguientes escenarios son ilustrativos. No son incidentes de clientes ni resultados medidos de ataques.
- Escenario: un remitente utiliza el dominio De origen exacto de una organización sin una identidad alineada de paso; Lo que puede mostrar la evidencia del dominio: la falla DMARC puede informar el manejo según la política aplicable; Aún se necesita control: análisis del receptor, seguimiento y respuesta a incidentes
- Escenario: un remitente utiliza un dominio diferente con un nombre para mostrar ejecutivo convincente; Lo que puede mostrar la evidencia del dominio: ese dominio diferente puede autenticarse exitosamente; Aún se necesita control: detección de suplantaciones e informes de usuarios
- Escenario: se toma el control de una cuenta legítima y se envía a través de una ruta aprobada; Lo que puede mostrar la evidencia del dominio: el mensaje puede tener una autenticación alineada válida; Aún se necesita control: seguridad e investigación de la cuenta
- Escenario: Un proveedor envía un mensaje autenticado solicitando un cambio de cuenta bancaria fraudulento; Qué puede mostrar la evidencia del dominio: El uso del dominio por parte del proveedor puede validarse; Aún se necesita control: verificación independiente de cambios de pago
Un solo”phishing "bloqueado" ocultaría estas diferencias. Etiquete las pruebas por identidad, ruta y control esperado. Para un ejercicio seguro, utilice cuentas de prueba autorizadas y contenido sintético; no hay necesidad de exponer a un destinatario real a una instrucción fraudulenta para establecer el límite del protocolo.
Verifique el correo legítimo antes de cambiar la política
Una política restrictiva puede afectar la comunicación legítima cuya autenticación falta o cuyas identidades no están alineadas. Inventario de cada servicio empresarial, su propietario y la cuenta o ruta que lo envía. Agregue evidencia de mensajes recibidos junto con el estado DNS .
Una matriz de preparación sintética podría mostrar la facturación verificada, el soporte verificado y un aviso de impuestos trimestral aún en espera de una prueba de envío. La decisión de lanzamiento correcta es resolver el flujo crítico faltante, no promediarlo porque la facturación representa la mayor parte del volumen.
Trate las fuentes desconocidas como no resueltas hasta que la evidencia las identifique. Un proveedor de nube conocido no demuestra su aprobación y una fila de informe fallida no demuestra que se trate de un ataque. Un inventario de remitentes mantenido da a esas investigaciones un lugar donde aterrizar.
Cuenta para listas de reenvío y correo
Un mensaje puede salir de su ruta original a través de un alias, reenviador o lista de correo. El reenvío cambia la fuente de conexión vista por el receptor final en RFC 7208 §10.3; Los cambios en el contenido cubierto pueden afectar la verificación DKIM según RFC 6376 §3.7. El fallo resultante puede referirse a un mensaje legítimo.
Actual RFC 9989 §7.4 advierte contra el rechazo de dominios de propósito general cuyos usuarios pueden publicar en listas de correo de Internet. También requiere que los dominios que publican rechazos apliquen firmas DKIM válidas en lugar de depender únicamente del SPF . Por lo tanto, un ámbito transaccional y un ámbito de correspondencia del personal pueden necesitar decisiones políticas diferentes.
Una prueba entregada a través de un transportista es evidencia de esa ruta y tiempo. No establece que cada lista, receptor o modificación futura se comporte de manera idéntica. Registre tanto la ruta de trabajo como la incertidumbre.
Mantener el registro de cambios vinculado al reclamo
Antes de aprobar un cambio de política, conserve el registro anterior, la diferencia propuesta, el alcance del dominio, el propietario, la evidencia revisada y la acción de recuperación. Luego, compare las transmisiones legítimas observadas, los errores devueltos y los informes disponibles. Registre los resultados reales en lugar de asumir que una publicación DNS exitosa demuestra una comunicación exitosa.
Para un ejercicio sintético, la nota de cambio podría decir que se consideró un dominio de recepción dedicado para una evaluación más sólida después de que se revisaron sus servicios conocidos y rutas indirectas. No debería decirse que se eliminó todo el phishing. La evidencia respalda una decisión sobre ese dominio y sus flujos de correo documentados.
Informe el riesgo residual en un lenguaje útil
Una declaración de gestión clara nombra el dominio, la población monitoreada, los servicios legítimos verificados, la política actual y las debilidades restantes. Mantiene los hallazgos de dominios falsificados separados del compromiso de la cuenta, dominios similares y fraude en transacciones.
Las acciones de seguimiento útiles incluyen eliminar permisos de envío obsoletos, mejorar la protección de la cuenta, validar solicitudes confidenciales a través de un canal independiente conocido y mantener un proceso de informes para correo sospechoso. Esas acciones abordan diferentes caminos de falla; su valor no debe atribuirse a la Registro DMARC solo.
El resultado que se debe buscar es preciso: se comprende y mantiene el uso legítimo del dominio De origen elegido, se investigan las fallas y la política se adapta al uso del dominio. Mantenga visibles los escenarios de fraude restantes para que una política de dominio más sólida no se convierta en una falsa promesa en cada mensaje.
Registrar una decisión que pueda ser revisada
Para los cuatro escenarios, mantenga resultados separados para fallas en el dominio exacto, un dominio autenticado diferente, apropiación de cuenta y una solicitud de cambio de pago autenticada. No los sume en una afirmación de éxito DMARC sin reservas. Los controles de seguimiento propuestos son recomendaciones operativas, no garantías ni requisitos del protocolo DMARC . No se realizó ningún incidente, simulación de ataque o implementación de políticas.