Aliases de e-mail do domínio: 5 problemas para diagnosticar

Você configurou um alias de e-mail de domínio - sales@yourcompany.com para sua caixa de entrada, support@ para o suporte. Tudo parecia certo no painel administrativo. Depois as consultas pararam, um cliente disse que a mensagem voltou e você descobriu que estava respondendo pelo endereço pessoal havia três semanas.

Quando um alias de domínio falha, confira os erros de digitação e a interação entre o roteamento e a autenticação moderna - SPF, DKIM, DMARC -. Uma regra antiga pode entrar em conflito com as verificações do destinatário.

Se você vê 550 5.7.520, 554 5.4.14 ou mensagens que somem apesar do simpático 250 OK do servidor, pare de adivinhar. Este guia apresenta cinco erros comuns de configuração, seus códigos e as correções que vale investigar.

Se precisa entender primeiro a arquitetura - a diferença entre alias e caixa postal -, leia alias de e-mail de domínio versus caixa postal antes de continuar.

Seu alias de e-mail de domínio está mesmo com problema? Comece aqui

Estes cinco padrões são pontos de partida para o diagnóstico. Cada um tem um sintoma e um código úteis. Encontre a linha mais próxima antes de alterar DNS, rotas ou políticas administrativas: o código orienta a investigação, mas não comprova sozinho a causa.

Por que aliases falham: o problema dos dois remetentes

Um e-mail pode ter dois endereços de remetente com funções diferentes; a diferença entre eles não significa, por si só, uma falha. O remetente do envelope (RFC 5321 MAIL FROM) direciona notificações de falha de entrega e é a identidade verificada pelo SPF. O remetente do cabeçalho (RFC 5322 From:) aparece para o destinatário no Gmail ou Outlook e fornece o domínio com o qual o DMARC exige alinhamento.

O roteamento interno - de sales@ para bob@ no mesmo servidor - não necessariamente acrescenta um salto SMTP externo, mas também não garante autenticação. No encaminhamento externo, o receptor vê o IP do servidor que encaminha e pode verificar SPF para o domínio original. Se esse IP não estiver autorizado, SPF falha. Com p=reject, uma falha de DMARC pode causar rejeição ou outro tratamento conforme o receptor; uma assinatura DKIM válida, alinhada e preservada ainda pode fazer o DMARC passar. Rejeição, quarentena e notificações de falha dependem das políticas e da etapa SMTP.

Erro de configuração 1: encaminhamento externo sem SRS

Encaminhar um alias para Gmail, Yahoo ou um endereço pessoal do Outlook.com pode fazer o SPF falhar; o resultado do DMARC também depende do DKIM e de seu alinhamento. É um problema relevante no período 2025-2026, especialmente quando remetentes publicam p=reject, não uma garantia de que todo encaminhamento falhe.

Exemplo: a cliente alice@bank.com escreve para contact@yourdomain.com. Seu servidor encaminha para you@gmail.com. O Gmail consulta SPF para bank.com. O IP do servidor de encaminhamento não consta no registro e SPF falha. O banco publica p=reject. Se nenhuma assinatura DKIM alinhada passar, o receptor pode rejeitar a mensagem. Seu servidor talvez já tenha respondido 250 OK ao salto anterior, mas isso não confirma a entrega final nem impede necessariamente uma notificação de falha posterior.

A correção para o envelope: Sender Rewriting Scheme (SRS). O SRS reescreve o remetente do envelope usando seu domínio antes do encaminhamento:

Envelope original: alice@bank.com
Após a reescrita SRS: SRS0=hash=TT=bank.com=alice@yourdomain.com

Agora o Gmail verifica SPF para yourdomain.com. Se seu servidor estiver autorizado, SPF pode passar para esse envelope reescrito. O SRS é habilitado no servidor pelo provedor ou administrador. Postfix e Exim têm módulos SRS disponíveis; confira a configuração.

Ressalva importante: o SRS pode resolver a autorização SPF do envelope encaminhado, mas não restaura o alinhamento DMARC com o domínio From original. Uma assinatura DKIM original, válida, alinhada e preservada pode bastar para o alinhamento DMARC. ARC (Authenticated Received Chain) fornece informações que o receptor pode avaliar depois de validar a cadeia e confiar no serviço que a sela; não cria alinhamento nem garante entrega. Assinar com outro domínio também não corrige o alinhamento com o remetente original.

Uma alternativa mais simples: evitar o encaminhamento para provedores externos. Use uma caixa IMAP real no seu domínio e acesse pelo celular. O encaminhamento externo, já comum em 2012, hoje exige cuidado com a autenticação, embora continue viável para alguns usos.

Erro de configuração 2: Microsoft 365 bloqueando encaminhamento externo

