Por que seus e-mails do Mailchimp caem no spam?

Você montou a campanha no Mailchimp, enviou para pessoas que se cadastraram para recebê-la, e a taxa de abertura veio pela metade do que costuma ser. Alguém responde dizendo que achou a mensagem na pasta de spam. Nada na campanha parece diferente da anterior, que funcionou.

O Mailchimp opera a infraestrutura de envio: os pools de IP, os feedback loops com os provedores de caixa de e-mail, os cabeçalhos de unsubscribe, o tratamento de bounces. O que ele não consegue é provar ao receptor que o e-mail é seu. Essa prova vive em registros DNS no seu domínio, e está ausente com muito mais frequência do que se imagina.

Três causas cobrem quase todos os casos.

Causa 1: o domínio nunca foi autenticado

Essa é a mais comum, e se esconde bem, porque o Mailchimp envia uma campanha sem hesitar para um domínio que nunca completou a autenticação.

Toda mensagem carrega dois endereços de remetente: o que o leitor vê no cabeçalho From:, e o remetente do envelope invisível, para onde os bounces voltam. Os receptores verificam o SPF no segundo e checam a assinatura DKIM separadamente. O DMARC então pergunta se algum desses checks aprovados pertence ao mesmo domínio do From: visível. Essa última pergunta se chama alinhamento, e é ela que decide tudo.

Veja como isso aparece nos cabeçalhos de uma mensagem entregue no Gmail. O domínio tem publicado um registro DMARC apenas com p=none, por isso o Gmail ecoa uma política de volta, e nenhuma autenticação do Mailchimp por trás:

Return-Path: <bounce-mc.us18_41205839.4913722-a1b2c3d4@mail105.suw11.rsgsv.net>
From: Ana <ana@example.com>
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce-mc.us18_41205839@mail105.suw11.rsgsv.net
         designates 198.2.128.1 as permitted sender)
       dkim=pass header.i=@mailchimpapp.net
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Dois checks passaram e o DMARC ainda assim falhou. O SPF passou para rsgsv.net, o DKIM passou para mailchimpapp.net, e nenhum dos dois é example.com. Pelo que o receptor vê, uma plataforma de envio em massa mandou uma mensagem em nome de um domínio que nunca a garantiu. É isso também que produz a linha “via mailchimpapp.net” que o Gmail coloca embaixo do nome do remetente, e que o Mailchimp documenta como a assinatura de um endereço From não autenticado.

A autenticação muda a linha do DKIM, e apenas a linha do DKIM. O Mailchimp mantém o remetente do envelope nos domínios dele, então o alinhamento por SPF não está disponível de forma alguma. Os registros que o Mailchimp entrega são dois CNAMEs e um TXT DMARC:

k2._domainkey.example.com.  CNAME  dkim2.mcsv.net.
k3._domainkey.example.com.  CNAME  dkim3.mcsv.net.
_dmarc.example.com.         TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Depois que os registros resolvem, dkim=pass header.i=@example.com substitui o domínio do Mailchimp, o DMARC passa só na perna do DKIM, e a linha “via” desaparece. O processo para colocar os registros na zona, incluindo os provedores que acrescentam o domínio ao hostname por você, está no guia de configuração do registro DKIM e no guia de configuração do registro DMARC.

Faça isto: envie uma campanha para você mesmo, cole os cabeçalhos brutos no analisador gratuito de cabeçalhos de e-mail e veja qual domínio a linha dkim=pass nomeia. Se for o Mailchimp, esse é o seu problema.

Causa 2: o endereço From está numa caixa de e-mail que não é sua

Criadores e pequenos negócios costumam disparar campanhas do endereço em que respondem mensagens, que com frequência é um endereço Gmail ou Yahoo.

O Mailchimp é direto sobre isso: serviços de e-mail públicos não podem ser autenticados. Não existe CNAME que você possa publicar sob gmail.com, porque o domínio não é seu. A assinatura sempre nomeará o Mailchimp, o DMARC nunca vai alinhar, e a mensagem não carrega nada que a ligue a você.

O tamanho do dano depende de qual serviço gratuito. Estas são as políticas que os dois maiores publicam, lidas em 10 de agosto de 2026:

_dmarc.gmail.com.  TXT  "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
_dmarc.yahoo.com.  TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ..."

Uma campanha com From em yahoo.com pede aos receptores que apliquem p=reject a ela, o que é uma rejeição, não uma pasta de spam. O gmail.com está em p=none hoje, então a mensagem não é rejeitada por política, e ainda chega sem nenhuma autenticação alinhada em um momento em que as próprias regras do Gmail para remetentes em volume pedem exatamente isso. Não vale enviar de nenhuma das duas.

A mesma armadilha pega quem usa um domínio autenticado em uma ferramenta e esquecido em outra. Autenticação é por plataforma. Um domínio autenticado para o Mailchimp não está autenticado para o e-mail transacional que sai por um serviço separado, e é por isso que os recibos caem na pasta de spam enquanto a newsletter chega bem. O post sobre Amazon SES cobre a metade transacional dessa divisão.

