Passo a passo: Relay access denied no Postfix, como corrigir

Relay access denied no Postfix ocorre quando o servidor recusa encaminhar uma mensagem para um domínio externo porque o cliente, a rede ou o remetente não foi autorizado. A correção normalmente envolve confirmar o erro nos logs, habilitar autenticação SMTP e revisar as restrições de relay sem transformar o servidor em open relay.

1. Localize a rejeição nos logs do Postfix.
2. Confira os domínios locais e as redes autorizadas.
3. Verifique se a autenticação SMTP está habilitada.
4. Ajuste as restrições de relay na ordem correta.
5. Recarregue o Postfix e teste um destinatário externo.

Pré-requisitos

O diagnóstico de envio SMTP exige acesso administrativo ao servidor e conhecimento do domínio realmente hospedado. Os procedimentos são adequados a instalações atuais do Postfix em Debian 13+, Rocky Linux 10+ ou AlmaLinux 10+, embora o caminho do log e o backend de autenticação possam variar.

• Acesso root ou usuário com permissão para executar sudo.
• Postfix instalado, ativo e responsável pelo recebimento SMTP.
• Um domínio configurado, como seudominio.com.br.
• Acesso ao arquivo /etc/postfix/main.cf e, se necessário, ao /etc/postfix/master.cf.
• Credenciais SMTP válidas para testar o envio autenticado.
• Porta de submissão SMTP liberada conforme a política de rede do servidor.

Se o servidor de e-mail ainda não estiver estruturado, consulte o Passo a passo para configurar servidor de e-mail no VPS Linux antes de alterar as regras de relay.

Diagnosticar Relay access denied no Postfix pelos logs

A rejeição de relay deve ser investigada na tentativa exata de envio. O log informa o IP do cliente, o remetente, o destinatário e, dependendo da configuração, se houve autenticação. Isso evita liberar redes ou domínios por tentativa e erro.

Relay access denied no Postfix: localizar a tentativa rejeitada

1. Reproduza o erro enviando uma mensagem para um domínio externo.
2. Consulte as entradas recentes do serviço.
3. Procure por Relay access denied, NOQUEUE ou reject.

sudo journalctl -u postfix --since "15 minutes ago" --no-pager | grep -iE "relay access denied|reject|NOQUEUE"

Ao rodar este comando, você verá uma linha semelhante a esta:

postfix/smtpd: NOQUEUE: reject: RCPT from unknown[198.51.100.25]: 454 4.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]>

Em sistemas que gravam arquivos tradicionais, identifique primeiro o arquivo disponível e filtre a mesma mensagem. Não presuma um caminho único, pois ele depende do serviço de logs da distribuição.

sudo grep -i "Relay access denied" /var/log/mail.log /var/log/maillog 2>/dev/null | tail -n 20

O resultado esperado contém o endereço IP do cliente e o destinatário recusado:

connect from unknown[198.51.100.25]
NOQUEUE: reject: RCPT from unknown[198.51.100.25]: Relay access denied

Se o IP for externo e não houver indicação de autenticação, a causa mais provável é um cliente tentando enviar sem SMTP AUTH. Se o destinatário deveria ser local, investigue também se o domínio foi declarado corretamente como domínio local ou virtual.

Verificar domínios, redes e restrições de relay

As permissões de encaminhamento SMTP são controladas principalmente por domínios aceitos, redes confiáveis, autenticação e restrições aplicadas durante o comando RCPT. Antes de editar arquivos, consulte a configuração efetiva, incluindo valores definidos por padrão pelo Postfix.

sudo postconf myhostname mydomain mydestination mynetworks smtpd_relay_restrictions smtpd_recipient_restrictions smtpd_sasl_auth_enable

Uma configuração restritiva pode apresentar uma saída semelhante:

myhostname = mail.seudominio.com.br
mydomain = seudominio.com.br
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 127.0.0.0/8 [::1]/128
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
smtpd_sasl_auth_enable = yes

As três causas mais frequentes são: cliente externo sem autenticação; rede legítima ausente de mynetworks; ou domínio local configurado no mapa errado. Um domínio de caixa postal virtual não deve ser adicionado automaticamente a mydestination, pois os mecanismos de entrega local e virtual possuem finalidades diferentes.

