Requisitos para remetentes do Gmail e Yahoo em 2026: o que realmente é aplicado

Os requisitos para remetentes em volume do Gmail e Yahoo entraram em vigor em 1º de fevereiro de 2024, e na maior parte daquele primeiro ano deixá-los de lado significava pior posicionamento, não e-mail bloqueado. Essa tolerância acabou. Desde novembro de 2025, o Gmail rejeita tráfego fora das regras no nível SMTP, o que significa que os requisitos agora aparecem no seu log de bounces em vez da sua taxa de abertura.

Esta é uma checagem de status para 2026: quais são as regras, como a aplicação realmente aparece no protocolo e o que verificar nos seus próprios domínios hoje.

Os requisitos, em uma tabela

As diretrizes para remetentes de e-mail do Google e o Yahoo Sender Hub convergiram para regras quase idênticas. Dois níveis:

Requisito	Para quem vale
Autenticação por SPF ou DKIM	Todos
Registro PTR válido (DNS direto e reverso correspondentes)	Todos
TLS na conexão de envio	Todos
Taxa de spam abaixo de 0.3%, idealmente abaixo de 0.1%	Todos
SPF e DKIM, ambos passando	Remetentes em volume
Registro DMARC, no mínimo p=none, com domínio From alinhado	Remetentes em volume
Descadastro com um clique (RFC 8058) mais um link visível no corpo	Remetentes em volume, e-mail de marketing
Descadastros atendidos em até 2 dias	Remetentes em volume

Remetente em volume é qualquer pessoa que envie perto de 5.000 mensagens ou mais para contas pessoais do Gmail em um período de 24 horas. Dois detalhes do FAQ das diretrizes para remetentes do Google que a maioria dos resumos deixa de fora: o status de remetente em volume não tem data de validade, um único dia qualificado marca o domínio permanentemente, e as regras valem apenas para e-mail enviado a contas pessoais do Gmail, não a destinatários do Google Workspace. O Yahoo especifica ainda uma chave DKIM mínima de 1024 bits.

O registro DMARC mínimo que satisfaz os dois provedores é uma linha:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

O gerador de DMARC monta esse registro com um endereço de relatórios, e o requisito de alinhamento, seu domínio From correspondendo ao domínio que o SPF ou o DKIM validou, é a parte para testar em vez de presumir.

Como a aplicação acontece em 2026

Ao longo de 2024 e da maior parte de 2025, um remetente fora das regras via principalmente degradação silenciosa: entrega na pasta de spam e dano lento à reputação. O FAQ do Google agora diz isso explicitamente: desde novembro de 2025, mensagens fora das regras “sofrerão interrupções, incluindo rejeições temporárias e permanentes”.

No protocolo, a rejeição permanente para e-mail sem autenticação é 550 5.7.26:

550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF [example.com] with ip: [203.0.113.25] = did not pass
550 5.7.26 For instructions on setting up authentication, go to
550 5.7.26 https://support.google.com/mail/answer/81126#authentication

Leia de baixo para cima: a mensagem nomeia o domínio e o IP que avaliou, e qual das duas verificações falhou. As duas falhando geralmente significa registro ausente; uma falhando geralmente significa um fornecedor enviando em seu nome sem alinhamento. O FAQ do Gmail também documenta uma família de códigos temporários 4.7.x que limitam a taxa do tráfego suspeito em vez de recusá-lo; o 4.7.28, por exemplo, é uma cota de volume sobre um IP, domínio ou chave DKIM que está se comportando mal. Um adiamento 4xx gera novas tentativas; trate uma taxa crescente deles como o aviso antes do 5xx.

A aplicação do Yahoo depende de adiamento. A string que os remetentes veem, documentada nos códigos de erro SMTP do Yahoo, é o adiamento TSS04:

421 4.7.0 [TSS04] Messages from 203.0.113.25 temporarily deferred due to
unexpected volume or user complaints - 4.16.55.1;
see https://postmaster.yahooinc.com/error-codes

As duas causas nomeadas são o diagnóstico: ou o volume saltou de um jeito que o Yahoo não reconhece para aquele IP, ou os destinatários estão marcando como spam. Insistir nos reenvios piora as duas.

A ação: procure nos seus logs de bounce por 5.7.26, 4.7. e TSS04 nos últimos 30 dias. Se sua plataforma esconde os bounces brutos, a lista de supressão é a alternativa, e qualquer entrada com data posterior a novembro de 2025 com uma frase sobre autenticação merece uma olhada.

A linha de 0.3% de taxa de spam na prática

O número é medido no Google Postmaster Tools, e é mais rigoroso do que parece. A expectativa declarada do Google é ficar abaixo de 0.1% e nunca chegar a 0.3%. A consequência de cruzar essa linha mudou em junho de 2024: um domínio em 0.3% ou acima fica inelegível para mitigação, ou seja, o suporte do Google não intervém em um problema de entrega até que a taxa fique abaixo de 0.3% por 7 dias consecutivos. O limite não é só uma entrada do filtro; é a linha de elegibilidade para receber ajuda.

O Yahoo publica o mesmo teto de 0.3% com um detalhe que vale saber: a taxa deles é calculada sobre o e-mail entregue na caixa de entrada. E-mail que já cai na pasta de spam não consegue gerar reclamações, então um remetente pode ver a taxa medida melhorar enquanto o posicionamento despenca; o denominador está encolhendo, não o problema.