Se o alias encaminha para fora e o remetente recebe 550 5.7.520 Access denied, verifique as políticas da Microsoft. A opção padrão "Automatic - System-controlled" do filtro de spam de saída do Exchange Online corresponde ao bloqueio do encaminhamento externo automático. A medida busca limitar a extração de dados; confira a política efetiva da organização.

Correção no portal administrativo: habilite o encaminhamento somente com autorização da organização. Os passos abaixo alteram a política padrão e podem afetar todas as contas às quais ela se aplica.

1. Abra o portal Microsoft 365 Defender
2. Acesse: Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. Edite Anti-spam outbound policy (Default)
4. Defina "Automatic forwarding rules" como On - Forwarding is enabled

Para habilitar o encaminhamento apenas para usuários específicos - uma abordagem mais delimitada -, crie uma política de saída direcionada a essas contas em vez de alterar o padrão da organização inteira.

Alternativa com PowerShell:

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

Erro de configuração 3: o loop de roteamento

Um loop pode gerar 554 5.4.14 Hop Count Exceeded. A mensagem circula entre dois endereços até atingir o limite do servidor - por exemplo, 15-20 saltos se essa for a configuração -, e o processamento para. O remetente pode receber uma notificação de falha; o destinatário pretendido pode não receber nada. O limite depende do sistema.

Confira se uma regra esquecida na caixa de destino está causando o loop:

Alias do servidor: info@ → admin@
Regra da caixa admin@: encaminhar tudo para info@ para arquivamento
Resultado: loop até exceder o limite de saltos

Investigue também o que costuma ficar esquecido: uma resposta de férias de dois anos atrás ou uma regra "arquivar tudo em info@". Revise aliases do servidor e regras dos clientes. No Exchange, confira as regras de transporte no centro administrativo. No Google Workspace, verifique "Filtros e endereços bloqueados" em cada conta afetada.

Correção estrutural: confira quando os aliases são expandidos e quando as regras das caixas são aplicadas. Dependendo do servidor, um redirecionamento que preserve o destinatário original pode acionar o alias novamente. Defina rotas de entrega sem ciclos e teste o comportamento; os nomes "redirect" e "deliver to" não garantem sozinhos o resultado.

Erro de configuração 4: exposição de identidade ao enviar pelo alias

Um alias que só recebe pode não atender à sua necessidade de identidade. Se você responde a uma mensagem enviada para sales@yourcompany.com e o destinatário vê bob.smith@yourcompany.com no campo From, a resposta não usa o endereço esperado. Essa exposição pode passar despercebida para você.

Verificação no Google Workspace:

1. Abra as configurações do usuário → Contas → "Enviar e-mail como"
2. Adicione o endereço do alias
3. Avalie "Tratar como um alias" conforme o uso da identidade. Desmarcar pode servir para uma identidade independente, mas não garante privacidade. Confira From, Reply-To e os cabeçalhos de uma mensagem de teste.

Verificação no Microsoft 365:

No M365, "Bob em nome de Sales" pode indicar permissão para enviar em nome de outra pessoa. Enviar por alias é uma função diferente das permissões "Send As" e de envio em nome de terceiros. Para habilitar a função de alias na organização:

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

Essa opção é do Exchange Online, não do Exchange local. Não é uma solução universal para a indicação "em nome de": verifique permissões, tipo de endereço e suporte do cliente.

Erro de configuração 5: conflito com catch-all

Um catch-all (*@domain.com) recebe mensagens para endereços sem correspondência específica. Se o sistema prioriza uma correspondência genérica antes de um alias explícito, pode enviar mensagens à caixa errada sem um erro evidente.

Nos mapas indexados do Postfix, virtual_alias_maps busca o endereço exato antes do catch-all do domínio; não depende simplesmente da ordem das linhas. Este exemplo coloca aliases explícitos primeiro para facilitar a leitura:

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

A última posição do catch-all é ilustrativa, não uma regra universal de avaliação; em mapas PCRE, a ordem dos padrões pode importar. Antes de aplicar o exemplo, faça backup da configuração e dos mapas existentes, teste as correspondências de destinatários e valide a configuração e as rotas com autorização administrativa antes de recarregar. Em mapas com MySQL, confira as consultas e a precedência da busca por endereço específico sobre a busca por domínio; a ordem das linhas não garante essa prioridade.

Diagnóstico avançado: leia os cabeçalhos completos

Quando uma mensagem parece sumir sem notificação de falha, os cabeçalhos de uma que chegou ao spam podem ajudar. Authentication-Results informa as verificações feitas por aquele receptor. Compare com logs e rastreamento de entrega; o cabeçalho não explica necessariamente todos os saltos.

No Gmail: abra a mensagem → menu de três pontos → "Mostrar original". Procure o bloco de autenticação:

