Porque os seus emails vão para o spam: o guia de diagnóstico completo
Por CaptainDNS
Publicado em 4 de fevereiro de 2026
Atualizado em 10 de novembro de 2026
- 5 principais causas: autenticação (SPF/DKIM/DMARC), reputação de IP/domínio, conteúdo suspeito, baixo engajamento, configuração técnica
- Verificação prioritária: teste o seu IP nas principais listas de bloqueio e audite a sua autenticação
- Desde 2024: Gmail e Yahoo exigem SPF, DKIM e DMARC para remetentes em massa
- Rejeições do Outlook.com de novembro de 2026 (AS9031519): sem DMARC aplicável, acrescentar
p=noneé a solução provisória relatada. Também são assinaladas rejeições com SPF, DKIM e DMARC em pass: se a sua autenticação já está correta, não reescreva os seus registos e siga o procedimento de comunicação da secção Outlook.com - A partir de novembro de 2026: a Spamhaus implementa progressivamente a exigência de um HELO válido e de registos PTR e A concordantes para cada IP de envio, com risco de listagem
- Limite crítico: uma taxa de reclamação superior a 0,1% aciona a classificação como spam
- Diagnóstico rápido: analise os cabeçalhos do email para identificar o problema exato
Porque os seus emails são classificados como spam
Todos os dias, mil milhões de emails são filtrados por sistemas anti-spam. Um em cada seis emails nunca chega à caixa de entrada do destinatário. Para as empresas, isso é crítico: faturas não recebidas, confirmações de pedidos perdidas, comunicações com clientes ignoradas.
A classificação como spam não é aleatória. Os fornecedores de email (Gmail, Outlook, Yahoo) usam centenas de sinais para decidir o destino de cada email. Entender esses sinais é a chave para resolver o problema: resumem-se a cinco pilares mensuráveis (autenticação, reputação, segurança de transporte, BIMI e envolvimento) que o nosso guia sobre a pontuação de entregabilidade de email decompõe um a um.
Este guia analisa as 5 principais causas da classificação como spam e oferece um plano de ação concreto para cada situação. Quer seja administrador de sistemas, responsável de marketing ou desenvolvedor, encontrará as respostas para as suas dúvidas.
Causa 1: Autenticação de email ausente ou incorreta
A autenticação de email tornou-se obrigatória em 2024. Gmail, Yahoo e Apple anunciaram que emails não autenticados seriam sistematicamente rejeitados ou classificados como spam.
Os 3 protocolos de autenticação
| Protocolo | Função | Impacto se ausente |
|---|---|---|
| SPF | Lista os servidores autorizados a enviar pelo seu domínio | Rejeição ou spam |
| DKIM | Assina criptograficamente cada email | Spam ou desconfiança |
| DMARC | Define a política em caso de falha SPF/DKIM | Sem proteção contra falsificação; rejeições do Outlook.com relatadas desde novembro de 2026 (não é a única situação assinalada) |
Verificar a sua configuração
Use uma auditoria de email de domínio para verificar instantaneamente se o seu domínio está configurado corretamente:
- Introduza o seu nome de domínio
- Consulte os resultados SPF, DKIM e DMARC
- Siga as recomendações de correção
Erros SPF comuns
| Erro | Consequência | Solução |
|---|---|---|
| Sem registo SPF | Emails classificados como spam | Criar um registo TXT com v=spf1 |
| Muitos includes (>10 lookups) | SPF inválido (PermError) | Otimizar ou usar um serviço de flattening |
| IP faltando | Falha SPF em alguns envios | Adicionar o IP ou o include do serviço |
| ~all vs -all | Política muito permissiva | Usar -all em produção |
Erros DKIM comuns
| Erro | Consequência | Solução |
|---|---|---|
| Sem assinatura | Email não autenticado | Configurar DKIM no servidor de email |
| Chave muito curta (<1024 bits) | Assinatura considerada fraca | Gerar uma chave de 2048 bits |
| Seletor incorreto | Falha na verificação | Verificar o DNS e a configuração do servidor |
| Corpo modificado | Assinatura inválida | Verificar os relays intermediários |
DMARC: a política que muda tudo
O DMARC é o maestro da autenticação. Sem ele, mesmo com SPF e DKIM válidos, os seus emails podem ser classificados como spam, ou recusados durante a transação SMTP. Uma recusa não deposita nada na pasta de lixo eletrónico: o remetente recebe um relatório de não entrega e a mensagem não é entregue. Desde o início de novembro de 2026, vários operadores relatam este tipo de recusa no Outlook.com para domínios sem registo DMARC. As comunicações de novembro abrangem também domínios cujos SPF, DKIM e DMARC são declarados corretos: a ausência de DMARC não explica todos os casos (detalhes na secção Outlook.com mais abaixo).
# Registo DMARC p=none com relatórios agregados
_dmarc.captaindns.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"
# Registo DMARC estrito (recomendado em produção)
_dmarc.captaindns.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com"
| Política | Comportamento | Recomendação |
|---|---|---|
p=none | Apenas monitorização | Fase inicial (2-4 semanas) |
p=quarantine | Emails suspeitos vão para spam | Fase intermediária |
p=reject | Emails suspeitos são rejeitados | Produção segura |
Causa 2: Reputação de IP ou domínio degradada
Mesmo com autenticação perfeita, os seus emails podem ir para o spam se sua reputação for ruim. Os fornecedores de email mantêm scores de reputação baseados no histórico de envio.
Entendendo a reputação
A reputação é composta por dois elementos:
- Reputação de IP: Score do endereço IP que envia os emails
- Reputação de domínio: Score do domínio de envio (From)
| Fator | Impacto na reputação |
|---|---|
| Taxa de reclamação de spam | Muito alto (limite: 0,1%) |
| Taxa de bounce | Alto (limite: 5%) |
| Engajamento (aberturas, cliques) | Moderado |
| Histórico do domínio | Moderado |
| Listas de bloqueio | Crítico |
Verificar se o seu IP está em lista de bloqueio
Um IP numa lista de bloqueio importante (Spamhaus, Barracuda) terá os seus emails sistematicamente rejeitados pelo Gmail, Outlook e Yahoo.
Para verificar se o seu IP está listado, teste-o nas principais DNSBL:
- Spamhaus ZEN: Usada pela maioria dos grandes fornecedores
- Barracuda BRBL: Muito comum em empresas
- SpamCop: Baseada em denúncias de utilizadores
Listas de bloqueio prioritárias
| Lista de bloqueio | Impacto | Usada por |
|---|---|---|
| Spamhaus ZEN | Crítico | Gmail, Yahoo, Outlook |
| Barracuda BRBL | Crítico | Empresas, filtros Barracuda |
| SpamCop | Alto | Vários fornecedores |
| UCEProtect | Moderado | Filtros anti-spam |
Melhorar a sua reputação
| Ação | Impacto | Prazo |
|---|---|---|
| Solicitar remoção das listas de bloqueio | Imediato | 24-72h |
| Reduzir a taxa de reclamação | Alto | 2-4 semanas |
| Retirar os hard bounces que visam o endereço (utilizador desconhecido, caixa de correio inexistente). Uma recusa que visa o domínio, o IP ou a autenticação corrige-se na origem, sem retirar o destinatário | Alto | Imediato |
| Aquecer progressivamente novos IPs | Preventivo | 4-6 semanas |
Causa 3: Conteúdo problemático
Os filtros anti-spam analisam o conteúdo de cada email. Certos elementos acionam automaticamente a classificação como spam.
Palavras e expressões a evitar
Os filtros anti-spam usam listas de palavras suspeitas. Aqui estão as categorias mais arriscadas:
| Categoria | Exemplos | Risco |
|---|---|---|
| Urgência excessiva | "URGENTE", "Aja agora", "Última chance" | Alto |
| Promessas financeiras | "Grátis", "Ganhe dinheiro", "Sem custos" | Alto |
| Pressão comercial | "Oferta limitada", "Só mais 24h", "Estoque esgotado" | Moderado |
| Expressões suspeitas | "Clique aqui", "100% garantido", "Sem compromisso" | Moderado |
Estrutura do email
| Problema | Porque é filtrado | Solução |
|---|---|---|
| Email 100% imagem | Texto oculto, técnica de spammer | Proporção 60% texto / 40% imagens |
| Links encurtados (bit.ly) | Ocultam o destino | Usar URLs completas |
| Muitos links | Comportamento típico de spam | Máximo 3-5 links por email |
| Sem versão texto | Apenas HTML = suspeito | Sempre incluir text/plain |
| Formulários integrados | Técnica de phishing | Links para o site |
Proporção HTML/texto ideal
Conteúdo recomendado:
- Texto: 60-80%
- Imagens: 20-40%
- Links: 3-5 no máximo
- Tamanho total: < 100 KB
Causa 4: Baixo engajamento dos destinatários
Os fornecedores de email medem como os destinatários interagem com os seus emails. Um baixo engajamento sinaliza conteúdo não desejado.
Sinais de engajamento negativo
| Sinal | Impacto | Limite crítico |
|---|---|---|
| Reclamações de spam | Muito alto | >0,1% aciona o spam |
| Hard bounces | Alto | >5% degrada a reputação |
| Soft bounces repetidos | Moderado | >10% em 30 dias |
| Baixa taxa de abertura | Moderado | <10% em listas ativas |
| Cancelamentos de subscrição elevados | Moderado | >1% por campanha |
O ciclo vicioso do spam
Baixo engajamento → Classificação como spam → Ainda menos engajamento → Reputação degradada
Para quebrar esse ciclo:
- Limpe as suas listas: Remova endereços inativos há mais de 6 meses
- Segmente: Envie conteúdo relevante para cada segmento
- Respeite o consentimento: Double opt-in obrigatório
- Facilite o cancelamento de subscrição: Link visível, processo em 1 clique
Boas práticas de higiene de lista
| Ação | Frequência | Impacto |
|---|---|---|
| Remover os hard bounces que visam o endereço (utilizador desconhecido, caixa de correio inexistente). Se a recusa visar o domínio, o IP ou a autenticação: corrigir a causa e reenviar, sem mexer na lista | Imediato | Crítico |
| Remover reclamações de spam | Imediato | Crítico |
| Limpar inativos (>6 meses) | Mensal | Alto |
| Reengajamento dos mornos | Trimestral | Moderado |
| Validação de emails no registo | Contínuo | Preventivo |
Causa 5: Configuração técnica deficiente
Problemas de configuração técnica podem sabotar todos os seus esforços.
Checklist de configuração do servidor
| Elemento | Verificação | Comando |
|---|---|---|
| Reverse DNS (PTR) | O IP deve resolver para um FQDN | dig -x <IP> |
| FQDN para IP | O FQDN deve resolver para o IP | dig A <fqdn> |
| HELO/EHLO | Deve resolver para o IP de envio e manter-se igual | Logs do servidor |
| Porta 25 aberta | Sem bloqueio do fornecedor | telnet mail.server.com 25 |
| TLS ativado | STARTTLS obrigatório | Teste de ligação |
Reverse DNS: porque é crítico
O reverse DNS (registo PTR) é verificado por todos os principais fornecedores. Sem PTR válido, os seus emails são imediatamente suspeitos.
# Verificar o PTR do seu IP
dig -x 192.0.2.1
# Resultado esperado
1.2.0.192.in-addr.arpa. 3600 IN PTR mail.captaindns.com.
# O FQDN deve resolver para o mesmo IP
dig A mail.captaindns.com
# Resultado: 192.0.2.1
Configuração HELO/EHLO
O servidor de email identifica-se com HELO ou EHLO. O nome anunciado deve:
- Ser um FQDN válido (não um IP, não "localhost", não um nome predefinido do fornecedor de alojamento)
- Resolver para o IP que envia o email (registo A)
- Manter-se igual de uma ligação para outra a partir desse IP
O PTR desse IP, por sua vez, aponta para um FQDN que resolve para o mesmo IP: é o FCrDNS (forward-confirmed reverse DNS).
# Ruim
EHLO localhost
EHLO [192.0.2.1]
EHLO server1
# Bom
EHLO mail.captaindns.com
Spamhaus, novembro de 2026. A partir de novembro de 2026, a Spamhaus implementa progressivamente uma exigência para cada IP de envio: um HELO válido, um reverse DNS (PTR) e um registo A concordante. Um IP que não a cumpra fica exposto a uma listagem. A Spamhaus não publica nem um dia preciso nem um calendário. Em IPv6, o endereço de envio deve pertencer a um bloco /64 ou maior, com um reverse DNS válido. Verifique desde já o PTR e o registo A de cada IP de envio com os comandos dig acima e, depois, o nome anunciado no HELO nos logs do seu servidor. Para um controlo concreto, envie uma mensagem para uma caixa de correio externa e leia o cabeçalho Received acrescentado pelo servidor de destino: o nome que se segue a from é, em geral, o que o seu servidor anuncia em HELO/EHLO. Consoante o servidor de destino, aparece em vez disso entre parênteses, após helo= ou HELO. O analisador de cabeçalhos de email apresentado mais abaixo mostra-o. Se os seus servidores de envio forem também os seus MX, o testador SMTP/MX assinala um banner cujo nome não corresponde ao do MX.
Diagnóstico por fornecedor
Cada fornecedor tem as suas especificidades. Veja como diagnosticar problemas nos principais.
Gmail
Ferramentas de diagnóstico:
- Google Postmaster Tools: reputação de domínio e IP
- Cabeçalhos Gmail: procure
X-Gm-SpameX-Gm-Phishy
Exigências Gmail 2024:
| Critério | Volume <5.000/dia | Volume >5.000/dia |
|---|---|---|
| SPF ou DKIM | Obrigatório | Obrigatório |
| DMARC | Recomendado | Obrigatório |
| Taxa de reclamação | <0,3% | <0,1% |
| TLS | Recomendado | Obrigatório |
| Cancelamento de subscrição 1-clique | - | Obrigatório |
Códigos de erro comuns:
| Código | Significado | Ação |
|---|---|---|
421 4.7.0 | Muitas ligações | Reduzir a taxa |
550 5.7.1 | Política DMARC | Corrigir SPF/DKIM |
550 5.7.26 | Falha de autenticação | Verificar SPF, DKIM |
Outlook.com e Microsoft 365: distinguir os diagnósticos
A Microsoft recebe os emails através de dois serviços distintos, que nem sempre reagem da mesma forma. O Outlook.com é o correio para particulares (endereços outlook.com, hotmail.com, live.com, msn.com). O Microsoft 365 aloja o correio empresarial, no domínio de cada cliente. O nome do servidor que recusa, no relatório de não entrega (NDR), ajuda a perceber qual deles responde: a MailRoute descreve os servidores do Outlook.com como olc.protection.outlook.com, e o domínio Microsoft 365 testado pela Spam Resource passava por um servidor em mail.protection.outlook.com.
Ferramentas de diagnóstico:
- SNDS (Smart Network Data Services): reputação de IP
- JMRP: feedback loop
Particularidades do Outlook:
- Usa Spamhaus e listas de bloqueio proprietárias
- Filtragem agressiva de novos domínios (<30 dias)
- Programa SNDS para monitorizar a reputação
Outlook.com (particulares)
A regra publicada pela Microsoft visa os remetentes de grande volume. Um domínio que envia mais de 5.000 mensagens por dia para o Outlook.com tem de passar no SPF e no DKIM, publicar um registo DMARC (no mínimo p=none) e passar no DMARC graças a um SPF ou a um DKIM alinhado com o domínio do From. O anúncio do site Postmaster do Outlook.com fixa o início a 5 de maio de 2025, primeiro com o envio para o lixo eletrónico e depois com rejeições; a rejeição associada é 550 5.7.515.
A rejeição relatada tem esta forma (a MailRoute assinala também uma variante sem o código entre parênteses):
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
No relatório de não entrega publicado no Microsoft Q&A a 6 de novembro, esta recusa surge dentro de outro código. A linha "Error Details" indica, com os dados pessoais retirados pelo moderador:
Error: 550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records
O relatório apresenta 550 5.7.23 como código de estado, sob o título "SPF validation error". O texto de ajuda que o acompanha fala apenas de SPF: verificar o registo, publicar apenas um, incluir nele spf.protection.outlook.com. O diagnóstico detalhado encontra-se depois da seta: é o 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records", que Hornblower409 associa ao AS9031519. Este modelo não prova que o seu SPF está errado. No mesmo tópico, Martin relata este invólucro e afirma ter SPF, DKIM e DMARC corretos há anos.
Se receber esta rejeição, leia e guarde primeiro o relatório completo: código exterior, texto interior, servidor que recusa e eventual AS9031519. Procure depois o registo DMARC em _dmarc.<domínio>. Para um subdomínio, veja também o do domínio principal, cuja política pode aplicar-se. É possível verificar o registo DMARC publicado sem linha de comandos. Uma consulta DNS que não chega ao fim (tempo esgotado, erro do servidor) não prova a ausência de registo: repita-a antes de tirar conclusões. Esta verificação mostra o que está publicado, não o resultado SPF ou DKIM de uma determinada mensagem.
Se nenhum registo DMARC se aplicar ao domínio:
- Publique um registo TXT em
_dmarc.<domínio>com o valorv=DMARC1; p=none. Muitos fornecedores de DNS acrescentam o domínio automaticamente: nesse caso, introduza apenas_dmarccomo nome. Um domínio só tem um registo DMARC: não crie um segundo com o mesmo nome, nem substitua uma política mais restritiva que já funciona. - Verifique se pelo menos o SPF ou o DKIM passa e está alinhado com o domínio do endereço de remetente apresentado (From). Um registo DMARC sem autenticação alinhada falha na mesma. Para controlar o alinhamento, envie uma mensagem para outra caixa de correio e leia o respetivo cabeçalho
Authentication-Results(consulte como ler os cabeçalhos de um email). - Aguarde que as caches DNS expirem: os servidores guardam durante algum tempo o registo antigo, ou o facto de não existir nenhum. Para um registo antigo, esse prazo é o respetivo TTL, definido na sua zona DNS. Se não existia nenhum registo, o tempo durante o qual os servidores retêm essa ausência depende do registo SOA da sua zona (cache negativa, RFC 2308), e não do TTL do novo registo. Reenvie depois as mensagens recusadas. Um 550 é uma falha permanente: o seu servidor não volta a tentar o envio.
A adição de um p=none é relatada como solução provisória para alguns domínios sem DMARC (Hornblower409 e Cameron Scott no tópico do Microsoft Q&A), e não como uma reparação do serviço da Microsoft. p=none não pede quarentena nem rejeição ao abrigo da política DMARC. Isso não garante, porém, a aceitação pelo Outlook.com, nem a chegada à caixa de entrada.
Se o SPF, o DKIM e o DMARC já estiverem corretos e as suas mensagens passarem na autenticação:
- Não reescreva uma configuração correta só para responder ao texto do relatório. Não publique um segundo registo SPF: dois registos SPF provocam um PermError (consulte o guia SPF PermError). Também não acrescente
include:spf.protection.outlook.comsó porque o relatório o sugere: o seu SPF deve autorizar os serviços que enviam realmente em nome do seu domínio. - Guarde o relatório completo e os elementos técnicos e, depois, comunique a rejeição ao Microsoft Sender Support. É o procedimento que Hornblower409 aconselha quando as mensagens recusadas com AS9031519 passam na autenticação.
- Em contexto empresarial, Daniel-Vo pedia a 9 de novembro que se fornecessem ao suporte do Microsoft 365 Network Message ID recentes, os logs das mensagens afetadas e exemplos em formato .eml. Estes elementos destinam-se ao suporte, não a um fórum público.
- Tente novamente mais tarde, sem garantia de resultado. As rejeições são relatadas como intermitentes, mas um 550 continua a ser uma falha permanente: o seu servidor não volta a tentar o envio, cabe-lhe a si reenviar a mensagem.
Um pass obtido noutra mensagem, ou noutro destinatário, ajuda no diagnóstico sem provar o veredicto do servidor do Outlook.com que recusou a sua. Como as rejeições são parciais, um reenvio aceite também não prova que a configuração está correta, avisa a MailRoute: verifique os registos em vez do resultado de um único envio.
Microsoft 365 (empresas)
O Microsoft 365 aplica os seus próprios mecanismos de filtragem. Acrescenta um veredicto proprietário compauth no cabeçalho Authentication-Results; um compauth=fail aumenta o risco de cair no lixo eletrónico (consulte o guia compauth do Microsoft 365). Durante o teste de Al Iverson (Spam Resource) de 7 de novembro de 2026, a mensagem recusada para outlook.com foi aceite para o domínio Microsoft 365 testado. Este teste isolado não mostra que os destinatários alojados no Microsoft 365 estão protegidos, nem que sofrem o mesmo incidente. Em contrapartida, os clientes do Microsoft 365 podem ser afetados enquanto remetentes, quando escrevem para o Outlook.com: é a eles que se dirige o pedido de suporte de Daniel-Vo citado acima. Leia sempre o texto completo do NDR.
Códigos de erro do Outlook.com e do Microsoft 365
| Código | Significado | Ação |
|---|---|---|
550 5.7.1 | Recusa genérica: ler o texto completo do NDR | Pedir a remoção da lista apenas se o texto indicar um bloqueio do IP, seguindo o procedimento que indica |
550 5.7.1 com "Message lacks SPF/DKIM/DMARC Auth Records" | Rejeição do Outlook.com relatada desde novembro de 2026 para domínios sem DMARC, mas também para domínios cuja autenticação passa | Verificar o registo DMARC e o alinhamento SPF ou DKIM sem concluir que falham só pelo texto da mensagem. Sem DMARC: publicar p=none e depois reenviar. Se tudo passar: comunicar ao Microsoft Sender Support |
550 5.7.23, quando acompanha o diagnóstico AS9031519 | Invólucro orientado para o SPF em torno da recusa 550 5.7.1 "Message lacks SPF/DKIM/DMARC Auth Records" (relatórios publicados no Microsoft Q&A, novembro de 2026). Sozinho, este código assinala uma falha SPF e não prova este incidente | Ler o diagnóstico depois da seta antes de mexer no SPF e seguir a situação correspondente (DMARC ausente ou autenticação já correta) |
550 5.7.515 | Nível de autenticação exigido não atingido (remetentes de grande volume para o Outlook.com) | SPF e DKIM válidos, DMARC publicado, alinhamento com o From |
550 5.7.606 | IP com baixa reputação | Consultar o SNDS e seguir o procedimento de remoção indicado no NDR. A recusa visa o IP: não retirar os destinatários recusados |
421 4.7.0 | Limite de taxa | Reduzir os envios |
Yahoo / AOL
Ferramentas de diagnóstico:
- Yahoo Sender Hub: reputação e diretrizes
- Complaint Feedback Loop: reclamações em tempo real
Exigências Yahoo 2024:
| Critério | Obrigatório |
|---|---|
| SPF | Obrigatório |
| DKIM | Obrigatório |
| DMARC | Obrigatório para >5.000 emails/dia |
| Cancelamento de subscrição 1-clique | Obrigatório |
| Taxa de reclamação | <0,3% |
Plano de ação recomendado
Etapa 1: Diagnóstico imediato (30 minutos)
- Teste o seu IP nas principais listas de bloqueio
- Verifique a autenticação (SPF, DKIM, DMARC) do seu domínio
- Analise um email problemático pelos seus cabeçalhos com o analisador de cabeçalhos de email
Se as suas mensagens forem recusadas em vez de classificadas como spam, parta do texto exato do NDR antes de qualquer pedido de remoção de lista. Um mesmo código 550 5.7.1 abrange várias causas. "Message lacks SPF/DKIM/DMARC Auth Records" não visa o seu IP: verifique o DMARC e o alinhamento, sem concluir que falham só pelo texto da mensagem. Também são assinaladas rejeições com a autenticação em pass; nesse caso, siga o procedimento "autenticação já correta" da secção Outlook.com. Um pedido de remoção só se justifica se o texto indicar o IP ou uma lista de bloqueio.
Etapa 2: Correções prioritárias (1-2 dias)
- Solicite a remoção se estiver em lista de bloqueio (Spamhaus, Barracuda prioritariamente)
- Corrija os erros de autenticação detetados
- Configure o reverse DNS se estiver a faltar
Etapa 3: Melhoria contínua (2-4 semanas)
- Registe-se nos feedback loops (Gmail, Outlook, Yahoo)
- Monitorize as taxas de reclamação (objetivo <0,1%)
- Limpe as suas listas: retire os endereços inativos há mais de 6 meses e os hard bounces cuja recusa diz respeito ao endereço (utilizador desconhecido, caixa de correio inexistente). Se a recusa visar o seu domínio, o seu IP ou a sua autenticação, corrija a causa e reenvie, sem retirar o destinatário
- Implemente uma monitorização regular das listas de bloqueio
Etapa 4: Prevenção a longo prazo
- Double opt-in para todas as inscrições
- Cancelamento de subscrição fácil (1-clique, cabeçalho list-unsubscribe)
- Monitorização automatizada das listas de bloqueio e da reputação
- Auditoria trimestral da configuração de email
FAQ
Porque é que os meus emails vão para o spam mesmo tendo configurado SPF e DKIM?
SPF e DKIM sozinhos não são suficientes. Desde 2024, Gmail e Yahoo também exigem DMARC aos remetentes em massa. No Outlook.com, desde o início de novembro de 2026 são relatadas rejeições de domínios sem DMARC, inclusive com volumes baixos, mas também de domínios cuja autenticação passa; a 9 de novembro, um moderador do Microsoft Q&A associava-as a uma degradação do serviço (consulte a pergunta seguinte). Verifique também se o seu IP não está numa lista de bloqueio e se a sua taxa de reclamação está abaixo de 0,1%. Uma falha em qualquer um desses pontos pode acionar o spam, mesmo com autenticação parcial.
Porque é que o Outlook.com rejeita os meus emails com AS9031519 apesar de o SPF e o DKIM serem válidos?
Desde o início de novembro de 2026 são relatadas duas situações. Vários operadores (lista Mailop, MailRoute, Spam Resource) observam esta rejeição em domínios sem registo DMARC; participantes do tópico do Microsoft Q&A "SPF Validation Error" assinalam-na também, de forma intermitente, com SPF, DKIM e DMARC em pass. A 9 de novembro de 2026, Daniel-Vo, apresentado nesse tópico como "Microsoft External Staff" e moderador, descrevia um problema do serviço Exchange para Outlook.com, Hotmail.com e Live.com, classificado como "service degradation", cuja causa ainda estava por apurar. Não é uma entrada do Service Health nem uma nova regra publicada. O relatório de não entrega pode apresentar 550 5.7.23 e o título "SPF validation error": leia o diagnóstico depois da seta antes de mexer no SPF. Se não existir nenhum DMARC aplicável, publique um TXT v=DMARC1; p=none em _dmarc.<domínio>, verifique se o SPF ou o DKIM passa e se mantém alinhado com o domínio do From, e depois reenvie as mensagens recusadas: um 550 é definitivo, o seu servidor não volta a tentar. p=none é uma solução provisória relatada, sem garantia de aceitação. Se a autenticação já passa, não reescreva os seus registos: guarde o relatório completo e comunique a rejeição ao Microsoft Sender Support.
Como saber se o meu IP está numa lista de bloqueio?
Use um verificador de lista de bloqueio que teste o seu IP nas principais listas (Spamhaus, Barracuda, SpamCop). O teste cobre mais de 25 listas de bloqueio simultaneamente e fornece os links de remoção para cada lista em que estiver. Teste o seu IP imediatamente se os seus emails estiverem a ser rejeitados ou classificados como spam.
Quanto tempo leva para sair de uma lista de bloqueio?
Os prazos variam conforme a lista de bloqueio: SpamCop remove automaticamente em 24-48h sem novas denúncias. Spamhaus processa solicitações manuais em 24-48h. Barracuda responde em 12-24h. UCEProtect tem um prazo de 7 dias. Em todos os casos, o problema que causou a listagem deve ser corrigido antes de solicitar a remoção.
Meus emails vão para spam apenas no Gmail, por quê?
O Gmail é particularmente rigoroso desde fevereiro de 2024. Verifique os seguintes pontos: (1) O DMARC está configurado com pelo menos p=none? (2) A taxa de reclamação está abaixo de 0,1%? (3) O cancelamento de subscrição em 1-clique está implementado para emails em massa? Use o Google Postmaster Tools para ver a reputação do seu domínio no Gmail.
Como melhorar a minha taxa de entregabilidade rapidamente?
Ações imediatas: (1) Verifique e corrija a sua autenticação SPF/DKIM/DMARC. (2) Teste o seu IP nas listas de bloqueio e solicite remoção se necessário. (3) Retire da sua lista os hard bounces cuja recusa diz respeito ao endereço (utilizador desconhecido, caixa de correio inexistente), bem como os inativos há mais de 6 meses. Se a recusa visar o seu domínio, o seu IP ou a sua autenticação, corrija a causa e reenvie antes de mexer na lista. (4) Reduza os envios para endereços que nunca abrem. Essas ações podem melhorar a entregabilidade em 1-2 semanas.
Qual é a taxa de reclamação aceitável?
O limite crítico é 0,1% (1 reclamação para cada 1.000 emails). Acima disso, Gmail e Yahoo começam a classificar os seus emails como spam. O Google recomenda ficar abaixo de 0,05% para uma entregabilidade ideal. Monitorize essa taxa pelos feedback loops e Google Postmaster Tools.
Meu servidor de email está bem configurado, mas meus emails ainda vão para spam?
Se a configuração técnica estiver correta, o problema provavelmente está relacionado a: (1) A reputação do seu IP ou domínio (verifique as listas de bloqueio). (2) O conteúdo dos seus emails (palavras gatilho, proporção imagem/texto). (3) O engajamento dos destinatários (baixa taxa de abertura, reclamações). Analise os seus cabeçalhos para identificar o fator causador.
Como aquecer um novo IP para envio de emails?
O aquecimento de IP consiste em aumentar progressivamente o volume de envio ao longo de 4-6 semanas. Comece com 50-100 emails/dia para os seus destinatários mais engajados, depois dobre o volume a cada semana. Monitorize bounces e reclamações. Nunca passe de 0 para milhares de emails/dia, pois isso aciona os filtros anti-spam.
O que muda com a exigência HELO/PTR da Spamhaus de novembro de 2026?
A partir de novembro de 2026, a Spamhaus implementa progressivamente uma exigência para cada IP de envio: um reverse DNS (PTR) que aponte para um FQDN, esse FQDN a resolver para o mesmo IP (registo A) e um nome HELO/EHLO que resolva para o IP de envio e se mantenha igual de uma ligação para outra. Segundo a Spamhaus, um reverse DNS ausente ou discordante é uma das razões mais comuns para ponderar a listagem de um IP. A Spamhaus não publicou nem um dia preciso nem um calendário: trata-se de uma implementação progressiva, não de um corte numa data fixa. Em IPv6, o endereço de envio deve estar num bloco /64 ou maior, com um reverse DNS válido.
Glossário
- DNSBL (DNS-based Blackhole List): Lista de bloqueio de IPs consultável por consulta DNS. Também chamada de RBL (Realtime Blackhole List).
- SPF (Sender Policy Framework): Registo DNS listando os servidores autorizados a enviar emails por um domínio.
- DKIM (DomainKeys Identified Mail): Assinatura criptográfica adicionada aos emails para provar a sua autenticidade.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): Política que define o tratamento de emails que falham no SPF/DKIM.
- Hard bounce: Falha de entrega permanente (código 5xx). O endereço pode não existir, mas a recusa também pode visar o seu domínio ou a sua autenticação. O servidor de envio não volta a tentar: depois da correção, reenvie a mensagem. Antes de retirar um endereço das suas listas, verifique se a recusa diz mesmo respeito a esse endereço.
- Soft bounce: Email temporariamente rejeitado (caixa cheia, servidor indisponível).
- Feedback loop: Programa que permite aos remetentes receberem as denúncias de spam dos destinatários.
- Reverse DNS (PTR): Registo DNS associando um endereço IP a um nome de domínio.
- FQDN (Fully Qualified Domain Name): Nome de domínio completo (ex: mail.captaindns.com).
- Reputação de IP: Score atribuído a um endereço IP com base no seu histórico de envio.
Guias relacionados sobre listas de bloqueio
- Como remover o seu IP de uma lista de bloqueio: o guia completo de remoção: Procedimentos detalhados para Spamhaus, Barracuda, SpamCop e mais
- Spamhaus vs Barracuda vs SpamCop: Comparativo: As 3 principais blacklists explicadas
Fontes
- Google Email Sender Guidelines (2024) (exigências oficiais do Gmail)
- Yahoo Sender Best Practices (diretrizes do Yahoo/AOL)
- Microsoft 365 Anti-Spam Protection (documentação do Outlook)
- Microsoft Support - Fix NDR error 550 5.7.515 in Outlook.com (regra oficial dos remetentes de grande volume para o Outlook.com)
- Outlook.com Postmaster (anúncio dos requisitos para os remetentes de grande volume, início a 5 de maio de 2025, consultado a 8 de novembro de 2026)
- Spam Resource - Microsoft newly rejecting mail lacking DMARC? (7 de novembro de 2026) (observações e testes de Al Iverson)
- Mailop - Microsoft requiring DMARC now or just us? (testemunhos de operadores, novembro de 2026)
- MailRoute - 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records (6 de novembro de 2026) (experiência operacional de um fornecedor de relay)
- Microsoft Q&A - SPF Validation Error (tópico aberto a 6 de novembro de 2026) (troca de mensagens de suporte, não documentação normativa: declaração de 9 de novembro de 2026 de Daniel-Vo, Microsoft External Staff e moderador, resposta do moderador voluntário Hornblower409 e testemunhos de utilizadores; consultado a 10 de novembro de 2026)
- The Register - Outlook.com bounces legit emails as Microsoft's authentication crackdown goes sideways (9 de novembro de 2026) (artigo de imprensa)
- RFC 7489 - DMARC (especificação técnica)
- Spamhaus - Understanding DNSBLs (funcionamento das listas de bloqueio)
- Spamhaus Sender Guidelines (exigências HELO, PTR e A para os IP de envio)
