Dia 19: Postfix e Dovecot — Mail Server com SMTP e IMAP

Montar um servidor de email próprio continua a ser uma das competências mais exigentes para qualquer administrador Linux. O Postfix trata do envio e receção via SMTP; o Dovecot faz a entrega aos utilizadores finais via IMAP e POP3. Mas um mail server moderno sem SPF, DKIM e DMARC tem as mensagens rejeitadas pelo Gmail, Outlook e praticamente todos os grandes provedores. Este guia cobre a instalação completa, a integração entre Postfix e Dovecot via SASL, e a configuração dos três registos DNS que autenticam o domínio — com comandos testados em Ubuntu 24.04 e Rocky Linux 9.

Atenção: Configurar um mail server num domínio que já envia email através de outro serviço (Microsoft 365, Google Workspace) pode causar perda de mensagens. Antes de avançar, confirmar que o registo MX do domínio aponta para o servidor correto e que não há conflito com fornecedores existentes.
Nota: Este artigo assume um VPS ou servidor dedicado com IP público, domínio registado e acesso root. Portas 25, 465, 587, 143 e 993 têm de estar abertas no firewall do datacenter — muitos fornecedores (Hetzner, DigitalOcean) bloqueiam a porta 25 por defeito.

Entender o Fluxo de Email: MTA, MDA e MUA

O envio de email envolve três papéis distintos. O MTA (Mail Transfer Agent) é o Postfix: recebe mensagens de outros servidores via SMTP e encaminha-as para o destino. O MDA (Mail Delivery Agent) é o Dovecot: entrega as mensagens na caixa de correio do utilizador e oferece acesso via IMAP ou POP3. O MUA (Mail User Agent) é o cliente final — Outlook, Thunderbird, Apple Mail — que liga ao Dovecot para ler e ao Postfix para enviar.

O fluxo completo: o MUA envia a mensagem ao Postfix na porta 587 (submission). O Postfix consulta o registo MX do domínio de destino e estabelece ligação SMTP na porta 25 do servidor remoto. O servidor remoto entrega ao seu próprio MDA, que coloca a mensagem na caixa do utilizador. O destinatário lê via IMAP na porta 993. Cada salto pode ser autenticado: SPF valida o remetente no DNS, DKIM assina a mensagem com uma chave privada, e DMARC diz ao destinatário o que fazer se ambas as verificações falharem (RFC 5321, RFC 5322).

O Postfix foi criado por Wietse Venema em 1998 como alternativa segura ao Sendmail. É o MTA predefinido em Ubuntu, Debian e muitas distribuições. O Dovecot surgiu em 2002 e é o IMAP server mais usado em Linux, com foco em segurança e performance (Postfix documentation, Dovecot documentation).

Pré-requisitos e Instalação

Antes de instalar, confirmar três coisas: (1) o servidor tem um registo A no DNS (ex: mail.exemplo.pt → 203.0.113.10), (2) o registo MX aponta para esse hostname, e (3) o rDNS (reverse DNS) do IP resolve para o mesmo hostname. Sem rDNS correto, a maioria dos servidores rejeita o email.

O rDNS é configurado no painel do fornecedor do VPS (Hetzner, OVH, DigitalOcean), não no DNS do domínio. O nome no rDNS tem de corresponder exactamente ao parâmetro myhostname do Postfix.

Instalar os pacotes necessários. No Ubuntu/Debian:

apt update
apt install postfix dovecot-core dovecot-imapd dovecot-pop3d opendkim opendkim-tools

No Rocky/Alma/RHEL (o postfix já vem instalado por defeito em muitos casos):

dnf install postfix dovecot opendkim opendkim-tools

Durante a instalação no Debian/Ubuntu, o instalador pergunta o tipo de configuração. Escolher “Internet Site” e inserir o nome de domínio (ex: exemplo.pt). No Rocky/RHEL não há este assistente — toda a configuração é manual no ficheiro /etc/postfix/main.cf.

Configurar o Postfix (SMTP)

O ficheiro principal do Postfix é /etc/postfix/main.cf. O Postfix usa uma sintaxe própria de pares chave=valor. As variáveis são expandidas no momento do carregamento — não há aspas, e os valores são separados por vírgulas ou espaços. A documentação oficial está em Postfix Basic Configuration.

Configuração base do main.cf:

# Identidade do servidor
myhostname = mail.exemplo.pt
mydomain = exemplo.pt
myorigin = $mydomain