Uma campanha para um segmento parado pode gastar o orçamento inteiro: 0.3% são três reclamações por mil mensagens entregues. A ação é um piso, não um teto: abra o Postmaster Tools, confira o gráfico da taxa de spam dos últimos 90 dias e, se houver qualquer pico, cruze a data dele com o seu log de envios antes que a próxima campanha saia.

Descadastro com um clique: onde as implementações ainda falham

O requisito, obrigatório para e-mail de marketing em volume desde 1º de junho de 2024, é o RFC 8058, e é um par de cabeçalhos, não um link:

List-Unsubscribe: <https://example.com/u?t=8f3ac91>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

As armadilhas que ainda derrubam remetentes em 2026:

• Um link no rodapé não é o mecanismo. Os cabeçalhos são o que o Gmail renderiza como o próprio botão de descadastro no topo da mensagem. O FAQ do Google é explícito que links só de mailto e links de URL simples não satisfazem o requisito. O link visível no corpo é exigido além disso, não no lugar.
• O endpoint precisa aceitar um POST sem etapas humanas. Uma página de “gerenciar preferências” que exige login ou um clique de confirmação falha na definição de um clique.
• O prazo é de 2 dias. Os dois provedores exigem que o descadastro seja atendido em até dois dias. Uma sincronização semanal do seu ESP para o seu CRM perde o prazo.
• E-mail transacional é isento, e rotular marketing como transacional para escapar do botão é o tipo de coisa que as taxas de reclamação expõem sozinhas.

A ação: envie sua campanha mais recente para uma caixa que você controla e leia os cabeçalhos brutos; as duas linhas List-Unsubscribe devem estar presentes, e o analisador de cabeçalhos os mostra junto com os resultados de autenticação em uma única passada.

A Microsoft agora executa a mesma jogada

O terceiro grande provedor de caixa de entrada entrou em 2025. Desde 5 de maio de 2025, a Microsoft exige SPF, DKIM e um registro DMARC alinhado de domínios que enviam mais de 5.000 mensagens por dia para endereços Outlook.com, Hotmail e Live, e rejeita o e-mail fora das regras com seu próprio código permanente, percorrido no guia do 550 5.7.515 no Outlook:

550 5.7.515 Access denied, sending domain example.com does not
meet the required authentication level.

A consequência prática: não existe mais uma grande caixa de entrada de consumidor onde e-mail em volume sem autenticação seja apenas filtrado. Os mesmos três registros satisfazem os três provedores, então um domínio que passa no Gmail passa no Outlook, desde que o alinhamento se mantenha. Se o posicionamento no Outlook é o seu problema específico, a ordem de diagnóstico difere da do Gmail e está coberta no guia de e-mail indo para a pasta de spam.

O que verificar nos seus domínios hoje

Verificar a conformidade uma vez leva cerca de dez minutos com uma verificação de saúde do domínio: ela lê SPF, DKIM e DMARC juntos e informa se o alinhamento realmente se mantém, que é o modo de falha para o qual as strings de bounce acima continuam apontando.

O porém é que conformidade não é um estado que se alcança, é um estado que se desgasta. Os requisitos amarram registros que outras pessoas editam: um fornecedor integrado pelo marketing adiciona um include, uma migração de DNS derruba um registro _dmarc, uma plataforma troca um DKIM selector. Cada uma dessas mudanças é silenciosa, e desde novembro de 2025 o modo de falha do silêncio é e-mail rejeitado em vez de uma queda lenta. Uma verificação pontual responde à pergunta de hoje para um domínio; ela não tem memória de como os registros estavam antes da mudança, que é exatamente a informação que um pico de rejeições torna urgente. A LitInboxes reexecuta essas verificações em cada domínio monitorado a cada seis horas, guarda o histórico datado que transforma “os bounces começaram semana passada” em “o DKIM selector desapareceu numa terça-feira”, acompanha os sinais de taxa de spam e reputação, e envia as mudanças por e-mail, Slack, Discord ou webhook. Há um passo a passo aqui se você quiser ver isso em um domínio real.

O checklist

1. Confirme que SPF e DKIM passam em todas as plataformas que enviam como seu domínio, não só na principal.
2. Confirme que existe um registro DMARC no mínimo em p=none, com relatórios rua ligados, e que seu domínio From alinha com SPF ou DKIM.
3. Procure nos bounces dos últimos 30 dias por 5.7.26, 4.7. e TSS04.
4. Leia a taxa de spam no Postmaster Tools contra a meta de 0.1% e o teto de 0.3%, nos últimos 90 dias.
5. Envie uma campanha para você mesmo e confirme que os dois cabeçalhos List-Unsubscribe estão presentes e que o endpoint aceita um POST puro.
6. Confirme que os descadastros chegam à sua plataforma de envio em até 2 dias, não em uma sincronização semanal.
7. Confirme que o IP de envio tem um registro PTR que resolve de volta para o mesmo hostname.
8. Reverifique depois de qualquer mudança de DNS, adição de fornecedor ou migração de plataforma, porque é aí que domínios em conformidade param silenciosamente de estar em conformidade.