Correo en Odoo: salida, entrega y respuesta

En Odoo, «enviado» no significa necesariamente «en la bandeja del cliente», y recibir una respuesta en un buzón no demuestra que haya quedado vinculada al documento correcto. El diagnóstico útil separa tres recorridos: salida desde Odoo, entrega por el servicio de correo y regreso de la respuesta al registro.

Esta guía usa la documentación de Odoo 19.0 como referencia explícita. Antes de aplicar un paso, identifica tu versión y modalidad: Odoo Online, Odoo.sh o instalación propia. Los menús, proveedores y responsabilidades pueden variar. El objetivo es reunir evidencia y hacer una prueba controlada, no cambiar DNS, credenciales o políticas de seguridad por ensayo y error.

Elige tu punto de entrada: árbol por síntoma · autenticación y alineación · prueba completa · ficha de evidencia.

1. Dibuja tu recorrido antes de tocar parámetros

Anota qué aplicación genera el mensaje, qué servidor lo envía, qué dominio aparece como remitente y por dónde vuelven respuestas y rebotes. Incluye plantillas o módulos personalizados que cambien remitentes. Identifica al responsable de Odoo, al proveedor de correo y al administrador del dominio; pueden ser tres equipos distintos.

El correo del ERP no sustituye necesariamente los buzones de las personas. Una respuesta vinculada a una cotización y un mensaje nuevo dirigido a un alias tienen finalidades distintas. La documentación de mensajes entrantes de Odoo 19 explica esas rutas, incluidos alias, catchall y rebotes. No conviertas el catchall en un buzón general para cualquier mensaje.

Para la salida, comprueba el mecanismo admitido por tu versión e integración. La documentación de correo saliente describe servidores SMTP externos y selección del remitente. Que un proveedor comercial ofrezca una API no significa que Odoo la utilice sin un módulo compatible y mantenido.

2. Árbol de diagnóstico: abre sólo la rama de tu síntoma

Las ramas son una guía de investigación, no ejecutan cambios ni envían mensajes. Guarda primero el error y la hora. Evita reenviar un lote entero mientras desconoces cuáles destinatarios ya recibieron el original.

A. Odoo no genera o no despacha el mensaje

Primera pregunta: ¿existe un mensaje asociado al documento o sólo se esperaba que una automatización lo creara?

• Si no existe, revisa con el responsable funcional la acción, plantilla, destinatario y condición que debían generarlo.
• Si existe y sigue pendiente, registra su estado y antigüedad. Solicita evidencia del procesamiento de la cola y de las tareas programadas aplicables.
• Si aparece un fallo, conserva el texto exacto y el destinatario afectado antes de reintentar.

No concluyas: «es spam» cuando todavía no hay evidencia de que el mensaje salió. Una cola detenida, un destinatario vacío y una autenticación rechazada son problemas distintos.

B. El servicio rechaza el envío o devuelve un rebote

Identifica quién emitió el error: el proveedor de salida o el servidor del destino. Guarda código, texto, fecha y referencia del mensaje. Distingue una respuesta temporal de un rechazo permanente y sigue la explicación del proveedor; no reduzcas todos los códigos a «contraseña incorrecta».

Comprueba límites contratados, remitentes permitidos y tamaño del mensaje con su codificación y adjuntos. El límite real puede no coincidir con el peso del archivo en disco. Si sólo falla un destinatario, investiga esa ruta antes de cambiar una configuración que funciona para los demás.

Escala con evidencia: un resumen del error y el identificador permiten correlacionar registros. Nunca incluyas contraseñas, tokens ni secretos en un ticket o captura.

C. El servidor aceptó el mensaje, pero no aparece en la bandeja

Verifica qué aceptación está documentada: entregar el mensaje al proveedor de salida no equivale a que el servidor receptor lo haya aceptado. Pide la trazabilidad hasta el siguiente salto conocido, sin presentar un estado intermedio como entrega final.

Con un destinatario de prueba autorizado, revisa bandeja, carpeta de no deseados y cuarentena si existe. Solicita al administrador receptor información del mensaje concreto. La autenticación puede pasar y aun así intervenir filtros, reputación o políticas del destinatario. No hay garantía universal de bandeja de entrada.

