Mi correo recibe mensajes, pero no puede enviarlos: qué revisar
Compara webmail y cliente, identifica el servidor de salida y conserva el error exacto. Recibir por IMAP no demuestra que la conexión SMTP esté funcionando.
Recibir mensajes no demuestra que el sistema de salida funcione. La lectura y el envío pueden utilizar servidores, autenticación y conexiones diferentes. Antes de cambiar contraseñas o registros MX, comprueba si falla la conexión al servidor de salida, la autorización para enviar o la entrega al destinatario.
Esta guía se centra en una cuenta de correo y su cliente. Si solo falla una notificación de tu web, consulta el formulario WordPress que muestra enviado sin entregar el correo.
1. Anotar dónde termina el intento de envío
Distingue si el mensaje permanece en la bandeja de salida, aparece un error inmediato o llega un rebote después. Conserva hora y texto del error, ocultando datos privados si lo compartes. La carpeta de enviados por sí sola no acredita que el destinatario lo recibiera.
Una respuesta de autenticación y un rechazo de un receptor necesitan investigaciones distintas. Evita resumir ambos como «el correo no funciona», porque esa descripción puede llevar a cambiar una parte que sigue operando correctamente.
2. Comparar webmail y programa de correo
Haz una prueba desde el webmail oficial del proveedor con una cuenta que controles. Si funciona allí, pero no desde el ordenador, compara configuración y conectividad del cliente. Si tampoco funciona desde webmail, revisa el estado y las restricciones de la cuenta con el proveedor.
Esta comparación acota el problema, pero no lo resuelve por sí misma: ambos recorridos pueden utilizar políticas o infraestructura distintas. Conserva los dos resultados y utiliza mensajes ficticios, sin adjuntos sensibles.
3. Comprobar el servidor SMTP asociado a esa cuenta
La guía de Thunderbird recomienda contrastar la configuración de salida con la documentación del proveedor y comprobar qué servidor SMTP utiliza cada cuenta. Una configuración guardada puede corresponder a otro buzón o a un servicio anterior.
Verifica servidor, puerto, cifrado, método de autenticación y usuario según tu producto contratado. No copies una combinación genérica por utilizar la misma aplicación de correo que otra persona. Si hubo cambio de contraseña o del método de acceso, confirma qué credencial admite el cliente sin desactivar protecciones de la cuenta.
No borres la cuenta como primer intento de reparación. Antes de cualquier cambio que afecte al perfil, comprueba si hay mensajes o carpetas conservados únicamente en ese dispositivo.
4. Separar conexión y autenticación
Si no se establece la conexión, revisa resolución del nombre y acceso al servicio con el administrador. Una comparación controlada desde otro dispositivo o red autorizada puede ayudar a localizar la capa afectada.
La documentación de Mozilla contempla interferencias de red o software de seguridad. No conviertas esa hipótesis en permiso para desactivar permanentemente firewall, antivirus, VPN o validación de certificados. Registra el resultado y pide una corrección específica si se confirma una incompatibilidad.
Si el servidor responde, pero no acepta la identidad o el remitente, comprueba los permisos de la cuenta. Recibir correo para una dirección o alias no significa automáticamente que puedas enviar utilizando esa dirección.
5. Investigar cuándo el mensaje sale, pero se rechaza después
Si el proveedor acepta el envío y aparece un rebote, conserva el diagnóstico completo para soporte. Comprueba si ocurre con todos los destinatarios, uno concreto o únicamente determinados mensajes. Esa diferencia permite preparar una prueba representativa sin reenviar repetidamente el mismo contenido.
Revisa autenticación y alineación cuando el rechazo lo señale. Las directrices de Gmail contemplan requisitos para remitentes, pero su cumplimiento no garantiza entrega universal. Nuestra guía de SPF, DKIM y DMARC explica qué datos reunir sin reducir políticas a ciegas.
6. No cambiar la recepción para corregir la salida
Si el fallo apareció tras una migración, confirma si el cliente sigue conectado al proveedor anterior y qué servicio debe enviar ahora. No alteres MX para intentar arreglar una contraseña o conexión SMTP incorrecta.
Si cambiaste la zona y también falla la recepción, sigue el diagnóstico de correo después de cambiar DNS. Si solo se trasladó la web, revisa cómo mantener el correo en el proveedor actual antes de cancelar servicios.
Qué preparar para pedir ayuda
Reúne proveedor y producto, aplicación y dispositivo, momento del fallo, resultado en webmail y mensaje de error. Comparte la configuración sin contraseñas, tokens ni contenido de conversaciones. Indica si hay direcciones alternativas o cambios recientes.
Podemos revisar DNS y dominios, coordinar una migración de correo empresarial o comprobar el servicio de salida si administras tu propio servidor Linux. La intervención debe dirigirse a la capa que falla, no trasladar todo el correo por defecto.