Seleccione el producto de correo Combell antes de seleccionar un registro
Combell no es una configuración de autenticación única. Es SPF Las instrucciones distinguen correo electrónico básico, correo electrónico Exchange y Microsoft 365 . esta separado DMARC artículo establece que DKIM no está disponible en buzones de correo estándar y describe una alternativa instalada con soporte en Combell Mailserver. Esas diferencias determinan lo que puede prometer un plan de configuración responsable. Esta guía cubre las opciones de productos documentadas y la preparación DNS , no una implementación de inquilino verificada ni una receta DKIM universal. El artículo SPF se actualizó el 1 de abril de 2025; el artículo DMARC se actualizó el 2 de septiembre de 2026. Confirme su aplicabilidad a la suscripción real antes de realizar cambios. Guía de Combell SPF Guía Combell DMARC
Comience con un inventario que nombre el producto en lugar de simplemente el proveedor en una factura. Registre qué sistema envía correspondencia al personal, cuál envía notificaciones al sitio web, cuál envía campañas y cuál recibe respuestas. Un sitio web alojado en Combell no establece que todos los mensajes utilicen su infraestructura de correo electrónico básica. Asimismo, una suscripción a Exchange y una ruta Microsoft 365 no deberían recibir una autorización de correo electrónico Básica simplemente porque sus DNS se administran a través del mismo portal. Este inventario es un trabajo propuesto: ninguna cuenta, dominio o mensaje ha sido inspeccionado para este manuscrito.
Conciliar SPF con la ruta de envío real
El proveedor publica ejemplos SPF separados para sus tres productos nombrados. Trátelos como instrucciones específicas del producto que requieren una verificación de aplicabilidad, no como adiciones intercambiables. Obtenga la información de la ruta aprobada actual, recupere la política SPF completa existente a través de un proceso autorizado e identifique a otros remitentes legítimos antes de proponer el registro resultante. No reemplace una política de múltiples remitentes con un ejemplo breve ni publique una segunda política SPF junto con ella. Guía de Combell SPF
SPF se evalúa para SMTP CORREO DE identidad, o la identidad HELO en los casos pertinentes; no autentica directamente la dirección visible del autor. Por lo tanto, una política que autoriza un servicio saliente puede ser correcta mientras el mensaje aún carezca DMARC alineación. Mantenga el dominio del sobre, el dominio De origen visible y la ruta de salida observada como campos separados. Evite describir una correcta Registro SPF como prueba de que todo el correo que lleva el nombre para mostrar de la organización es genuino. RFC 7208 , secciones 2.3–2.4
Revise la ruta de dependencia ampliada SPF , incluidos los servicios ya presentes. Los límites del protocolo evaluaron los términos de consulta de DNS; Esto no es simplemente un recuento de entradas textuales, paquetes o respuestas almacenadas en caché. La autorización adicional debe permanecer dentro de las reglas de evaluación sin eliminar silenciosamente a un remitente legítimo. El mecanismo final de todos expresa un resultado de política, mientras que el manejo del receptor sigue siendo una decisión separada. Ni una falla total ni la redacción orientada a la entrega de un proveedor garantizan una bandeja de entrada particular o un resultado de rechazo. RFC 7208 , secciones 4.6.4 y 8
Publicar en el contexto DNS autorizado
Para los dominios administrados en su interfaz DNS documentada, Combell dirige al operador a través de Mis productos, administración DNS y reenvío, administración al lado del dominio y Registros TXT. Sus instrucciones SPF utilizan un nombre de host en blanco para el propio dominio. Aplique ese comportamiento solo al editor documentado y a la zona deseada. Una zona DNS administrada en otro lugar requiere la propia semántica de entrada de nombres de ese proveedor; Las instrucciones de Combell no prueban que otro editor maneje nombres o sufijos en blanco de manera idéntica. Guía de Combell SPF
Antes de la publicación, registre el nombre del propietario completo previsto, el tipo de registro, el contenido completo, el TTL y el valor de reversión. Compare ese propietario previsto con la vista previa del editor. Después de un cambio autorizado, distinga la vista almacenada del panel de control de las respuestas autorizadas y las observaciones del solucionador. La presentación TXT puede incluir comillas o múltiples cadenas de caracteres; esos detalles mostrados no deben confundirse con varias políticas SPF independientes. El operador debe preservar el valor lógico previsto y los límites de registro. RFC 1035 , secciones 3.3.14 y 5.1 RFC 7208 , secciones 3.1–3.3
El intervalo de una a cuatro horas declarado por Combell es una guía operativa, no una prueba de que cada caché se haya actualizado en un momento particular. Una hoja de trabajo debe conservar los tiempos de observación y distinguir las respuestas anteriores almacenadas en caché del estado autorizado actual. No reescriba repetidamente un registro correcto simplemente porque un solucionador todavía devuelve una respuesta anterior. Por el contrario, el tiempo transcurrido no puede reparar un nombre de propietario incorrecto o una póliza duplicada accidentalmente.
Respetar la limitación DKIM del buzón estándar
La página Combell DMARC dice explícitamente que DKIM no está disponible en buzones de correo estándar. Identifica a Combell Mailserver como una opción diferente en la que el soporte puede instalar DKIM y a Flexmail como un producto de marketing independiente. Estas alternativas no establecen que los buzones estándar hayan adquirido un switch DKIM , ni tampoco suministran un universal selector o clave pública. Un proyecto que requiera DKIM alineado debe considerar esto como una decisión de ajuste del producto, sin resolver la aplicabilidad de la cuenta corriente. Guía Combell DMARC
No publique un registro DKIM inventado para que una lista de verificación parezca completa. La publicación DNS por sí sola no puede hacer que una ruta sin firmar firme mensajes. El firmante debe poseer la clave privada correspondiente y aplicar una firma adecuada, mientras que el receptor obtiene el material público de verificación a través del selector de firma y dominio de firma. Una instalación asistida por soporte necesita su propio alcance aprobado, instrucciones actuales y evidencia de mensajes posteriores. No se ha realizado ningún contacto de soporte ni instalación aquí. RFC 6376 , secciones 3.5 y 3.6.2.2
Decidir la política DMARC por separado de la muestra
Combell describe cómo agregar DMARC como un registro TXT en _dmarc y brinda un ejemplo de política de monitoreo para usuarios que no desean una política de cumplimiento específica. Ese ejemplo no es un permiso para reemplazar una política de cuarentena o rechazo existente. Revise el inventario completo de remitentes de la organización y los acuerdos de presentación de informes aprobados antes de cambiar la política. Un generador puede formatear una decisión; no puede decidir la tolerancia de la organización hacia el correo no autenticado. Guía Combell DMARC
DMARC puede pasar a través de un resultado SPF alineado calificado o un resultado DKIM alineado calificado. Por lo tanto, las limitaciones DKIM del buzón estándar no prueban por sí solas que todos los mensajes fallan DMARC , pero tampoco una política SPF publicada establece que la identidad real del sobre se alinee. Registre los resultados del receptor para la ruta aprobada cuando haya evidencia disponible. La autenticación sigue siendo distinta de la reputación, la evaluación del contenido, la preferencia del destinatario y la entrega final. RFC 9989 , secciones 2.4 y 4.4
Diagnóstico ficticio: la suposición errónea del producto
Considere una organización ficticia, Cedar Workshop, cuyo administrador ve a Combell en la factura DNS y selecciona un ejemplo de correo electrónico básico. Su correspondencia financiera en realidad utiliza un producto de correo suscrito diferente, mientras que el sitio web utiliza otro servicio de envío. Luego, un colega propone un selector DKIM adivinado para cumplir con una lista de verificación interna. Nada en este escenario es un incidente medido o una prueba ejecutada.
El diagnóstico propuesto comienza con la corrección del inventario de productos. El equipo concilia cada remitente legítimo con la política SPF existente y registra qué rutas pueden proporcionar identidades alineadas. Deja DKIM sin resolver para buzones estándar en lugar de inventar un récord. Si la empresa requiere DKIM para esa ruta, el propietario evalúa la alternativa del producto admitido y obtiene las instrucciones aplicables. El resultado exitoso es una decisión clara y un plan de evidencia, no una afirmación de que los cambios DNS ya han solucionado la entrega.
Hoja de trabajo de aceptación en blanco
- Suscripción y producto: ____; titular responsable de la cuenta: ____.
- Solicitud de envío, dominio sobre y visible Desde dominio: ____.
- Operador DNS autorizado y nombre completo del propietario previsto: ____.
- Política SPF existente y remitentes legítimos retenidos: ____.
- Autorización específica del producto confirmada en la fecha: ____.
- Revisión de la evaluación SPF ampliada y dependencias no resueltas: ____.
- Disponibilidad DKIM para este producto exacto y responsabilidad de instalación: ____.
- Política DMARC actual, destino de informes aprobado y justificación del cambio: ____.
- Observaciones DNS autorizadas y evidencia real de mensajes recibidos: ____.
- Decisiones restantes sobre el ajuste del producto, propietario de la reversión y aprobador de la versión: ____.
Todos los campos están intencionalmente en blanco. Los requisitos de implementación del catálogo, la revisión humana, la aplicabilidad de las fuentes actuales, las rutas de producción, la revisión visual/accesibilidad y la autorización del propietario permanecen abiertos. Este borrador no constituye aceptación operativa y no ofrece garantía de entrega.