No hagas: cambiar palabras para burlar filtros, comprimir un adjunto para ocultarlo o pedir que se desactive la protección del receptor. Corrige identidad, contenido legítimo y condiciones documentadas.

D. La respuesta llega al correo, pero no al registro de Odoo

Responde al mensaje original de prueba; no empieces un correo nuevo con el mismo asunto. Comprueba el Reply-To, el recorrido entrante configurado y la asociación de referencias del mensaje. Un asunto parecido no basta para identificar el documento.

Revisa con el administrador el alias y modelo de destino, así como reenvíos o servidores entrantes que correspondan a esa instalación. Odoo documenta la vinculación de respuestas mediante referencias de mensajes. El catchall espera respuestas a mensajes previos, no es una dirección genérica para crear cualquier registro.

Cierre de la prueba: la respuesta aparece una sola vez, en el registro correcto y accesible sólo para los usuarios que deban verla. Recibirla en un buzón intermedio es un avance, no el cierre.

La guía oficial de problemas comunes de correo en Odoo ayuda a interpretar fallos, límites y evidencias para soporte. Usa las pantallas de tu versión; no ejecutes instrucciones de otra modalidad como si fueran intercambiables.

3. SPF, DKIM y DMARC: qué debe alinearse realmente

Según RFC 9989, publicado en mayo de 2026, DMARC pasa si existe SPF válido y alineado O una firma DKIM válida y alineada con el dominio del From visible. No exige que From, Return-Path y DKIM sean tres cadenas idénticas.

• SPF: para esta evaluación se considera el dominio autenticado del MAIL FROM del sobre.
• DKIM: se considera el dominio d= de una firma validada.
• Alineación estricta: exige igualdad exacta del dominio correspondiente con el del From.
• Alineación relajada: compara su dominio organizacional conforme al estándar; no basta con que dos nombres «se parezcan».

Ejemplo conceptual: DKIM puede pasar y estar alineado aunque SPF no lo esté; esa vía puede satisfacer DMARC. Si SPF y DKIM pasan pero ninguno está alineado, no basta. El resultado de DMARC tampoco certifica que un mensaje sea deseado, legítimo en todos sus contenidos o destinado a la bandeja principal.

SPF tiene además un límite específico: RFC 7208, sección 4.6.4, limita a 10 los términos que provocan consultas DNS durante la evaluación, incluidos mecanismos y modificadores como include y redirect. No son simplemente diez dominios escritos ni diez registros DNS totales. La evaluación incluye dependencias; si se excede ese límite, el resultado es permerror. Debe revisarlo el administrador, no «arreglarse» añadiendo autorizaciones indiscriminadas.

Con un SMTP externo, los valores de autenticación deben corresponder al proveedor que realmente envía. No copies los registros del servicio de Odoo como si autorizaran a cualquier tercero. Documenta las fuentes autorizadas y la política existente antes de proponer cambios; no rebajes automáticamente una política a monitoreo para hacer desaparecer un fallo.

4. Un subdominio organiza, no blinda la reputación

Separar flujos puede facilitar responsables, métricas y políticas. No demuestra aislamiento absoluto de reputación: receptores y proveedores pueden considerar distintas señales y relaciones entre dominios, infraestructura y comportamiento. Tampoco transforma un envío no solicitado en uno aceptable.

La operación debe distinguir notificaciones esperadas de campañas, controlar destinatarios y respetar los límites y requisitos aplicables. No adoptes límites de grandes emisores como si fueran los de todo negocio. Si cambia el volumen, solicita al proveedor las condiciones vigentes para tu cuenta y comprueba que el flujo legítimo pueda procesarse sin saturación.

Usa el mecanismo de autenticación admitido por la combinación concreta de proveedor y versión, incluido OAuth cuando corresponda. No existe una contraseña de aplicación universal. Un método soportado y una cuenta con alcance adecuado son más importantes que copiar parámetros de una captura ajena.

5. Prueba de aceptación: envío, adjunto, respuesta y rebote