# Domínios dos quais este servidor recebe email
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

# Interfaces de rede (todas)
inet_interfaces = all
inet_protocols = ipv4

# Formato da caixa de correio (Maildir)
home_mailbox = Maildir/

# Redes autorizadas a enviar através deste servidor
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

# Tamanho máximo da mensagem (50 MB)
message_size_limit = 52428800

# Limites de caixa
mailbox_size_limit = 0

O parâmetro home_mailbox = Maildir/ define o formato Maildir — cada mensagem é um ficheiro individual, mais robusto que o formato mbox tradicional. O Dovecot tem de usar o mesmo formato. O mynetworks lista as redes autorizadas a relay sem autenticação — incluir apenas localhost.

Ativar a porta de submission (587) para os clientes enviarem email autenticado. Editar /etc/postfix/master.cf e descomentar a secção submission:

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

A porta 587 exige TLS (smtpd_tls_security_level=encrypt) e só aceita clientes autenticados via SASL (permit_sasl_authenticated). Isto separa o tráfego de clientes (porta 587, autenticado) do tráfego entre servidores (porta 25, sem autenticação). Ver Postfix SASL README.

Adicionar configuração TLS ao main.cf (usando certificados Let’s Encrypt se disponíveis, ou certificados auto-assinados para teste):

# TLS - servidor
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.exemplo.pt/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.exemplo.pt/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes

# TLS - cliente (envio)
smtp_tls_security_level = may
smtp_tls_loglevel = 1

# SASL via Dovecot
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous

O parâmetro smtpd_sasl_path = private/auth aponta para um socket Unix que o Dovecot cria dentro do chroot do Postfix em /var/spool/postfix/private/auth. Esta é a ponte entre os dois serviços. Ver Postfix TLS README e Dovecot + Postfix howto.

Configurar o Dovecot (IMAP)

