Yahoo 554 5.7.9 "Message Not Accepted for Policy Reasons" — A Correção do Remetente (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

O Yahoo devolve 554 5.7.9 quando uma mensagem viola a sua política de remetentes — normalmente autenticação SPF/DKIM falhada ou uma política DMARC que o Yahoo está a aplicar. Corrija-o fazendo o SPF ou o DKIM passar, alinhado com o seu domínio From. Só 10,59% dos domínios aplicam o DMARC — 27.640.987 deles — segundo o censo do Defaults.Exposed de 261.086.232 domínios (2026-06-29).

A correção é DNS e higiene de lista, não um formulário de recurso: diagnostique que política está a violar, faça o SPF ou o DKIM passar para o domínio certo, alinhe a verificação vencedora com o seu endereço From, publique DMARC se envia em volume, e adicione anulação de subscrição com um clique. Abaixo está a ordem de passos mais um descodificador para os códigos irmãos do Yahoo — 553 5.7.1, 553 5.7.2 e os adiamentos 421.

O que significa o erro 554 5.7.9 do Yahoo?

Desde fevereiro de 2024, o Yahoo aplica a mesma família de regras de remetentes que o Gmail: todos os remetentes deviam passar SPF ou DKIM; os remetentes em massa têm de passar ambos, com o mecanismo a passar alinhado com o domínio From, publicar uma política DMARC, oferecer anulação de subscrição com um clique do RFC 8058 no correio de subscrição, e manter a taxa de reclamação baixa. O Yahoo recusa-se deliberadamente a publicar um limiar de volume para “massa” — a regra paralela da Google traça a linha em 5000 mensagens por dia, e esse é o padrão de referência que a maioria dos remetentes usa. As caixas de correio da AOL correm na mesma infraestrutura, portanto uma correção cobre ambas.

O 554 5.7.9 é a rejeição de política permanente do Yahoo. A forma clássica diz: “554 5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codes” — deliberadamente genérica, porque cobre toda a família de política: falhas de autenticação, aplicação de DMARC (incluindo o p=reject próprio do domínio remetente), e violações das diretrizes para remetentes. Ao contrário do 550-5.7.26 do Gmail, o texto raramente diz qual verificação falhou, portanto o passo 1 abaixo — uma verificação do exterior ao seu domínio — importa mais aqui, não menos.

A lacuna subjacente é enorme: em todo o censo de 2026-06-29 de 261.086.232 domínios, 46,4% (121.145.609) não publicam registo SPF nenhum, e só 10,59% aplicam o DMARC. O Yahoo não está a pedir nada exótico — está a rejeitar correio da maioria não autenticada.

Que código de devolução do Yahoo tem?

Compare o seu NDR contra esta tabela — tratando cada entrada como “uma devolução parecida com:”, porque o Yahoo publica oficialmente categorias de erro em vez de strings literais, e a redação exata e as etiquetas de razão entre parênteses (como [TSS04]) são observadas na prática e mudam ao longo do tempo. Verifique os fragmentos contra a sua devolução real e a lista de códigos de erro do Sender Hub do Yahoo.

Código	Uma devolução parecida com (fragmento)	O que significa	Onde está a correção
554 5.7.9	”Message not accepted for policy reasons”	Rejeição de política permanente — falha de autenticação, DMARC ou diretrizes para remetentes	Este guia, passos 2–6
553 5.7.1	Texto de política de IP ou conteúdo, muitas vezes com uma etiqueta de razão entre parênteses (por exemplo, referência a lista de bloqueio)	O Yahoo não aceita a partir deste IP/origem — bloqueio de reputação ou política	Passos 2–3, depois envio limpo; a autenticação previne recaídas mas não remove um IP da lista
553 5.7.2	”will be permanently deferred” / repetir não terá sucesso	Falha de reputação sustentada no IP de envio — a versão dura de um adiamento	Passos 2–7, aquecimento de novo IP se autoalojado
421 4.7.0	”temporarily deferred due to unexpected volume or user complaints” (muitas vezes uma etiqueta [TSS])	Adiamento temporário — pico de ritmo ou reclamações, não um bloqueio permanente	As filas de repetição vão drenar; corrija os passos 5–7 para que pare de se repetir

Duas notas honestas sobre essa tabela. Um adiamento 421 é o Yahoo a limitar o seu ritmo enquanto decide — respeite a repetição, abrande, e corrija o lado das reclamações; martelar a fila converte adiamentos em 553s. E nenhum registo DNS remove um IP de uma lista de bloqueio: a autenticação trava as rejeições de política e previne recaídas, mas a reputação do IP só recupera através de envio limpo ao longo do tempo.

Como se corrige o 554 5.7.9, passo a passo?

Execute primeiro a verificação gratuita em defaults.exposed. Lê os seus registos reais de SPF, DKIM e DMARC a partir do exterior — a mesma vista que o Yahoo tem — e mostra qual verificação está a falhar antes de tocar no DNS.
Faça o SPF passar para o domínio que o Yahoo realmente verifica. A salvaguarda que apanha metade de todos os remetentes: os recetores avaliam o SPF contra o domínio do Return-Path (RFC5321.MailFrom), não o cabeçalho From. Se uma ferramenta de newsletter ou CRM envia por si, o SPF é normalmente avaliado contra o domínio de devolução deles — é por isso que o seu próprio registo SPF pode estar perfeito e irrelevante. Confirme para que domínio as suas devoluções retornam, depois assegure que o SPF desse domínio cobre a origem de envio.
Ative a assinatura DKIM com o seu próprio domínio. No seu fornecedor ou ESP, ative o DKIM de domínio personalizado (normalmente dois ou três registos CNAME) para que as assinaturas digam d=oseudominio.com, não a predefinição da plataforma. Guias de plataforma: falhas de DMARC do Mailchimp, Brevo e Klaviyo.
Faça a verificação que passa alinhar com o seu domínio From. Os requisitos do Yahoo — como o DMARC — importam-se com o alinhamento: SPF ou DKIM a passar para um domínio que corresponde ao do seu endereço From. Se a sua verificação mostrar SPF e DKIM verdes mas o Yahoo continuar a rejeitar, está na armadilha do alinhamento — veja DMARC falha mas SPF e DKIM passam.
Publique um registo DMARC se envia em volume. O Yahoo exige pelo menos p=none com um endereço de relatórios dos remetentes em massa — não publica nenhum número de volume rígido, portanto trate os 5000/dia da Google como o padrão de referência. É um registo TXT em _dmarc — veja o guia de correção do DMARC para o registo e o plano de aperto, e o guia de configuração de DMARC na IONOS para um exemplo trabalhado num painel de controlo. Vai ficar à frente de 89,41% dos domínios ao aplicá-lo eventualmente.
Adicione anulação de subscrição com um clique do RFC 8058 (cabeçalhos List-Unsubscribe + List-Unsubscribe-Post) no correio de marketing e de subscrição, e honre as anulações dentro de dois dias. Os ESP reputados adicionam isto automaticamente assim que a autenticação de domínio está ativa — verifique nos cabeçalhos de uma mensagem enviada.
Mantenha as reclamações baixas. O Yahoo pesa fortemente as ações “marcar como spam” dos utilizadores — mantenha a sua taxa de spam abaixo de 0,3% — e picos de reclamação sustentados são o caminho principal de adiamentos 421 para rejeições 553/554. Registe-se no ciclo de feedback de reclamações do Yahoo através do seu Sender Hub, elimine endereços sem interação, e nunca envie a listas compradas.

A maioria dos remetentes resolve o 554 5.7.9 nos passos 2–4; os passos 5–7 são o que o mantém fora do ciclo de adiamento depois disso. Para a lista completa de requisitos de ambos os fornecedores — limiares, cabeçalhos, números de taxa de spam — veja o nosso artigo de referência sobre os requisitos da Google e da Yahoo para remetentes; este guia mantém-se focado em corrigir a devolução.

As regras do Yahoo aplicam-se a pequenos remetentes?

A lista de verificação em massa — SPF e DKIM, alinhamento, DMARC publicado, anulação de subscrição com um clique — aplica-se formalmente a remetentes de volume significativo, e o Yahoo recusa-se explicitamente a pôr um número em “significativo” (a regra paralela da Google usa 5000 mensagens por dia, o padrão de referência comum de trabalho). Mas a autenticação básica é esperada de todos, e o 554 5.7.9 não verifica o seu volume antes de disparar: pequenos remetentes atingem-no através da infraestrutura partilhada do seu ESP, através do p=reject do seu próprio domínio com correio não alinhado, ou simplesmente ao enviar a partir de um domínio sem autenticação nenhuma — os 46,4% dos domínios sem registo SPF (censo de 2026-06-29). Trate os passos 1–4 como obrigatórios em qualquer volume.

Isto é o mesmo que o 550-5.7.26 do Gmail?

Mesma família de regras, dialeto diferente. A Google e o Yahoo anunciaram os seus requisitos juntos no final de 2023 e ambos começaram a aplicá-los em fevereiro de 2024, portanto um domínio corrigido para um está essencialmente corrigido para o outro. As diferenças práticas: o texto de devolução do Gmail normalmente nomeia o mecanismo que falhou, o 554 5.7.9 do Yahoo normalmente não; e o Yahoo apoia-se mais em adiamentos de IP guiados por reclamações. A ser devolvido em ambos? Corrija aqui uma vez, depois verifique as especificidades do Gmail no guia do 550-5.7.26.

Perguntas frequentes

O 554 5.7.9 significa que o Yahoo colocou o meu domínio numa lista de bloqueio? Normalmente não. É uma rejeição de política — mais frequentemente autenticação — não um veredito de reputação, e é totalmente corrigível no DNS. É também terreno extremamente comum onde estar: só 10,59% dos 261.086.232 domínios aplicam uma política DMARC segundo o censo de 2026-06-29. Rejeições 553 5.7.2 persistentes depois de a sua autenticação estar limpa são o caso de reputação.

Porque é que a minha newsletter é devolvida pelo Yahoo quando o endereço From é @yahoo.com? Porque o Yahoo publicou p=reject nos seus próprios domínios de consumidor já em 2014 — qualquer serviço de terceiros a enviar From @yahoo.com falha o próprio DMARC do Yahoo e é rejeitado, por design. A correção é estrutural: envie a partir do seu próprio domínio com a sua própria autenticação, não a partir de um endereço de correio gratuito. A configuração de domínio personalizado do seu ESP é o caminho — veja o guia de plataformas de newsletter.

Quanto tempo depois de corrigir o DNS é que o Yahoo vai aceitar o meu correio? As correções de autenticação atuam assim que os novos registos estiverem visíveis — minutos a algumas horas, até 48 para TTLs lentos. A recuperação de reputação é mais lenta: os adiamentos 421 desaparecem ao longo de dias de envio limpo e sem reclamações, e um adiamento permanente 553 5.7.2 pode levar semanas ou um novo aquecimento.

Envie o relatório ao proprietário

Se está a resolver esta devolução para um cliente, não feche o pedido com “o Yahoo aceita o nosso correio outra vez”. Volte a executar a verificação gratuita depois das suas mudanças e reencaminhe o relatório classificado ao dono do negócio. Mostra, em linguagem simples, que o domínio agora autentica o seu email e onde ainda fica aquém — a evidência de que vão precisar para as renovações do seguro cibernético e os questionários de segurança de fornecedores. Você corrigiu a devolução; o relatório prova-o.

Verifique o seu domínio → · Guia do 550-5.7.26 do Gmail → · Corrigir o DMARC → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.