Prepara un documento ficticio claramente marcado como prueba, sin datos fiscales, personales o comerciales reales. Si tu operación utiliza PDF y XML, incluye archivos de prueba inocuos que reproduzcan su formato y tamaño razonable. Usa buzones autorizados para la prueba, no direcciones inventadas de terceros.

1. Texto simple: envía desde el flujo funcional que necesitas, no sólo desde una pantalla de configuración. Registra documento, hora con zona y referencia del mensaje.
2. Adjuntos: repite con los archivos ficticios y verifica recepción e integridad. Compara el resultado con el mensaje sin adjuntos.
3. Identidad: revisa los encabezados en el destino autorizado, incluyendo resultados de autenticación, From y Reply-To. Conserva una copia interna depurada de información sensible.
4. Respuesta: responde al original y comprueba que aparezca en el registro correcto de Odoo, una sola vez.
5. Error controlado: coordina con el administrador un destino o mecanismo de prueba de rechazo. Verifica quién recibe el aviso y cómo se identifica el destinatario afectado. No generes rebotes hacia personas ajenas.
6. Cierre: documenta resultados, pendientes y responsables. Repite sólo los casos necesarios tras una corrección autorizada.

La prueba de conexión SMTP es un control preliminar. Odoo advierte que un resultado exitoso no asegura que el mensaje salga: pueden persistir restricciones del proveedor. La aceptación necesita el recorrido funcional completo, incluida la respuesta si tu negocio depende de ella.

6. Ficha de evidencia para soporte

Este desplegable no transmite ni almacena información. Copia la ficha a tu expediente interno y comparte con soporte sólo lo necesario por un canal autorizado.

Abre la ficha del incidente de correo

• Versión y modalidad de Odoo: ____
• Fecha, hora y zona horaria: ____
• Flujo y documento ficticio o referencia anonimizada: ____
• Síntoma: no generado / pendiente / rechazado / no visible / respuesta sin vincular: ____
• Identificador del mensaje y del proveedor, sólo para soporte autorizado: ____
• Destinatario anonimizado y dominio de destino pertinente: ____
• Código y texto del error, sin secretos: ____
• Resultado de texto simple y de adjuntos: ____
• Resultado SPF / DKIM / DMARC y dominios pertinentes depurados: ____
• Último salto confirmado y evidencia: ____
• Responsable, siguiente comprobación y resultado: ____

Oculta direcciones personales, contenido, identificadores internos y demás datos innecesarios. Los encabezados también pueden contener información privada. No publiques su versión completa en foros ni la envíes a herramientas sin autorización.

7. Qué soporte vale la pena contratar

Pide que el alcance diferencie generación en Odoo, servicio de salida, dominio y entrada. Debe quedar claro quién puede consultar registros, coordinar con el receptor, revisar una plantilla y proponer un cambio. Una promesa genérica de «correo funcionando» no define esas responsabilidades.

El servicio con experiencia puede justificar un costo mayor si evita que tu equipo invierta horas reenviando facturas o buscando respuestas perdidas. Evalúa ese valor mediante pruebas, atención y documentación, no mediante una garantía imposible de que ningún mensaje irá a spam. Cobalt Blue Web puede ser una opción a evaluar cuando necesitas acompañamiento técnico; compara el alcance escrito con el de otros proveedores y decide libremente.

Si Odoo está lento, correlaciona la antigüedad de la cola con registros y carga del sistema antes de culpar a la infraestructura. La lentitud no prueba por sí sola duplicación de mensajes. Cambiar de servidor tampoco corrige automáticamente un alias, un remitente no autorizado o una política del receptor.

8. IA para clasificar, no para reenviar a ciegas

La IA puede agrupar errores depurados, resumir una cronología o sugerir qué evidencia falta. Contrasta cada hipótesis con el código del proveedor y el registro original. No le entregues secretos, facturas reales ni encabezados completos a un servicio no autorizado.

No permitas que una clasificación dispare reenvíos masivos o cambie políticas de dominio sin revisión. El avance medible es saber qué etapa falló, qué evidencia lo demuestra y quién puede resolverla. Eso mejora la operación sin convertir un mensaje ambiguo de «enviado» en una promesa de entrega.