Source: https://once-email.com/es/blog/corecomponent

Entrega y autenticación  · 22 may 2025Actualizado 23 ago 2026

# Postfix vs Dovecot: funciones distintas en un servidor de correo entrante

Ubica Postfix, Dovecot, LMTP, la cola e IMAP en la ruta de entrada y decide con evidencias dónde falla una entrega.

[Ingeniería de Once Email, Once Email author Ingeniería de Once Email](<https://once-email.com/es/about>)

Revisado por Revisión técnica de Once Email

Qué te ayuda a hacer esta guía

Determinar si un fallo de correo entrante pertenece a SMTP, cola, almacenamiento del buzón o acceso IMAP.

Guía del artículo

Por qué vale la pena leer este artículo

**Análisis original**

La guía sigue un mensaje por aceptación SMTP, cola, entrega LMTP, almacenamiento y acceso IMAP, y asigna cada señal de fallo al componente que realmente puede producirla.

**Contexto de tendencias**

Postfix y Dovecot siguen desplegándose juntos, pero paneles e imágenes de contenedor ocultan la separación entre transferencia, entrega final y acceso al buzón, favoreciendo diagnósticos equivocados.

**Valor práctico**

El operador obtiene una tabla de decisión y un orden de comprobación que distingue rechazo SMTP, aplazamiento en cola, error de escritura y fallo de acceso sin registrar contenido sensible.

Postfix y Dovecot suelen instalarse juntos, pero no desempeñan la misma función. En un sistema receptor habitual, **Postfix acepta SMTP y administra la cola**, mientras **Dovecot realiza la entrega final o expone el buzón mediante LMTP e IMAP**. Que un servicio esté activo no demuestra que el recorrido completo funcione.

Esta página es un mapa de diagnóstico, no una receta de producción. Un despliegue real exige DNS, TLS, validación de destinatarios, control de abuso, permisos, copias, monitorización y restricciones de relay. Once Email solo recibe correo; no proporciona envío SMTP, respuesta, reenvío ni correo masivo.

## [Comparación rápida](<https://once-email.com/es/blog/corecomponent#comparaci%C3%B3n-r%C3%A1pida>)

| Pregunta | Postfix | Dovecot |
| --- | --- | --- |
| Papel de red principal | Recibe o envía SMTP | Ofrece IMAP/POP3 y puede recibir entrega LMTP |
| Posee la cola | Sí | No |
| Acepta el destinatario durante SMTP | Normalmente Postfix y sus mapas o políticas | Puede aportar datos de usuarios según el diseño |
| Deposita el mensaje en el buzón | Puede usar entrega local/virtual o delegar | LMTP de Dovecot puede efectuar la entrega final |
| Permite listar y leer al cliente | No | Sí, normalmente mediante IMAP |

No suele ser una elección «Postfix o Dovecot». En un buzón alojado, la pregunta útil es dónde termina una responsabilidad y comienza la siguiente.

## [Seguir un mensaje entrante](<https://once-email.com/es/blog/corecomponent#seguir-un-mensaje-entrante>)

La [arquitectura oficial de Postfix](<https://www.postfix.org/OVERVIEW.html>)  muestra el correo de red entrando por ` smtpd `, pasando por cleanup y llegando a una cola. Después el gestor escoge un agente de entrega. De ahí salen cuatro puntos de control:

1. **Conexión SMTP:** el servidor remoto alcanza Postfix y negocia la transacción.
2. **Aceptación:** Postfix acepta o rechaza el destinatario de sobre según mapas y reglas.
3. **Cola y transferencia:** el mensaje aceptado pasa a local, virtual, pipe o LMTP.
4. **Acceso:** tras la entrega, Dovecot deja que un cliente autorizado liste y lea por IMAP.

Un ` 250 ` SMTP no equivale a visibilidad en el buzón. Postfix puede aceptar primero y aplazar después por un error LMTP, cuota o almacenamiento. A la inversa, el mensaje puede estar guardado y seguir invisible por autenticación IMAP, índices, espacios de nombres o permisos.

## [LMTP une las dos responsabilidades](<https://once-email.com/es/blog/corecomponent#lmtp-une-las-dos-responsabilidades>)

Una frontera común es LMTP. Postfix mantiene SMTP y la cola, y conecta con Dovecot para la entrega final. La [guía LMTP de Dovecot](<https://doc.dovecot.org/2.4.2/howto/lmtp/postfix>)  ilustra un socket Unix protegido dentro del spool de Postfix.

El socket no es solo una ruta copiada de un tutorial. Propietario, grupo, modo, ubicación chroot y estado del servicio forman un contrato. Si Postfix no puede alcanzarlo, el resultado correcto suele ser un elemento aplazado, no un buzón presentado como vacío. Tras aceptar LMTP, pesan más las evidencias de cuota y almacenamiento.

No hagas el socket escribible por todos para ocultar un error. Identifica la cuenta de servicio que necesita acceso y concede lo mínimo. Tampoco publiques LMTP en Internet sin una arquitectura que defina autenticación y protección del transporte.

## [Diagnosticar por evidencia](<https://once-email.com/es/blog/corecomponent#diagnosticar-por-evidencia>)

| Evidencia | Primera frontera que revisar |
| --- | --- |
| No hay conexión al puerto 25 | DNS, firewall, TLS o ` smtpd ` de Postfix |
| Rechazo del destinatario antes del cuerpo | Mapas y política de Postfix; quizá el directorio consultado |
| SMTP acepta y el mensaje queda deferred | Cola de Postfix y transporte elegido |
| Socket LMTP ausente o sin permiso | Enlace Postfix–Dovecot y permisos |
| LMTP informa cuota o escritura fallida | Entrega Dovecot y almacenamiento |
| El fichero existe pero IMAP no lo lista | Autenticación, namespace, índice y permisos de Dovecot |

Usa un marcador único y una ventana limitada. Conserva ID de cola, clase SMTP, resultado LMTP y resultado del buzón ya redactado. No envíes direcciones reales, códigos, tokens, asuntos, cuerpos, adjuntos ni URL completas a registros compartidos o analítica.

## [Cree una ficha de cuatro campos antes de cambiar la configuración](<https://once-email.com/es/blog/corecomponent#cree-una-ficha-de-cuatro-campos-antes-de-cambiar-la-configuraci%C3%B3n>)

Para un único mensaje de prueba autorizado, conserve solo cuatro hechos redactados. Juntos permiten comprobar si la aceptación, la cola, la entrega final y la visibilidad pertenecen a la misma transacción:

| Punto | Conservar | Qué demuestra |
| --- | --- | --- |
| Aceptación SMTP | Hora, clase de estado mejorada e ID de cola abreviado | Postfix aceptó la transacción; no demuestra la entrega final |
| Resultado de cola | El mismo ID abreviado, transporte y estado delivered/deferred | Postfix eligió un transporte y completó o retuvo la entrega |
| Resultado LMTP | Éxito o clase de error, sin destinatario ni contenido | Dovecot LMTP aceptó la entrega final o devolvió una causa acotada |
| Visibilidad | Conteo antes/después y resultado de lectura de la aplicación | El almacenamiento cambió y la ruta real puede o no verlo |

Empiece con inspección de solo lectura. ` postqueue -p ` enumera la cola; filtre localmente por el ID abreviado y no exporte toda la cola. ` doveadm mailbox status -u TEST_USER "messages unseen" INBOX ` consulta contadores, usando solo una identidad de prueba autorizada. Las referencias oficiales de [herramientas de cola de Postfix](<https://www.postfix.org/QSHAPE_README.html>)  y [estado de buzón de Dovecot](<https://doc.dovecot.org/2.4.2/core/man/doveadm-mailbox.1.html>)  explican estos datos. Sin coincidir también en tiempo y marcador redactado, no prueban que sea el mismo mensaje.

## [Errores de categoría y orden seguro](<https://once-email.com/es/blog/corecomponent#errores-de-categor%C3%ADa-y-orden-seguro>)

Instalar Dovecot no crea un listener SMTP; instalar Postfix no ofrece un buzón IMAP. SPF, DKIM y DMARC son otra capa: aportan autenticación y alineación, no acceso. Para eso está la [guía de resultados SPF, DKIM y DMARC](<https://once-email.com/es/blog/read-spf-dkim-dmarc-results>) .

Una cola vacía no prueba éxito: el mensaje pudo rebotar, expirar, ser descartado por una política explícita o haber salido. Un buzón vacío tampoco prueba que nada llegó: la consulta puede haber fallado, el cliente estar sin conexión o mirar otro namespace. Mantén separados «sin resultado», «fallo temporal» y «vacío confirmado».

Verifica primero el endpoint SMTP, entrega un único mensaje autorizado, registra la aceptación de Postfix, sigue cola y entrega, confirma el buzón Dovecot y léelo por el mismo IMAP usado por la aplicación. Elimina la cuenta de prueba y conserva solo evidencia redactada. Reiniciar ambos servicios antes de observar borra tiempos y colas sin explicar la causa.

## Guías relacionadas

Cómo leer cabeceras Received y seguir la ruta de entrega de un correo

Un método para reconstruir saltos, tiempos y servidores sin confundir la ruta técnica con la identidad del remitente.

[Cómo leer cabeceras Received y seguir la ruta de entrega de un correo](<https://once-email.com/es/blog/read-received-headers>)

Cómo usar una API de correo temporal sin crear pruebas inestables

Diseño de pruebas con buzones aislados, consultas limitadas, tiempos máximos, correlación segura y limpieza determinista.

[Cómo usar una API de correo temporal sin crear pruebas inestables](<https://once-email.com/es/blog/temporary-email-api-testing-guide>)

¿No llega el correo de verificación? Lista segura de diagnóstico

Un orden de comprobación para encontrar un mensaje retrasado sin solicitar códigos repetidamente ni exponer información sensible.

[¿No llega el correo de verificación? Lista segura de diagnóstico](<https://once-email.com/es/blog/anxiety>)

## Herramientas de correo centradas en la privacidad

Analizador de cabeceras de correo

Explica los saltos de entrega y resume SPF, DKIM y DMARC sin afirmar una autenticidad absoluta.

[Analizador de cabeceras de correo](<https://once-email.com/es/tools/email-header-analyzer>)

[Descargar muchos adjuntos y descomprimirlos localmente con UnpackFlow Descarga en una carpeta exclusiva, verifica cada archivo y usa list, plan, run o start para tratar archivos multipartes y anidados localmente.](<https://once-email.com/es/blog/batch-email-attachments-unpackflow>) [¿Cuánto dura un correo temporal? Planifica antes de que caduque Cómo elegir una duración suficiente, prever retrasos y evitar depender de un buzón que desaparecerá.](<https://once-email.com/es/blog/readbook>)
