Alcance: Cloud Mail no es todos los servicios de Web.com
Esta guía conserva el tema de autenticación de Web.com del catálogo, pero limita la implementación documentada a Cloud Mail. SPF. No es un verificado. DKIM Guía de configuración para cada paquete de correo electrónico de Web.com. La guía del proveedor disponible es una captura de Cloud Mail anterior, por lo que se debe confirmar la aplicabilidad de la cuenta actual antes de realizar un cambio. Un dominio comprado en Web.com no identifica, por sí solo, su servicio de correo electrónico saliente. Comience con la ruta de suscripción y envío en lugar del logotipo del registrador.
La página Cloud Mail distingue su producto de otros productos de correo electrónico. Enumera SPF como opcional dentro de su configuración DNS general. Su ejemplo normal es v=spf1 include:spf.cloudus.oxcs.net ~all . Para un paquete de alojamiento o formulario de contacto de sitio web, incluye spf.registeredsite.com y spf.cloudus.oxcs.net . pide uno Registro SPF. Estos son ejemplos documentados, no valores verificados con una cuenta de cliente actual. Configuración DNS de Web.com Cloud Mail
Establecer la ruta antes de elegir una póliza
Cree un pequeño inventario de aplicaciones productoras de mensajes. Distinguir una persona que envía a través de un buzón alojado de un sitio web que genera notificaciones, una plataforma de marketing que utiliza la misma dirección visible y un servicio de facturación de terceros. Para cada ruta, identifique el equipo que pueda confirmar su configuración real. Registre la incertidumbre explícitamente. Un recibo de compra de un dominio o sitio web no es prueba suficiente de que todas las aplicaciones utilicen la misma infraestructura de salida.
Una política SPF describe la infraestructura de envío autorizada para una identidad SMTP . No se limita a autenticar todos los mensajes cuyo campo De visible contenga el dominio. La identidad del sobre relevante puede diferir de ese campo visible. Esto es importante cuando un sitio web se envía a través de otro servicio o cuando una aplicación utiliza un servicio controlado por el proveedor. dirección de rebote. Una política puede ser sintácticamente correcta pero ser irrelevante para la identidad que se está evaluando. RFC 7208 , HELO y CORREO DE identidades
Por lo tanto, el inventario debe distinguir los hechos conocidos de las cuestiones pendientes de acceso a la cuenta. Marque el dominio del autor visible, el dominio del sobre esperado, la ruta de envío prevista y el propietario de la aplicación. Deje los valores desconocidos en blanco en lugar de derivarlos de una dirección de correo web. Este es un plan de recopilación de evidencia propuesto, no un informe de que algún mensaje ya haya sido inspeccionado.
Preservar los remitentes existentes al preparar SPF
antes de proponer un récord, conserva la respuesta TXT autorizada actual y su tiempo de recopilación a través de un proceso de cambio autorizado. Identifique la póliza SPF única con el nombre del propietario correspondiente. Otro Registros TXT pueden coexistir con ese nombre, pero no se pueden resolver varias políticas SPF simplemente eligiendo la que parezca más nueva. Varias cadenas de caracteres dentro de un registro de recursos TXT también son diferentes de varios registros de recursos. RFC 7208 , registros de recursos DNS y múltiples cadenas
Prepare una comparación del antes y el después que preserve a los remitentes aún autorizados. No reemplace una política de producción con un ejemplo breve de proveedor simplemente porque el ejemplo parece más fácil de entender. El mecanismo final para todos también expresa la intención política. Una muestra que termina en softfail no autoriza a debilitar una política existente, y una terminación más estricta no completa un inventario de remitentes no revisados.
Revise la ruta de evaluación completa, incluidas las inclusiones anidadas. El límite SPF se refiere a los términos de consulta de DNS evaluados, no simplemente al número de palabras incluidas visibles en la cadena de nivel superior. El almacenamiento en caché no hace válida una política excesiva. Capture la revisión de dependencia propuesta por separado de la afirmación de que una evaluación en vivo actual tuvo éxito. Aquí no se afirma tal evaluación. RFC 7208 , límites de búsqueda DNS e inclusión
Mantenga los cambios de enrutamiento y autenticación separados
Un cambio de autenticación no debería convertirse silenciosamente en una migración de buzón de correo. El propietario del cambio debe explicar por qué es necesaria cada edición DNS propuesta. Un cambio de destino de buzón tiene consecuencias de servicio diferentes a las de un cambio de autorización SPF . El plan de reversión debe ser específico para los registros realmente aprobados, en lugar de una instrucción amplia para restaurar toda la zona a partir de una exportación anterior.
Esta separación también protege aplicaciones no relacionadas. Un dominio puede alojar un sitio web público, correo entrante, registros de descubrimiento de servicios y servicios delegados de terceros. Una hoja de trabajo de autenticación debe identificar el nombre exacto del propietario, el tipo y el contenido previsto. No debería pedirle a un operador que copie una tabla DNS de proveedor completa sin comprender las consecuencias. La presentación DNS puede utilizar nombres relativos o absolutos según el editor; el operador debe confirmar el nombre del propietario resultante en lugar de asumir una regla de interfaz universal. RFC 1035 , formato de archivo maestro
DKIM y DMARC siguen siendo preguntas de aceptación separadas
El alcance SPF documentado no proporciona un Cloud Mail verificado Selector DKIM, clave pública o procedimiento de activación de firma. Esos campos siguen sin resolverse. No invente un selector predeterminado, no tome prestada una clave de un producto de alojamiento diferente ni trate la existencia de un SPF incluido como prueba de que los mensajes están firmados. La verificación DKIM depende del dominio de firma y del selector de la firma y de la clave publicada correspondiente. No se establece mediante una afirmación genérica que el alojamiento admita un correo electrónico seguro. RFC 6376 , DKIM-Signature y almacenamiento de claves
DMARC requiere un identificador autenticado de paso con la relación requerida con el dominio del autor visible. Pasar SPF para un dominio de sobre no relacionado no es suficiente. Por el contrario, pasar DKIM alineado puede proporcionar la ruta de autenticación calificada incluso cuando SPF no se alinea. La revisión operativa debería registrar qué camino respalda cada ruta real en lugar de exigir una combinación universal inventada. La autenticación no garantiza la ubicación de la bandeja de entrada ni prueba que la solicitud comercial de un mensaje sea legítima. RFC 9989 , alineación y alcance del identificador
Diagnóstico ficticio: dos aplicaciones, una ruta asumida
Consideremos la organización ficticia Marlin Workshop. Su administrador enumera a "Web.com" como propietario de los correos electrónicos del personal y de los recibos del sitio web. Un cambio propuesto copia el ejemplo SPF más corto y elimina una autorización existente sin verificar qué aplicación todavía la usa. Se trata de un error de planificación ficticio, no de un incidente notificado ni de una prueba ejecutada.
El revisor detiene el cambio y separa las dos filas de la aplicación. El propietario del buzón del personal debe identificar el producto real. El propietario del sitio web debe establecer cómo se envían los recibos. El operador DNS conserva la política existente y prepara una comparación revisada solo después de que esos datos estén disponibles. Si las rutas difieren, sus evidencias también deben diferir. El diagnóstico es una suposición no respaldada sobre la infraestructura compartida, no una prueba de que un proveedor en particular no pudo autenticar el correo.
Hoja de trabajo de aceptación en blanco
Complete esta hoja de trabajo sólo con observaciones autorizadas. Las celdas vacías significan evidencia no resuelta, no una prueba en vivo fallida.
- Evidencia de producto y suscripción: ______
- Confirmación y fecha del proveedor actual: ______
- Solicitud y propietario responsable: ______
- Dominio de autor visible: ______
- Identidad real del sobre y evidencia: ______
- Propietario autorizado actual SPF y valor: ______
- Cambio propuesto con remitentes retenidos: ______
- Dependencia anidada y revisión del límite de búsqueda: ______
- Capacidad DKIM , selector y evidencia de activación: ______
- Resultado de autenticación alineado real: ______
- Ventana de aprobación, reversión y observación de cambios: ______
Límite de liberación
Este manuscrito proporciona un método de revisión de alcance, no una configuración completa. La aplicabilidad actual del producto, los valores de cuenta generados, la publicación autorizada, la evidencia de mensajes recibidos, la revisión humana del tema, las rutas de producción, la accesibilidad visual y la autorización del propietario permanecen abiertas. El requisito más amplio de evidencia de implementación del catálogo no ha cambiado. No se realizaron ediciones DNS , solicitudes de soporte, mensajes ni pruebas de inquilinos para este borrador.