Exemplo com falha - SRS ausente:

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

smtp.mailfrom continua como alice@bank.com. Se o IP for do servidor de encaminhamento, o exemplo indica que o envelope não foi reescrito com SRS.

Exemplo que passa - SRS ativo e autenticação alinhada preservada:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

O envelope foi reescrito e SPF passa para yourdomain.com. Esse SPF não está alinhado ao From original. Para explicar o resultado DMARC pelo DKIM, deve haver uma assinatura válida e alinhada, não mostrada neste trecho; o SRS sozinho não explica o resultado.

Para testar a resposta do servidor a um endereço de alias, use swaks somente com autorização em servidores e domínios sob seu controle. Substitua os valores de exemplo por endereços de teste próprios, não de terceiros: esse comando pode enviar uma mensagem de teste.

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK confirma aceitação naquela etapa SMTP, não a existência de uma caixa nem a entrega final; catch-all ou validação adiada também podem aceitar o endereço. 550 User Unknown indica que o servidor rejeitou o endereço como desconhecido naquele teste. Revise mapas, políticas e logs.

Prevenção: simplifique o roteamento e reduza os saltos

Para reduzir erros, elimine quando possível os padrões que os favorecem. Estas duas orientações cobrem boa parte dos casos anteriores.

Regra 1: evitar encaminhamento externo desnecessário. Mantenha o e-mail corporativo no domínio da empresa e consulte a caixa com um cliente IMAP no celular. O encaminhamento pode complicar SPF e DMARC, levar dados por infraestrutura de terceiros e exigir outra identidade de envio. Se ele for necessário, avalie essas implicações e configure a autenticação.

Regra 2: reduzir cadeias de alias a um salto.

Cada salto acrescenta uma oportunidade de loop, alteração de cabeçalho ou falha de autenticação. Um único salto é uma meta útil de arquitetura, não uma exigência universal.

Para endereços temporários ou de campanha, considere o endereçamento com sinal de mais - bob+newsletter@domain.com - em vez de criar um alias sempre. Confira o suporte e as opções atuais de TrekMail, Gmail e Exchange; eles dependem do provedor e da configuração. Alguns formulários rejeitam o caractere +, por isso ele também não funciona em todos os sites.

Para comparar alias e encaminhamento em detalhes, leia encaminhamento por alias de e-mail.

Quando o problema é o modelo de preços

Parte dessa complexidade aparece quando preços por usuário tornam caixas independentes caras. Você cria aliases para evitar outra licença e acaba gastando horas com cabeçalhos SRS e políticas de encaminhamento no PowerShell.

A comparação histórica do TrekMail apresentada aqui contrapõe uma mensalidade do serviço à cobrança por cada caixa. O plano Starter ($3.50/mês) serve como exemplo de uma oferta anterior com sales@, support@ e billing@ como caixas IMAP independentes, com acessos e identidades próprios. Confira a tarifa vigente, os limites de domínios e caixas e as cotas compartilhadas da conta. Para responder com cada identidade, verifique as permissões e a configuração do cliente SMTP; caixas independentes não garantem que nenhum cabeçalho revele outra identidade. No modelo Nano com SMTP próprio, ele é necessário para todas as mensagens de saída, inclusive respostas; planos pagos podem oferecer SMTP gerenciado conforme seus recursos.

Para agências, o plano Pro ($10/mês) para 100 domínios também é uma referência à oferta anterior. Verifique as condições atuais antes de cadastrar clientes. A ferramenta de migração IMAP descrita pode copiar mensagens do Gmail ou cPanel com acesso autorizado e compatibilidade verificada. Confira pastas e contagens, coordene a mudança DNS e uma cópia final das mensagens novas; IMAP não substitui um backup nem migra sozinho contatos e calendários.

Se está configurando e-mail em um domínio pela primeira vez, como criar e-mail com seu domínio explica o processo. Consulte os preços do TrekMail para confirmar a tarifa da conta, os limites e as condições do período de teste. A oferta anterior previa um teste de plano pago de 14 dias com cartão obrigatório; confira as condições vigentes antes de se cadastrar.

Conclusão

Aliases podem falhar por problemas de SPF no encaminhamento sem SRS, bloqueios do Microsoft 365, loops de regras esquecidas, identidades de envio mal configuradas e conflitos com catch-all. Os códigos ajudam na investigação, mas a correção exige verificar a rota real, as políticas e a autenticação alinhada.

Se esses problemas se repetem, talvez não seja só a configuração: você pode estar criando alternativas para um modelo de preços por usuário. Nesse caso, vale revisar também a arquitetura e o plano.

Para ampliar o contexto de arquitetura e diagnóstico, comece por configuração e correções de encaminhamento de e-mail.