Un dominio puede ser nuevo para su organización sin estar libre de dependencias de correo. Un nuevo sitio web puede utilizar un nuevo registro, mientras que un nombre adquirido o vuelto a registrar puede haber heredado aplicaciones, reglas de reenvío o expectativas que el nuevo propietario aún no ha descubierto.
El primero útil DMARC La decisión es, por tanto, una decisión con propósito. Establece quién controla el dominio, qué enviará, qué recibirá y quién puede aprobar un cambio. Luego configure y verifique los registros relevantes para ese alcance.
Crear un pequeño registro de propósito
Trate el dominio como un activo con un propietario responsable. Registre la cuenta del registrador, el proveedor DNS autorizado, el contacto de renovación, el aprobador de cambios y el uso previsto. El acceso administrativo debería sobrevivir a la salida del personal.
Siga enviando y recibiendo como dos campos separados:
- Uso previsto: Sitio web únicamente; Pregunta de envío: ¿Se puede enviar cualquier formulario, herramienta de soporte o aplicación utilizando este dominio?; Pregunta de recepción: ¿Los clientes o servicios necesitan una dirección aquí?
- Uso previsto: correo transaccional de productos; Pregunta de envío: ¿Qué cuentas de aplicaciones y rutas de recuperación envían?; Pregunta de recepción: ¿Adónde irán las respuestas, los errores de entrega y las solicitudes de soporte?
- Uso previsto: correo de empleados; Pregunta de envío: ¿Qué usuarios, delegados y herramientas conectadas envían?; Pregunta de recepción: ¿Qué buzones de correo, alias y rutas de reenvío existen?
- Uso previsto: Registro defensivo; Pregunta de envío: ¿La organización ha aprobado algún envío?; Pregunta de recepción: ¿Se requiere algún servicio entrante?
Este registro sugerido hace visibles los supuestos ocultos. “No hay buzones de empleados” no establece que un dominio no envíe nada.
Compruebe si hay una dependencia de correo menos obvia
Antes de declarar que un dominio no envía, inspeccione los formularios del sitio web, las herramientas de monitoreo, la configuración del comercio electrónico, los sistemas de facturación, los proveedores de identidad y las plataformas de soporte. Pregunte si utilizan el dominio como remitente visible, dirección de devolución del sobre o un DKIM dominio de firma.
Para un dominio adquirido, incluya los contratos y los propietarios de las aplicaciones de la transferencia de adquisición. Una instantánea DNS registra lo que se publica ahora; no prueba la ausencia de una solicitud inactiva o de un mensaje previsto para el próximo mes.
Usar el inventario del remitente para adjuntar cada uso descubierto a una cuenta y un propietario designados. Conserve los cheques sin respuesta como hallazgos abiertos en lugar de convertir el silencio en aprobación.
Verificar dónde pertenecen realmente los cambios DNS
Confirme los servidores autorizados y el nombre exacto del propietario completo antes de publicar. Una cuenta de registrador y una cuenta de alojamiento DNS pueden ser sistemas diferentes. La delegación de subdominio puede mover una parte particular del árbol de nombres a otra autoridad.
Para un nuevo dominio de envío, siga la configuración generada por la plataforma para la cuenta real. La publicación de una clave DKIM o un registro de delegación no es prueba de que el servicio haya comenzado a firmar; RFC 6376 §3.6.2.1 y RFC 6376 §5 recuperación y firma de claves por separado. Envíe un mensaje controlado a través de la ruta prevista e inspeccione la verificación recibida confiable y alineación.
Bajo RFC 9989 §4.5, la política DMARC se publica en el nombre _dmarc correspondiente. Un valor colocado en la raíz del dominio no sustituye al nombre de ese propietario. El flujo de trabajo de publicación conecta la verificación DNS con mensajes y evidencia de informes.
Elija la sucursal correcta para un dominio que no envía
un genuinamente dominio no emisor puede publicar una política que exprese la preferencia de manejo del propietario para el uso no autorizado de su dominio De. Una política DMARC restrictiva es una decisión de alcance que aún depende de la implementación y el análisis del receptor.
SPF y el servicio entrante requieren decisiones separadas. Bajo RFC 7208 §5.1 y RFC 7208 §4.6.2, un ejemplo v=spf1 -all La política establece que esa política SPF no autoriza ninguna fuente para el dominio evaluado. Por sí solo no describe todos los subdominios posibles ni bloquea el correo entrante.
Una declaración MX nula se refiere a la recepción. RFC 7505 §3 lo define como el único registro MX, con preferencia cero y objetivo de un solo punto, para un dominio que no acepta correo. La orientación en RFC 7505 §4.2 dice dominios utilizados en CORREO DE o la dirección De remitente visible no debe publicar MX nulo. No lo apliques simplemente porque el dominio no tiene una bandeja de entrada normal.
Usar la guía de dominio no emisor antes de combinar estos controles. Expresan intenciones diferentes y deben estar de acuerdo con el uso real.
Trabajar a través de un nuevo dominio de producto ficticio
Supongamos que una empresa registra el dominio de un producto. Su lista de verificación de lanzamiento etiqueta el nombre "solo sitio web", pero tres comprobaciones revelan otros usos:
- Descubrimiento: un servicio de restablecimiento de contraseña utilizará el dominio del producto en Desde; Consecuencia: El nombre es un dominio emisor.
- Descubrimiento: las respuestas deben llegar a una dirección de soporte; Consecuencia: se requiere una ruta entrante
- Descubrimiento: una región de aplicación de respaldo utiliza una cuenta de proveedor separada; Consecuencia: Esa cuenta necesita su propia configuración y evidencia de mensajes.
El siguiente paso correcto es revisar el registro de propósitos, configurar las rutas aprobadas y verificarlas. La aplicación de un conjunto de registros sin envío contradeciría el servicio planificado.
Es posible que un nombre defensivo independiente realmente no tenga un uso aprobado para envío o recepción. Su propietario puede elegir controles para ese propósito diferente y documentar los controles que respaldan la clasificación.
Haga de la presentación de informes una vía operativa operativa
Si se solicitan informes agregados, verifique el destino y cualquier autorización de destino externo requerida en RFC 9990 §4. Decida quién revisará los informes y cómo se investigará el tráfico inesperado. Una dirección de informe no es útil simplemente porque aparece en un valor TXT .
Un nuevo dominio puede producir poco tráfico legítimo. Bajo RFC 9990 §3.1 y RFC 9989 §5.3.8, una colección vacía podría reflejar que no se ha observado ningún correo, que no hay participación del destinatario o que hay un problema de recogida. Utilice pruebas controladas y controles de recopilación para distinguir esas posibilidades.
Mantener la privacidad y el acceso de los informes proporcionales al propósito. La guía de privacidad de informes Explica cómo evaluar los datos recopilados.
Revisar los cambios de propósito antes de habilitar un nuevo servicio
La configuración inicial no debería convertirse en un obstáculo que los equipos sorteen. Cuando un dominio obtiene correo de empleados, uso transaccional o un nuevo subdominio, requiere una actualización de propósito y la correspondiente autenticación y revisión de recepción.
La participación total actual DMARC requiere más de un solo mensaje de paso: los requisitos en RFC 9989 §8 incluir SPF y DKIM alineados, informes y publicación de políticas. Los dominios de empleados de propósito general también necesitan la evaluación de interoperabilidad en RFC 9989 §7.4 antes de elegir rechazar.
El resultado duradero es un dominio cuyo propietario, propósito y registros coinciden. Revise ese acuerdo cuando cambie la función comercial del dominio, en lugar de asumir que la etiqueta del primer día seguirá siendo precisa para siempre.
Mantenga la siguiente acción específica
El dispositivo de dominio de producto necesita tanto una ruta de envío aprobada como una ruta de respuesta, por lo que su etiqueta de solo sitio web debe cambiar antes de seleccionar controles que no sean de envío. La cuenta de respaldo sigue siendo una tarea de verificación distinta. Las preferencias de manejo Null MX , SPF -all y DMARC no son interruptores intercambiables. Se trata de consecuencias de planificación, no de registros realizados o de una evaluación real de la adquisición.