Atenção: faça uma cópia da configuração antes de modificá-la. Uma regra permissiva ou uma rede pública ampla em mynetworks pode criar um open relay.

sudo cp /etc/postfix/main.cf /etc/postfix/main.cf.backup-relay
sudo postconf -n

O primeiro comando não produz saída quando concluído; o segundo lista apenas os parâmetros explicitamente configurados:

myhostname = mail.seudominio.com.br
mynetworks = 127.0.0.0/8 [::1]/128
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Não coloque o IP dinâmico de cada usuário em mynetworks. Essa diretiva deve conter somente interfaces locais e redes privadas realmente controladas. Para notebooks, celulares e aplicações externas, prefira autenticação SMTP.

Corrigir a autenticação SMTP e as regras de relay

O SMTP AUTH permite que um usuário legítimo envie mensagens externas sem depender do endereço IP de origem. O Postfix precisa ter um backend SASL funcional e reconhecer clientes autenticados antes de rejeitar destinos não autorizados.

1. Confirme que o backend de autenticação configurado está ativo.
2. Habilite SASL no serviço SMTP ou no serviço de submissão.
3. Autorize clientes autenticados em smtpd_relay_restrictions.
4. Mantenha a rejeição de destinos não autorizados ao final da regra.

sudo postconf -e "smtpd_sasl_auth_enable = yes"
sudo postconf -e "smtpd_sasl_security_options = noanonymous"
sudo postconf -e "smtpd_tls_auth_only = yes"
sudo postconf -e "smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination"

Esses comandos não exibem saída em caso de sucesso. Confirme os valores gravados:

sudo postconf smtpd_sasl_auth_enable smtpd_sasl_security_options smtpd_tls_auth_only smtpd_relay_restrictions

O output esperado é:

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_tls_auth_only = yes
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

permit_sasl_authenticated autoriza o relay depois da autenticação. defer_unauth_destination impede que clientes não autorizados encaminhem mensagens para domínios externos. A existência dessas diretivas não corrige credenciais inválidas nem substitui a configuração do backend SASL.

Para clientes externos, use preferencialmente o serviço de submissão com TLS e autenticação obrigatória. No master.cf, confirme que a entrada de submissão está habilitada e que suas opções não anulam a política desejada.

sudo postconf -Mf submission/inet
sudo postconf -P "submission/inet/syslog_name"
sudo postconf -P "submission/inet/smtpd_tls_security_level"
sudo postconf -P "submission/inet/smtpd_sasl_auth_enable"

Quando o serviço já está configurado, a saída deve indicar a entrada submission e os parâmetros aplicados. Parâmetros inexistentes podem não produzir o resultado abaixo e precisarão ser definidos conforme o backend SASL instalado:

submission inet n - y - - smtpd
postfix/submission
encrypt
yes

Validar a configuração e testar o envio externo

O teste de relay precisa comprovar duas situações: um usuário autenticado consegue enviar e um cliente anônimo não consegue usar o servidor para destinos externos. Validar apenas o envio bem-sucedido pode ocultar uma configuração perigosa.

sudo postfix check
sudo systemctl reload postfix
sudo systemctl is-active postfix

postfix check e o reload normalmente não mostram saída quando não há erro. O último comando deve retornar:

active

Com uma ferramenta de teste SMTP disponível, envie uma mensagem autenticada pela porta de submissão. Substitua a senha de exemplo por uma credencial temporária ou informe-a de forma segura, evitando registrá-la no histórico do shell.

swaks --server mail.seudominio.com.br --port 587 --tls \
--auth LOGIN --auth-user [email protected] \
--from [email protected] --to [email protected]

Após fornecer a credencial, uma sessão autorizada deve avançar além do comando RCPT e terminar com respostas semelhantes:

< 235 2.7.0 Authentication successful
< 250 2.1.5 Ok
< 250 2.0.0 Ok: queued

Em seguida, repita sem autenticação. O comportamento seguro é recusar o destinatário externo:

swaks --server mail.seudominio.com.br --port 25 \
--from [email protected] --to [email protected]

O output esperado para um cliente anônimo não autorizado é uma rejeição de relay:

< 454 4.7.1 <[email protected]>: Relay access denied

Essa segunda rejeição é correta e demonstra que o servidor não está aberto. Depois que o envio funcionar, valide também a identidade do domínio com o Checklist: como testar se o DKIM e SPF estão configurados.

