Todo e-commerce depende do e-mail para avisar o cliente de uma compra, recuperar um carrinho ou anunciar uma oferta. Se o provedor da caixa de entrada não confia no seu domínio, a mensagem mais bem planejada vai para a aba Promoções ou direto para o spam, e ninguém avisa.
Desde 2024, essa confiança deixou de ser subjetiva. Gmail e Yahoo passaram a exigir autenticação técnica de quem envia em volume, e o Outlook.com publicou requisitos parecidos. Quem não cumpre vê atraso, rejeição ou queda de entrega, sem que nenhuma métrica do disparo avise com clareza.
Este guia explica o que cada provedor exige, como configurar SPF, DKIM e DMARC, como ler o painel do Google Postmaster Tools e o que fazer, em ordem, nos próximos sete dias. Cada dado traz a fonte. O que é recomendação da Analytikos está identificado como tal.
O que Gmail, Yahoo e Outlook exigem hoje
As regras do Gmail valem para mensagens enviadas a contas pessoais (@gmail.com e googlemail.com). Elas se dividem em dois níveis, conforme a página oficial de diretrizes para remetentes do Google. Todo remetente precisa de SPF ou DKIM, DNS direto e reverso válidos, criptografia TLS, taxa de spam abaixo de 0,3% e mensagens no formato da RFC 5322. Quem envia 5.000 mensagens ou mais por dia para o Gmail precisa também de SPF e DKIM juntos, DMARC publicado, alinhamento do domínio do remetente e descadastro em um clique.
O FAQ oficial do Google define a contagem: mensagens de subdomínios somam no domínio principal. Se 2.500 mensagens saem de loja.com.br e 2.500 de promo.loja.com.br no mesmo dia, o total é 5.000 e o remetente é tratado como remetente em massa. Quem atinge o critério uma vez é considerado remetente em massa de forma permanente.
A tabela resume os três provedores. Ela cobre apenas o que as páginas oficiais informam; onde o provedor não divulga um número, isso está indicado.
| Requisito | Gmail | Yahoo | Outlook.com |
|---|---|---|---|
| Limite que define “alto volume” | 5.000 mensagens por dia para contas Gmail pessoais | Não divulga limite de volume | 5.000 mensagens por dia para serviços de consumo da Microsoft |
| SPF e DKIM | Obrigatórios para remetente em massa | Obrigatórios | Obrigatórios, publicados e passando |
| DMARC | Obrigatório para remetente em massa, no mínimo p=none | No mínimo p=none, passando | Obrigatório, com SPF ou DKIM alinhado ao From |
| Descadastro em um clique | Obrigatório em mensagens de marketing, além do link visível no corpo | Altamente recomendado, atender em 2 dias | Não consta na página consultada |
| Taxa de spam | Abaixo de 0,10% e nunca atingir 0,30% | Abaixo de 0,3% | Não consta na página consultada |
| Erro típico de rejeição | 4.7.31 (sem DMARC), 4.7.23 (PTR), 4.7.29 (TLS) | Não detalhado nas páginas consultadas | 550 5.7.515: domínio sem o nível de autenticação exigido |
Os detalhes de cada coluna estão nas páginas oficiais: Yahoo Sender Hub, que declara que não especifica limite de volume, e o suporte da Microsoft sobre o erro 550 5.7.515, que descreve os requisitos de SPF, DKIM e DMARC para alto volume. Para o Gmail, o FAQ registra que o reforço da aplicação das regras sobre tráfego fora de conformidade começou em novembro de 2025, com rejeições temporárias e permanentes.
SPF, DKIM e DMARC: o que cada um faz
Os três protocolos respondem a perguntas diferentes. O SPF diz quais servidores podem enviar em nome do domínio. O DKIM prova que a mensagem não foi alterada e foi assinada pelo domínio. O DMARC define o que o destinatário deve fazer quando SPF e DKIM falham ou não estão alinhados ao domínio que aparece no remetente.
SPF: a lista de servidores autorizados
O SPF é um registro TXT no DNS. Um exemplo genérico, que você deve adaptar ao seu provedor de envio:
v=spf1 include:_spf.seuprovedor.com ~allDois pontos técnicos da RFC 7208 causam a maioria dos erros. Primeiro, o registro pode disparar no máximo 10 consultas DNS (includes, a, mx e similares). Acima disso o resultado é erro permanente (permerror) e o SPF deixa de valer. Segundo, o qualificador ~all indica falha branda (softfail) e -all indica falha explícita. A RFC orienta que o receptor não rejeite uma mensagem apenas por softfail.
Cada ferramenta que envia e-mail em nome da loja (plataforma de e-commerce, CRM, atendimento, nota fiscal) tende a pedir seu próprio include. Com quatro ou cinco serviços, o limite de 10 consultas é atingido com facilidade. Esse cenário é um exemplo da Analytikos, não um dado da RFC.
DKIM: a assinatura da mensagem
O DKIM usa um par de chaves. A chave pública fica no DNS, em um registro TXT no formato seletor._domainkey.seudominio.com.br. A privada assina cada mensagem. A RFC 6376 exige chaves RSA de pelo menos 1024 bits, e Google e Yahoo recomendam 2048 bits. Ao ativar o DKIM no seu provedor de envio, ele fornece o seletor e o valor a publicar. Use um seletor por serviço, para poder trocar a chave de um sem afetar os outros.
DMARC: a política e o relatório
O DMARC é um registro TXT em _dmarc.seudominio.com.br. O ponto de partida para quem ainda não tem política é monitorar sem bloquear:
v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com.brA tag p define a política (none, quarantine ou reject) e rua indica onde receber os relatórios agregados. O Google exige, no mínimo, p=none para remetentes em massa. A trajetória usual é começar em none, analisar os relatórios por algumas semanas, corrigir os remetentes legítimos que falham e só então endurecer para quarantine e reject. Essa sequência é recomendação da Analytikos.
Uma atualização relevante: em maio de 2026 o IETF publicou a RFC 9989, que obsoleta a RFC 7489 e inclui, entre outras mudanças, um apêndice sobre a remoção da tag pct. Os guias dos provedores ainda mencionam pct em alguns contextos, então revise a documentação do seu provedor de DNS e de envio antes de depender dela.
Alinhamento: passar no teste não basta
Um erro frequente é ver SPF e DKIM como “pass” e supor que o DMARC também passa. O DMARC exige alinhamento: o domínio do endereço visível no campo From precisa coincidir com o domínio validado pelo SPF ou pelo DKIM (basta um dos dois). Na RFC 7489, o modo relaxado (padrão) aceita o mesmo domínio organizacional, como mail.loja.com.br para loja.com.br. O modo estrito exige o nome idêntico.
O caso clássico em e-commerce: a plataforma de e-mail envia com o próprio domínio no Return-Path e assina o DKIM com o domínio dela. SPF e DKIM passam, mas nenhum alinha com o domínio da loja, e o DMARC falha. A correção é configurar o domínio de envio personalizado e o DKIM com o seu domínio no provedor.
Descadastro em um clique: o que o cabeçalho precisa ter
Para mensagens de marketing, o Google exige descadastro em um clique, além do link visível no corpo. O FAQ do Google ressalta que o link isolado ou um mailto não bastam: são necessários os cabeçalhos List-Unsubscribe e List-Unsubscribe-Post da RFC 8058. Mensagens transacionais, como redefinição de senha ou confirmação de pedido, ficam fora dessa exigência.
List-Unsubscribe: <https://loja.com.br/descadastro?token=ABC123>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickPela RFC, os dois cabeçalhos devem estar cobertos pela assinatura DKIM, e a resposta ao POST não deve redirecionar. O prazo para efetivar o descadastro é de 48 horas no Google (FAQ) e de 2 dias no Yahoo. Na prática, a Analytikos recomenda efetivar na hora: o descadastro rápido reduz o clique em “marcar como spam”, que é o que pesa na taxa de reclamação.
Taxa de spam: como calcular e o que fazer com o resultado
A taxa de spam do Google Postmaster Tools é a proporção de mensagens entregues na caixa de entrada de destinatários engajados que foram marcadas como spam. O denominador é o que chegou à caixa de entrada, não o que foi enviado. A página de ajuda do Postmaster Tools informa ainda que só entram na conta as mensagens autenticadas com DKIM e que a taxa pode levar até 7 dias para cair depois da correção.
A conta é simples: taxa = denúncias de spam ÷ mensagens entregues na caixa de entrada. Veja três cenários com 20.000 mensagens na caixa de entrada (números ilustrativos, não dados reais):
Denúncias de spam em 20.000 mensagens na caixa de entrada
Com 14 denúncias (14 ÷ 20.000 = 0,07%) o remetente está dentro da meta de 0,10%. Com 40 (0,20%) já ultrapassou a meta, mas ainda não chegou ao limite. Com 60 (0,30%) o remetente perde a elegibilidade para a mitigação do Google, segundo o FAQ, e só a recupera após 7 dias seguidos abaixo de 0,3%. Em uma base de 100.000 mensagens na caixa de entrada, o teto de 0,10% equivale a 100 denúncias e o de 0,30% a 300.
Se o número sobe, a causa quase sempre está em frequência alta, lista sem consentimento claro ou conteúdo que a pessoa não esperava. Revise a pressão de contato (veja por que o excesso de personalização derruba resultados) e priorize quem abriu ou comprou nos últimos 90 dias. Esse recorte é recomendação da Analytikos.
Plano de 7 dias para colocar a autenticação em dia
Se você ainda não revisou nada, a ordem abaixo evita retrabalho. Ela reserva as semanas seguintes para observar os relatórios do DMARC antes de endurecer a política. É uma sequência sugerida pela Analytikos, montada a partir dos requisitos oficiais.
Do inventário ao monitoramento em 7 dias
- 1Dia 1: inventário de remetentesListe todas as ferramentas que enviam e-mail com o domínio da loja: plataforma, CRM, atendimento, nota fiscal.
- 2Dia 2: SPFConsolide em um único registro, com no máximo 10 consultas DNS.
- 3Dia 3: DKIMAtive a assinatura em cada serviço, com chave de 2048 bits e domínio próprio.
- 4Dia 4: DMARC em monitoramentoPublique p=none com rua e comece a receber os relatórios.
- 5Dia 5: descadastro em um cliqueInclua List-Unsubscribe e List-Unsubscribe-Post nas mensagens de marketing.
- 6Dia 6: Postmaster ToolsVerifique o domínio e confira o painel de conformidade.
- 7Dia 7: listaSepare quem não interage há 90 dias e reduza o envio para esse grupo.
Autenticação resolve a entrega; o que cada segmento recebe e quando é tema da medição e otimização do e-mail marketing e da estratégia de relacionamento.
Como ler o painel de conformidade do Postmaster Tools
Na versão atual do Postmaster Tools, o painel de conformidade mostra, para cada requisito, um dos três estados: Compliant, Needs work ou No data found. Para todos os remetentes aparecem SPF, DKIM, registros DNS, formato da mensagem, criptografia e taxa de spam. Para remetentes em massa, aparecem também DMARC, descadastro em um clique e atendimento do descadastro em 48 horas.
Alguns cuidados de leitura, todos da documentação do Google: o painel usa média móvel de vários dias, reporta apenas o domínio principal (mesmo usando dados de subdomínios), conta somente mensagens para contas Gmail pessoais e reflete o DNS observado no recebimento, não a configuração atual. Volume baixo gera dados incompletos, e “No data found” não significa erro. Por isso, uma correção feita hoje pode levar dias para aparecer no painel.
Erros comuns que derrubam a entrega
- Mais de um registro SPF no mesmo domínio. Só pode haver um; junte os includes em um registro.
- Estourar as 10 consultas DNS do SPF. Remova serviços que não enviam mais e-mail.
- DKIM assinado com o domínio do provedor. O SPF e o DKIM passam, mas nenhum alinha com o domínio da loja.
- DMARC sem endereço de relatório. Sem rua, você não vê quem envia em seu nome.
- Mudar para reject sem observar. Pode bloquear sistemas legítimos que ninguém inventariou.
- Link de descadastro sem os cabeçalhos da RFC 8058. O botão do Gmail não funciona como esperado.
- Misturar marketing e transacional no mesmo domínio de envio. Uma reclamação de campanha pode afetar a confirmação de pedido. Separar em subdomínios é recomendação da Analytikos, não exigência dos provedores.
- Comprar ou alugar lista. Eleva denúncias e contraria a base legal da LGPD (Lei 13.709/2018).
Os erros de rejeição também ajudam no diagnóstico. Segundo o FAQ do Google, 4.7.31 indica domínio sem DMARC ou sem política, 4.7.23 e 5.7.25 apontam problema no DNS reverso (PTR) e 4.7.29 e 5.7.29 apontam falha de TLS. No Outlook.com, o erro 550 5.7.515 indica que o domínio não atende ao nível de autenticação exigido.
O contexto brasileiro
Três pontos pesam no Brasil. Primeiro, a autenticação se aplica igual a domínios .com.br: o provedor olha o domínio do remetente, não o país. Segundo, o CERT.br recomenda separar o envio autenticado por submissão (porta 587) do transporte entre servidores (porta 25), e redes residenciais costumam bloquear a porta 25. Por isso, o e-commerce deve enviar sempre por um provedor de envio com autenticação, nunca por servidor próprio em conexão residencial (CERT.br, Gerência da Porta 25, documento de 2009). Terceiro, o descadastro fácil é também uma questão de respeito ao titular dos dados, no espírito da LGPD.
Para entender o papel do e-mail dentro da estratégia de relacionamento, leia o que é CRM Marketing e as métricas que mostram se o seu e-mail marketing funciona.
Checklist de entregabilidade
- Inventário de todas as ferramentas que enviam com o domínio da loja.
- SPF único, com no máximo 10 consultas DNS.
- DKIM ativo em cada serviço, com chave de 2048 bits e alinhado ao domínio da loja.
- DMARC publicado, com rua apontando para uma caixa monitorada.
- Cabeçalhos List-Unsubscribe e List-Unsubscribe-Post nas mensagens de marketing.
- Descadastro efetivado em até 48 horas, de preferência na hora.
- Domínio verificado no Google Postmaster Tools e painel sem itens em “Needs work”.
- Taxa de spam abaixo de 0,10%.
- DNS reverso (PTR) e TLS válidos no servidor de envio.
- Segmento sem interação há 90 dias com envio reduzido.
Perguntas frequentes
Pequenas lojas precisam seguir as regras de remetente em massa?
O requisito de DMARC, alinhamento e descadastro em um clique se aplica a quem envia 5.000 mensagens ou mais por dia ao Gmail. Mesmo abaixo disso, SPF ou DKIM, TLS e taxa de spam abaixo de 0,3% valem para todos. A Analytikos recomenda configurar tudo desde o início, porque o volume de envio tende a crescer com o tempo.
Posso começar com DMARC em p=reject?
Não é recomendável sem observação prévia. Comece com p=none e rua, analise os relatórios, corrija os remetentes legítimos que falham e endureça a política em etapas.
O que é alinhamento no DMARC?
É a coincidência entre o domínio do campo From e o domínio validado pelo SPF ou pelo DKIM. Basta um dos dois alinhar. O modo relaxado aceita o mesmo domínio organizacional; o estrito exige o nome idêntico.
Quanto tempo leva para o Postmaster Tools refletir uma correção?
Os dados têm atraso de cerca de 24 horas e usam média móvel de vários dias. A taxa de spam pode levar até 7 dias para cair. Mudanças de DNS aparecem conforme o painel observa novas mensagens.
E-mail transacional também precisa de descadastro em um clique?
Não. A exigência vale para mensagens de marketing e promocionais. Redefinição de senha e confirmação de pedido ficam fora, segundo o FAQ do Google.
A taxa de abertura ajuda a medir entregabilidade?
Pouco. A taxa de spam do Postmaster Tools, os erros de rejeição e o painel de conformidade são indicadores mais diretos. A abertura sofre interferência de recursos de privacidade dos clientes de e-mail.
O que fazer se a taxa de spam passou de 0,30%?
Reduza a frequência, envie apenas para quem interage e revise a origem da lista. Segundo o FAQ do Google, a elegibilidade para mitigação volta depois de 7 dias seguidos abaixo de 0,3%.