Faça isto: mova o endereço From da campanha para um domínio que você controla, e liste todas as outras ferramentas que enviam sob esse mesmo domínio. Cada uma precisa da própria assinatura.

Causa 3: a audiência e os números que realmente movem o resultado

Com a autenticação no lugar, onde a mensagem cai é decidido pela reação dos destinatários. Dois números carregam a maior parte do peso: quantas pessoas marcam a mensagem como spam e quantos endereços dão bounce.

O Mailchimp não publica um limite. As páginas de abuso e suspensão do Mailchimp citam “limites do setor” e notificações de advertência sem afirmar um número, então não existe linha para ficar logo abaixo. O Google publica uma. As diretrizes para remetentes do Gmail esperam que a taxa de spam reportada no Postmaster Tools fique abaixo de 0.1% e nunca chegue a 0.3%, e exigem SPF e DKIM, um registro DMARC alinhado e unsubscribe em um clique de quem envia mais de cerca de 5.000 mensagens por dia para contas Gmail pessoais. O Mailchimp fornece o cabeçalho de unsubscribe. O resto é do seu domínio, e o que Gmail e Yahoo realmente aplicam vale a leitura se a audiência for grande.

Os dois números vêm do mesmo lugar: como a audiência foi coletada. Uma planilha importada, uma lista comprada de qualquer um ou um formulário de cadastro sem etapa de confirmação vai gerar reclamações de pessoas que não lembram de você, e essas reclamações seguem o seu domínio para dentro de cada campanha futura. A reputação se recupera devagar, e ela se recupera pelo comportamento de envio, não por desculpas.

Faça isto: antes da próxima campanha, remova cada hard bounce, arquive os contatos sem aberturas ou cliques nos últimos seis meses e verifique de onde veio o segmento mais antigo da audiência.

Verificando a correção

Espere o TTL do DNS expirar, envie uma campanha para você mesmo e leia os cabeçalhos de novo. A linha dkim=pass deve nomear o seu domínio e dmarc=pass deve vir na sequência. A linha spf=pass ainda vai nomear um domínio do Mailchimp, e aqui isso é o esperado, não uma falha.

Depois leia os registros de volta do DNS público, em vez de ler no painel do Mailchimp. O health check gratuito de e-mail resolve seus registros SPF, DKIM, DMARC e MTA-STS como um receptor faria e confere o seu domínio contra blocklists na mesma passada, o que pega o caso de um registro colado com um erro de digitação no final enquanto o painel reporta um sucesso em cache.

Isso responde por um domínio, no momento em que você pergunta. E essa é a lacuna real.

Nada nessa configuração avisa quando ela quebra. Uma migração de DNS derruba os dois CNAMEs e o Mailchimp segue enviando, sem assinatura, sem erro. Um registro DMARC é substituído pelo assistente de configuração de outra ferramenta. Uma campanha para um segmento parado gera reclamações numa terça-feira que silenciosamente custam a caixa de entrada por semanas. Os relatórios da campanha continuam mostrando entrega, porque “delivered” significa que o receptor aceitou a mensagem, não que alguém a viu.

Fechar essa lacuna é o que o LitInboxes faz. Cada domínio monitorado é reavaliado a cada 6 horas em registros DNS, 8 blocklists de alto sinal em todos os planos e 24 no Pro, relatórios agregados de DMARC e reputação do Google Postmaster, com histórico datado para uma queda poder ser rastreada até o dia em que começou, e um alerta quando algo muda em vez de um lembrete para ir conferir. Alertas por e-mail estão em todos os planos; alertas por Slack, Discord e webhook estão no Pro. Há uma demo ao vivo se você quiser ver a tela primeiro.

Se o Mailchimp não for o problema, percorra o diagnóstico completo de spam, que segue as outras causas por ordem de probabilidade. Criadores e negócios de cursos costumam esbarrar nisso em um domínio que também roda uma plataforma de cursos, um agendador e um processador de pagamentos, cada um assinando os e-mails por conta própria.

O checklist

1. Envie uma campanha para você mesmo e leia os cabeçalhos brutos.
2. Veja qual domínio a linha dkim=pass nomeia. Mailchimp significa que o domínio não está autenticado.
3. Inicie a autenticação no Mailchimp e publique os dois registros CNAME que ele fornece.
4. Publique um registro DMARC em p=none com um endereço rua e leia o que chegar.
5. Mova o endereço From para um domínio que você controla se ele estiver em um serviço de caixa de e-mail gratuita.
6. Liste todas as outras plataformas que enviam sob esse domínio e autentique cada uma.
7. Remova hard bounces e contatos sem engajamento há seis meses.
8. Releia os cabeçalhos depois que o TTL expirar e confirme que a assinatura agora nomeia o seu domínio.