Alcance: hosting compartido Afrihost y cPanel
Afrihost publica instrucciones separadas para obtener registros de autenticación en cPanel y agregarlos a través del Editor DNS de alojamiento compartido de ClientZone. Esta guía sigue esa ruta documentada. No implica que Afrihost Pure Mail, un proveedor de buzones de correo externo o cada paquete de alojamiento utilice registros o controles de firma idénticos. Establezca el producto de correo electrónico real y el servicio DNS autorizado antes de preparar un cambio. Los valores específicos de la cuenta y la aplicabilidad de la interfaz actual siguen sin verificarse.
el proveedor SPF Las instrucciones de generación utilizan el área de entrega de correo electrónico de cPanel: seleccione Administrar junto al dominio, busque SPF y copie su Valor. Es DKIM Las instrucciones utilizan la misma área y la acción Instalar el registro sugerido. Estos son pasos propuestos por el operador, no acciones realizadas para este manuscrito. Generación Afrihost SPF Generación Afrihost DKIM
Generación, publicación y firma separadas
Un registro sugerido es evidencia de lo que recomienda una interfaz de configuración particular. No es evidencia de que la zona de autoridad pública contenga ese valor o de que un mensaje haya sido firmado y verificado exitosamente. Conserve el contexto del dominio junto con el registro sugerido. Un administrador que copia un valor de una cuenta de alojamiento incorrecta puede generar una solicitud de cambio aparentemente plausible pero irrelevante.
Para DKIM , distinga el material de verificación público de cualquier material de firma privado. El registro DNS contiene información de clave pública. Las claves privadas no deben recopilarse en la hoja de trabajo de aceptación ni pegarse en un ticket. El protocolo conecta la firma de un mensaje a un dominio de firma y selector; esos identificadores determinan dónde busca un verificador la clave. Un dominio visualmente similar o una etiqueta de cuenta genérica no pueden reemplazarlos. RFC 6376 , DKIM-Signature y almacenamiento de claves
El artículo sobre creación DKIM de Afrihost dice que el registro se puede copiar al clúster DNS del dominio después de instalar el registro sugerido. Trate esto como una razón para establecer quién sirve realmente DNS autorizado. Una vista de alojamiento local y una zona pública operada externamente pueden requerir propiedad de publicación diferente. No concluya que el registro público cambió simplemente porque una interfaz local mostró una notificación de éxito. Generación Afrihost DKIM
Prepara el cambio SPF sin descartar otros remitentes
La ruta documentada de ClientZone es Alojamiento, el dominio en Alojamiento compartido, Configuración de alojamiento, Editor DNS y luego Crear nuevo registro. Para SPF , el artículo especifica TXT , un campo de prioridad en blanco, el contenido SPF copiado y TTL 7200. Esa receta de interfaz no justifica la creación de una segunda política SPF cuando ya existe una. Revise la política existente y combine solo los cambios de autorización aprobados. Publicación Afrihost SPF
SPF evalúa la identidad SMTP , incluyendo CORREO DE, en lugar de simplemente confiar en el campo From legible por humanos. Solicitudes de inventario que envían para obtener la identidad relevante antes de modificar su política. Los envíos de buzones de correo alojados, las notificaciones de sitios web y una herramienta de marketing externa pueden tener diferentes sobres e infraestructura. No asuma que un cPanel predeterminado incluye todos los servicios que la organización ha adoptado. RFC 7208 , HELO y CORREO DE identidades
Conserve una póliza SPF aplicable a nombre del propietario. Revise las inclusiones anidadas y otros términos de consulta de DNS con respecto al límite de términos evaluados del protocolo. Una política corta de alto nivel aún puede tener un camino de dependencia excesiva. Registre el método de revisión y el tiempo de evidencia, pero no etiquete un plan no ejecutado como una evaluación en vivo exitosa. Una respuesta almacenada en caché no renuncia a las reglas de evaluación. RFC 7208 , registros múltiples y límites de búsqueda DNS
Resuelva la ambigüedad del nombre del propietario DKIM antes de la publicación
La página de publicación DKIM de Afrihost describe la ruta ClientZone y cómo pegar un valor DKIM TXT . Sin embargo, su texto incluye un encabezado de instrucción con etiqueta SPF y un campo de nombre de dominio genérico en lugar de un selector completo de propietario específico de la cuenta. Esos detalles no son una base segura para inventar un registro DKIM superior. Obtenga y revise el nombre y el valor completos generados para el dominio real y resuelva la convención de nomenclatura del editor antes de autorizar la publicación. Publicación Afrihost DKIM
En DKIM , el selector y el dominio de firma forman el nombre de búsqueda de clave debajo de _domainkey . El selector real debe provenir de la configuración admitida de la cuenta y coincidir con los mensajes que se firman. No proporcione un selector adivinado simplemente porque otro servicio lo utilice. La misma regla se aplica a una clave pública copiada: su sintaxis por sí sola no establece que el firmante previsto posee la clave privada correspondiente. RFC 6376 , almacenamiento de claves
Confirme si el editor espera una etiqueta relativa o un nombre de propietario completo. Las convenciones de archivos maestros DNS incluyen un origen actual, pero los editores gráficos son interfaces de productos y necesitan su propia interpretación. El criterio de aceptación es el nombre completo del propietario resultante, no si el operador escribió una taquigrafía familiar. RFC 1035 , formato de archivo maestro
Interpretar los resultados de la autenticación de forma estricta
Algunos términos introductorios del proveedor describen que DKIM previene el spam o mejora la entrega. No conviertas esa descripción en una garantía. DKIM proporciona una firma criptográfica y una identidad de firma atribuible; no es cifrado del cuerpo del mensaje y no establece que todas las instrucciones comerciales del mensaje sean seguras. Una firma válida también es distinta de DMARC alineación. RFC 6376 , introducción
Para la ruta de envío real, una revisión de aceptación debe relacionar una identidad SPF o DKIM pasajera con el dominio de autor visible. DMARC puede pasar a través de cualquiera de los mecanismos alineados calificados. Un registro DNS que existe de forma aislada no establece esa relación para un mensaje. La autenticación tampoco garantiza la entrega, evita el filtrado de destinatarios ni demuestra que no se ha abusado de una cuenta. RFC 9989 , alineación y alcance del identificador
Diagnóstico ficticio: el propietario de la publicación equivocado
Imagine una asociación ficticia llamada Cedar Trail Club. Su voluntario obtiene un registro DKIM sugerido del dominio de cPanel correcto y luego copia solo el valor en una solicitud de cambio DNS . Otro operador asume que el registro pertenece a la raíz porque la solicitud no contiene ningún propietario del selector. Este es un escenario de planificación inventado, no una afirmación sobre un cliente de Afrihost o una prueba realizada aquí.
El revisor rechaza la solicitud incompleta sin adivinar un selector. El propietario de la aplicación debe proporcionar el registro público generado completo e identificar la ruta de firma prevista. El operador DNS debe confirmar la zona autorizada y el nombre del propietario resultante. Luego, el propietario de la versión requiere evidencia del mensaje real, obtenida a través de un proceso autorizado, antes de aceptar la firma y la alineación. La lección correctiva es preservar la relación entre el contexto generado, la ubicación de la clave pública y la identidad del mensaje en lugar de tratar un valor pegado como una configuración completa.
Hoja de trabajo de aceptación operativa en blanco
Esta hoja de trabajo es una propuesta. Ninguna celda está precompletada con un resultado de cuenta inventado.
- Producto de hosting, paquete y contexto de dominio: ______
- Operador autorizado de cPanel y referencia de aprobación: ______
- Proveedor DNS autorizado y propietario de la zona: ______
- Política SPF existente e inventario de remitentes legítimos: ______
- Valor SPF sugerido y política fusionada revisada: ______
- Nombre completo del propietario DKIM generado y valor público: ______
- Interpretación del nombre del editor y verificación de conflictos: ______
- Observación de registros públicos, marca de tiempo y alcance: ______
- Selector de mensajes real, dominio de firma e identidad del sobre: ______
- Evidencia de autenticación y alineación: ______
- Reversión, propietario responsable y decisión de liberación: ______
Retenciones operativas y de publicación
La aplicabilidad de la cuenta, los controles actuales del producto, la publicación DNS , la activación de la firma y la verificación de los mensajes recibidos permanecen abiertos. No se accedió a ninguna cuenta, no se instaló ningún registro sugerido, no se creó ningún registro DNS ni se envió ningún mensaje de prueba. También están abiertos la revisión del tema humano, la aplicabilidad de las fuentes, la evidencia del catálogo original, las rutas de producción, la accesibilidad visual y la autorización del propietario. El borrador no reemplaza la evidencia de implementación requerida del catálogo con este diagnóstico ficticio o con la redacción de éxito de instrucción del proveedor.