Identifique primero Netcore CE o Netcore Email API
Una etiqueta de cuenta Netcore no es suficiente para elegir una receta DNS . Netcore publica instrucciones de configuración de dominio separadas para su plataforma Customer Engagement (CE) y su API de correo electrónico. La página de inicio de sesión del producto identifica Email API como anteriormente Pepipost. Registre qué producto, inquilino o subcuenta envía el mensaje y si la aplicación utiliza SMTP , una integración API o una campaña CE. No aplique un artículo antiguo de Pepipost a una pantalla CE simplemente porque ambas llevan el nombre Netcore. Inicio de sesión del producto Netcore, Configuración del dominio CE, Verificación de API de correo electrónico.
Haga un inventario de los flujos reales de cara al cliente antes de agregar un dominio de envío. Un recibo, un enlace de inicio de sesión y una campaña de marketing pueden tener diferentes propietarios de aplicaciones y dominios De. Para cada uno, conserve un mensaje de referencia o un error de envío, el remitente configurado, el estado actual del dominio y quién controla DNS autorizado. Los pasos siguientes describen sucursales documentadas; Los nombres de host y los valores generados por la cuenta tienen prioridad sobre los ejemplos.
API de correo electrónico: separe la verificación DNS de la aprobación
La guía de configuración de la API de correo electrónico conservada describe la publicación del panel proporcionado SPF TXT y único DKIM registro TXT, luego usando Verificar registros DNS . Si ya existe una política en el propietario SPF , combine la autorización requerida en esa política en lugar de agregar otro candidato. Registro SPF. No pegue una política de muestra completa sobre los permisos de otros remitentes legítimos. Después de la verificación DNS , el dominio ingresa a un proceso de aprobación que puede incluir comprobaciones automáticas y revisiones manuales. Un registro DNS verificado no establece por sí solo que el dominio esté aprobado para enviar. Verificación y aprobación del dominio de API de correo electrónico.
Mantenga los dos resultados en campos separados de la hoja de trabajo. Si DNS es correcto pero la aprobación sigue pendiente, investigue el estado de revisión de la cuenta y la información comercial solicitada. Las ediciones repetidas DNS pueden oscurecer una configuración funcional sin abordar la aprobación. Por el contrario, una cuenta activa no prueba que el dominio o subcuenta del remitente específico esté listo.
La guía explicativa de Netcore también describe un valor SPF revisado que el operador debe publicar cuando se detecta una política existente. Compare ese valor propuesto con el registro autorizado actual: otro equipo podría haber cambiado DNS desde que el panel lo leyó por primera vez. Conserve los permisos intencionales y evalúe la ruta de búsqueda completa. Para DKIM , utilice el nombre de host y el valor asociados con el dominio seleccionado. Los selectores separados pueden servir diferentes servicios, pero valores conflictivos en uno selector no se resuelven apilando claves arbitrarias. Explicación de API de correo electrónico SPF y DKIM, Reglas de procesamiento SPF.
CE: verificar cada fila DNS generada
La documentación CE especifica Configuración → Dominio de correo electrónico → Agregar dominio. Después de ingresar el dominio, la pantalla de Configuración DNS proporciona el propósito, tipo, nombre de host, valor y estado de cada registro. Los tipos de registros pueden incluir TXT , CNAME y MX ; copie las filas realmente proporcionadas para el inquilino en lugar de imponer el modelo de dos TXT de la API de correo electrónico. La guía dice que todos los registros generados deben configurarse y verificarse. Utilice Verificar y luego complete el flujo cuando tenga éxito. CE Agregar dominio de correo electrónico.
La misma guía CE distingue Éxito, Pendiente, Error y Migrado. Pendiente y Error no permiten el envío. También advierte que editar un nombre de host después de la verificación hace que el dominio esté inactivo y requiere una nueva verificación de todos los registros. Trate las ediciones de nombres de host como un cambio controlado con riesgo de interrupción. La disponibilidad de Descargar configuración DNS es útil para la transferencia de pruebas; no es prueba de que los registros fueron publicados o de que un receptor haya autenticado un mensaje.
No redireccionar el ingreso ordinario de la organización. Registros MX simplemente porque una fila generada usa MX . Primero identifique el propietario exacto y el propósito mostrado por el inquilino. Un subdominio de envío o rebote puede tener su propia configuración DNS . El texto público revisado no justifica un nombre de host CE universal, un destino MX o un selector DKIM .
Sobre personalizado: publicación y activación son pasos diferentes
Netcore Email API documenta por separado una costumbre Return-Path proceso. Describe la elección de un subdominio, la publicación de la asignación CNAME proporcionada y la solicitud al equipo de entrega que habilite el sobre personalizado/ Return-Path y DKIM para la cuenta. Ese proceso documentado significa que un CNAME publicado por sí solo no es evidencia de que los mensajes hayan cambiado de identidad. Confirme las instrucciones actuales del inquilino y el estado de activación antes de confiar en esta opción. El artículo conserva el nombre de la era Pepipost, por lo que no generaliza su objetivo o proceso de soporte a CE. Return-Path personalizada de API de correo electrónico.
Decida por qué se necesita el sobre personalizado. Puede proporcionar una ruta SPF alineada solo si el dominio del sobre real cumple con el dominio De alineación Requisito y pases SPF . Un subdominio relacionado puede cumplir con una alineación relajada, mientras que una alineación estricta requiere una igualdad de dominio exacta. Un verificado, alineado firma DKIM puede que ya suministre el DMARC camino. No elimine los registros DNS requeridos por el proveedor simplemente porque DMARC solo necesita un mecanismo de paso alineado. Reglas de alineación DMARC.
Complete la hoja de trabajo de Netcore específica del producto
Utilice una copia por inquilino/subcuenta y dominio de envío. Copie cada fila DNS generada en una entrada numerada separada en lugar de agrupar varios propósitos en uno.
- Producto: CE / API de correo electrónico. Inquilino/subcuenta: ______. Solicitud o campaña: ______.
- Destino del dominio: ______. Remitente configurado actualmente: ______. Autoridad y operador DNS : ______.
- Número de fila generado: ______. Objetivo: ______. Dueño: ______. Tipo: ______. Evidencia del valor exacto: ______. Resultado autorizado y hora UTC: ______.
- Permisos SPF existentes retenidos: ______. Evaluación completa de búsqueda de DNS: ______.
- Estado DNS del dominio: ______. Estado de aprobación de API, si corresponde: ______. Fecha de prueba: ______.
- ¿Se planea cambiar el nombre de host CE? ______. Titular de reverificación e interrupción: ______.
- ¿Se solicita un sobre personalizado? ______. Propietario publicado: ______. Confirmación de activación del proveedor: ______. Identidad del sobre recibido: ______.
- Flujo de trabajo de prueba e ID de mensaje: ______. Del dominio: ______. Dominio/resultado SPF : ______. Cada DKIM
d=/s=/ resultado: ______. - Resultado DMARC del receptor: ______. Modo de alineación y trayectoria de paso: ______.
- Verificación de manejo de rebotes: ______. Ruta de reversión: ______. Aprobador de la versión: ______.
Regla de diagnóstico: la falta de datos autorizados es un problema de publicación; una aprobación de API pendiente es un problema de aprobación de servicio; un sobre diferente después de la publicación es un problema de activación o enrutamiento. Asigne la falla al propietario correcto antes de realizar otro cambio.
Diagnóstico trabajado ficticio: DNS verificado, sobre antiguo
Ejemplo de entrenamiento ficticio, no el resultado de una prueba Netcore. Una aplicación envía recibos de receipts.example. Su propietario ha publicado el registro DKIM de la cuenta y ha solicitado un sobre personalizado en bounce.receipts.example. El mensaje recibido todavía utiliza un sobre de servicio no relacionado, pero DKIM pasa con d=receipts.example. El receptor confiable informa que DMARC pasó.
La hoja de trabajo explica ambos hallazgos: DKIM proporciona la ruta de adelantamiento alineada; la transición de sobres personalizados aún no se ha demostrado. El administrador comprueba si se produjo la activación del proveedor y si la aplicación utiliza el inquilino previsto. Agregar más permisos SPF a receipts.example no cambiaría el sobre de propiedad del servicio en ese mensaje. Una vez confirmada la activación, un recibo nuevo debe mostrar el sobre esperado y el manejo exitoso del rebote.
En un segundo caso ficticio de CE, se edita un nombre de host verificado durante el lanzamiento de una campaña y el dominio queda inactivo. La respuesta correcta es completar la reverificación requerida y mantener el envío pausado hasta que CE lo permita. Un ticket de aprobación de Email API abordaría el flujo de trabajo del producto incorrecto.
Aceptación y recuperación
Consulte a los propietarios de registros exactos en DNS autorizado y luego compare los resultados recursivos con marcas de tiempo. Inspeccione las firmas recibidas y el tablero. Una clave DKIM publicada demuestra la disponibilidad, no que la aplicación haya utilizado esa clave; un envío exitoso de API demuestra la aceptación por parte de un servicio, no la ubicación en la bandeja de entrada. Utilice una transacción y un destinatario controlados, sin tokens de reinicio reales ni datos de clientes en el paquete de revisión. Verificación DKIM.
Guarde DNS previo al cambio y la configuración de la aplicación. Si la nueva ruta falla, pausa el remitente afectado, restaura solo la configuración modificada y prueba un mensaje nuevo. Verifique los envíos en cola antes de cambiar de transporte para evitar duplicados. Mantenga los dominios y campañas no relacionados fuera del cambio.
No se probó ningún inquilino de Netcore en vivo, cambio DNS o mensaje recibido para este manuscrito. Las hojas de trabajo y los ejemplos son material de preparación. La aplicabilidad actual del producto/inquilino, la evidencia de activación y aprobación, DNS autorizado, las pruebas de mensajes en vivo, la revisión visual y la aprobación humana de las PYME siguen siendo necesarias antes del lanzamiento.