O Dovecot lê a configuração de vários ficheiros em /etc/dovecot/. No Debian/Ubuntu, o ficheiro principal é dovecot.conf que inclui conf.d/*.conf. No Rocky/RHEL, toda a configuração está em /etc/dovecot/dovecot.conf. A documentação completa está em Dovecot Configuration Manual.

Definir os protocolos e o formato da caixa. Editar /etc/dovecot/dovecot.conf (ou conf.d/10-mail.conf no Debian):

# Protocolos ativos
protocols = imap lmtp

# Formato Maildir (igual ao Postfix)
mail_location = maildir:~/Maildir

# Utilizador do processo do Dovecot
mail_uid = vmail
mail_gid = vmail
first_valid_uid = 5000
last_valid_uid = 5000

O mail_location tem de corresponder ao home_mailbox do Postfix. Se o Postfix entrega em ~/Maildir/ e o Dovecot lê de ~/Maildir/, as mensagens aparecem correctamente no cliente IMAP.

Configurar a autenticação SASL para o Postfix. Editar conf.d/10-master.conf (Debian) ou a secção service auth no dovecot.conf (Rocky):

service auth {
  # Socket Unix para o Postfix
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

service imap-login {
  inet_listener imap {
    port = 143
  }
  inet_listener imaps {
    port = 993
    ssl = yes
  }
}

O unix_listener cria o socket que o Postfix usa para validar credenciais. O caminho /var/spool/postfix/private/auth corresponde ao smtpd_sasl_path = private/auth do Postfix — o Postfix resolve este caminho relativo ao seu chroot.

Configurar TLS no Dovecot. Editar conf.d/10-ssl.conf (Debian) ou a secção SSL no dovecot.conf (Rocky):

ssl = required
ssl_cert = </etc/letsencrypt/live/mail.exemplo.pt/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.exemplo.pt/privkey.pem
ssl_min_protocol = TLSv1.2

O símbolo < antes do caminho diz ao Dovecot para ler o ficheiro de certificado diretamente, em vez de interpretar o caminho como uma string. É uma sintaxe específica do Dovecot. O ssl_min_protocol = TLSv1.2 recusa ligações com TLS 1.0/1.1, que são inseguras.

Integrar Postfix e Dovecot via SASL

A integração entre Postfix e Dovecot acontece num único socket Unix. O Postfix pede ao Dovecot “este utilizador existe e a password está correta?” e o Dovecot responde sim ou não. Isto evita manter duas bases de dados de utilizadores separadas. O Postfix nunca acede diretamente às passwords — delega sempre no Dovecot.

Para usar utilizadores do sistema (Linux), o Dovecot precisa de ler /etc/shadow. Adicionar o utilizador dovecot ao grupo shadow:

usermod -aG shadow dovecot

Reiniciar ambos os serviços e ativar no arranque:

systemctl restart postfix dovecot
systemctl enable postfix dovecot

Verificar que ambos estão ativos e sem erros:

systemctl status postfix dovecot --no-pager

Testar a ligação IMAP com openssl s_client na porta 993 (IMAPS):

openssl s_client -connect mail.exemplo.pt:993 -quiet

Se a ligação estabelecer e mostrar * OK [CAPABILITY ...] Dovecot ready., o Dovecot está a responder com TLS. Ver Arch Wiki: Dovecot e Arch Wiki: Postfix.

SPF — Sender Policy Framework

O SPF é um registo DNS TXT que lista os servidores autorizados a enviar email em nome do domínio. Quando o Gmail recebe uma mensagem de [email protected], consulta o registo SPF de exemplo.pt e verifica se o IP do servidor remetente está na lista. Se não estiver, a mensagem é marcada como spam ou rejeitada. A especificação está em RFC 7208.

Registo SPF para um servidor único:

exemplo.pt.    IN    TXT    "v=spf1 mx a -all"

Decomposição do registo:

  • v=spf1 — versão do SPF (sempre spf1)
  • mx — autoriza o IP do registo MX do domínio
  • a — autoriza o IP do registo A do domínio
  • -all — rejeita tudo o resto (fail hard). ~all é soft fail (marca como spam mas não rejeita)

Para incluir um servidor adicional (ex: o IP de alojamento do site (usado no formulário de contacto), que é o cenário mais habitual para PME):

exemplo.pt.    IN    TXT    "v=spf1 mx a ip4:203.0.113.20 include:mailgun.org -all"

O -all (hard fail) é recomendado para domínios que enviam email apenas dos servidores listados. O ~all (soft fail) é útil durante a fase de testes — o destinatário marca como spam mas não rejeita, permitindo identificar problemas sem perder mensagens.

Verificar o registo SPF com dig:

dig TXT exemplo.pt +short

DKIM — DomainKeys Identified Mail

O DKIM assina cada mensagem com uma chave privada e publica a chave correspondente no DNS. O servidor de destino verifica a assinatura usando a chave pública do DNS. Se a assinatura for válida, prova que a mensagem não foi alterada em trânsito e que veio do domínio correto. A especificação está em RFC 6376.

Gerar o par de chaves com o OpenDKIM. Primeiro, criar o diretório e gerar a chave:

mkdir -p /etc/opendkim/keys/exemplo.pt
cd /etc/opendkim/keys/exemplo.pt
opendkim-genkey -s mail -d exemplo.pt -b 2048
chown -R opendkim:opendkim /etc/opendkim/keys/exemplo.pt

O comando gera dois ficheiros: mail.private (chave privada, fica no servidor) e mail.txt (registo DNS para publicar). O -s mail é o seletor — o nome que identifica esta chave no DNS. O -b 2048 define o tamanho da chave RSA em bits.

O conteúdo de mail.txt é o registo DNS a publicar:

mail._domainkey.exemplo.pt.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

Configurar o OpenDKIM em /etc/opendkim.conf:

# Configuracao OpenDKIM
PidFile /run/opendkim/opendkim.pid
Mode sv
Domain exemplo.pt
Selector mail
KeyFile /etc/opendkim/keys/exemplo.pt/mail.private
Socket local:/run/opendkim/opendkim.sock
LogWhy yes
Syslog yes
SyslogSuccess yes
Canonicalization relaxed/relaxed

O Mode sv significa que o OpenDKIM assina (s) e verifica (v). O Canonicalization relaxed/relaxed tolera pequenas alterações nos cabeçalhos e corpo feitas por relés intermédios — é a configuração recomendada. Ver OpenDKIM no GitHub e Arch Wiki: OpenDKIM.

Ligar o OpenDKIM ao Postfix. No Ubuntu/Debian, o socket do OpenDKIM fica em /run/opendkim/opendkim.sock. No Rocky/RHEL, usar inet:127.0.0.1:12301 (socket TCP). Adicionar ao main.cf:

# Milter (OpenDKIM)
smtpd_milters = unix:/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/run/opendkim/opendkim.sock
milter_default_action = accept

No Rocky/RHEL, a linha é smtpd_milters = inet:127.0.0.1:12301. Reiniciar os serviços:

systemctl restart opendkim postfix

Verificar o registo DKIM no DNS:

dig TXT mail._domainkey.exemplo.pt +short

DMARC — Domain-based Message Authentication

O DMARC é a política que diz ao destinatário o que fazer quando SPF e/ou DKIM falham. Sem DMARC, o destinatário decide sozinho — alguns aceitam, outros marcam como spam. Com DMARC, o remetente define a política e recebe relatórios de falhas por email. A especificação está em RFC 7489.

Registo DMARC para começar em modo de monitorização (recomendado nos primeiros 7-14 dias):

_dmarc.exemplo.pt.    IN    TXT    "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s"

Decomposição do registo:

  • p=none — política de monitorização (não rejeita nem marca como spam). Avançar para p=quarantine (marca como spam) e depois p=reject (rejeita)
  • rua — endereço para relatórios agregados (XML diário com estatísticas)
  • ruf — endereço para relatórios forenses (mensagem individual em caso de falha)
  • pct=100 — percentagem de mensagens sujeitas à política (100% = todas)
  • adkim=s — alinhamento estrito (o domínio do cabeçalho From tem de corresponder ao domínio da assinatura DKIM)
  • aspf=s — alinhamento estrito para SPF

A progressão recomendada é: p=none durante 1-2 semanas para receber relatórios e identificar fontes legítimas que não passam a verificação. Depois p=quarantine com pct=25 (25% das mensagens) e aumentar gradualmente. Finalmente p=reject com pct=100. Ver DMARC FAQ e DMARC Analyzer.

Verificar o registo DMARC:

dig TXT _dmarc.exemplo.pt +short

Erros Comuns

Problema Causa Solução
Email vai para spam no Gmail SPF, DKIM ou DMARC em falta ou mal configurados Verificar os três registos DNS com dig. Enviar email para mail-tester.com para diagnóstico
Connection refused na porta 25 Fornecedor do VPS bloqueia porta 25 ou Postfix não está a correr Confirmar com o fornecedor que a porta 25 está desbloqueada. Verificar systemctl status postfix
SASL authentication failed Socket Dovecot-Postfix desalinhado ou Dovecot sem acesso ao shadow Confirmar smtpd_sasl_path = caminho do socket. Verificar usermod -aG shadow dovecot
Mensagens não chegam à caixa IMAP Formato Maildir diferente entre Postfix e Dovecot Confirmar home_mailbox = Maildir/ no Postfix e mail_location = maildir:~/Maildir no Dovecot
rDNS não corresponde ao hostname Fornecedor do VPS não configurou o reverse DNS Configurar rDNS no painel do fornecedor. O nome tem de ser igual a myhostname do Postfix
TLS handshake falha Certificado expirado ou caminho errado Verificar openssl x509 -in fullchain.pem -noout -dates. Renovar com certbot se expirado
Open relay (servidor envia email de qualquer origem) mynetworks demasiado permissivo (ex: 0.0.0.0/0) Restringir mynetworks a 127.0.0.0/8 apenas. Usar SASL para clientes remotos

Checklist de Verificação

Antes de declarar o mail server pronto para produção, confirmar cada ponto:

  1. Registo A de mail.exemplo.pt aponta para o IP do servidor
  2. Registo MX aponta para mail.exemplo.pt
  3. rDNS do IP resolve para mail.exemplo.pt
  4. Postfix ativo: systemctl status postfix
  5. Dovecot ativo: systemctl status dovecot
  6. OpenDKIM ativo: systemctl status opendkim
  7. SPF publicado e validado com dig TXT exemplo.pt
  8. DKIM publicado e validado com dig TXT mail._domainkey.exemplo.pt
  9. DMARC publicado em modo p=none para monitorização inicial
  10. Teste de envio para mail-tester.com com score 9/10 ou superior
  11. Portas 25, 465, 587, 143 e 993 abertas no firewall
  12. Certificado TLS válido (Let’s Encrypt ou equivalente)
Atenção: Um open relay permite que qualquer pessoa use o servidor para enviar spam, o que resulta em blacklistagem do IP em listas como Spamhaus e Barracuda. Remover o IP de uma blacklist pode demorar dias ou semanas. Confirmar que mynetworks está restrito a localhost antes de abrir o servidor para tráfego externo.

Artigos Relacionados