Problemas comuns e como resolver

Falhas de envio externo podem permanecer mesmo após ajustar as restrições, especialmente quando o cliente usa a porta errada, o backend SASL não responde ou o domínio foi classificado incorretamente.

Sintoma: o cliente envia sem pedir usuário e senha

Causa: o aplicativo está usando SMTP sem autenticação ou conectando à porta destinada ao tráfego entre servidores.

Solução: configure o cliente para usar a porta de submissão, TLS e autenticação com o endereço de e-mail completo. Confirme nos logs se a sessão aparece como autenticada antes do comando RCPT.

Sintoma: a senha está correta, mas o relay continua negado

Causa: o backend SASL pode não estar acessível ao processo do Postfix, ou a regra efetiva não contém permit_sasl_authenticated.

Solução: consulte postconf, verifique o serviço de autenticação e acompanhe o log durante uma nova tentativa. Não compense uma falha de SASL adicionando o IP público do usuário a uma rede ampla.

Sintoma: mensagens locais funcionam e destinatários externos falham

Causa: o domínio local é aceito sem relay, enquanto destinos externos exigem uma rede confiável ou uma sessão autenticada.

Solução: habilite SMTP AUTH no cliente e confirme a ordem de smtpd_relay_restrictions. Preserve a rejeição de destinos não autorizados ao final da política.

Sintoma: o domínio próprio também recebe Relay access denied

Causa: o Postfix pode não reconhecer o domínio como local ou virtual, ou o mapa de destinatários não está carregado.

Solução: revise mydestination e os mapas de domínios virtuais conforme o modelo de entrega adotado. Não adicione o domínio aleatoriamente a várias diretivas, pois isso pode causar loops ou entrega no destino errado.

Perguntas frequentes sobre Relay access denied no Postfix

O que significa Relay access denied no Postfix?

A mensagem indica que o Postfix recusou encaminhar o e-mail para um domínio externo porque o cliente ou remetente não estava autorizado a usar o servidor como relay. A correção depende de identificar se faltou autenticação SMTP, autorização da rede ou configuração adequada do domínio.

Como identificar a causa do Relay access denied no Postfix?

Consulte os logs do Postfix e localize a tentativa rejeitada, observando remetente, destinatário, endereço IP e estado da autenticação. Depois, confira as permissões de relay, os domínios aceitos e a configuração usada pelo cliente de e-mail.

A autenticação SMTP corrige o erro Relay access denied?

A autenticação SMTP pode corrigir o erro quando o usuário legítimo tenta enviar para um domínio externo sem se autenticar. Também é necessário confirmar se o Postfix reconhece clientes autenticados como autorizados nas restrições de relay.

Posso liberar qualquer endereço IP para fazer relay no Postfix?

Não é seguro autorizar endereços indiscriminadamente, pois isso pode transformar o servidor em open relay e permitir envios não autorizados. Libere apenas redes controladas ou, preferencialmente, exija autenticação SMTP para clientes externos.

Por que o Postfix envia e-mail local, mas rejeita destinatários externos?

A entrega local pode funcionar porque o domínio do destinatário é reconhecido pelo próprio servidor, enquanto a entrega externa exige permissão de relay. Verifique a autenticação SMTP, as redes autorizadas e a ordem das restrições aplicadas pelo Postfix.

Conclusão

A correção segura preserva a separação entre entrega local, relay autenticado e tentativas anônimas. O objetivo não é remover toda rejeição, mas autorizar somente usuários e redes legítimos.

• Use os logs para confirmar IP, destinatário e estado da autenticação.
• Autorize clientes externos por SMTP AUTH, evitando redes públicas em mynetworks.
• Teste o envio autenticado e confirme que o relay anônimo continua bloqueado.

Leia também

• Guia: Postfix como relay SMTP com SASL e TLS no Fedora 42
• Solucionar falhas do Postfix não enviando emails no Debian 12
• Como mover Postfix para novo servidor sem perder configurações

Precisa de ajuda com Relay access denied no Postfix?

A equipe da AviraHost pode ajudar a revisar logs, autenticação SMTP e restrições de relay, reduzindo o risco de uma liberação excessiva no servidor.

Solicitar análise da configuração do Postfix