Defaults.Exposed

Defaults.ExposedCorreçõesGuides

Emails do Mailchimp, Brevo ou Klaviyo a Falhar o DMARC? Ative a Autenticação Real do Domínio (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.

As plataformas de newsletter falham o DMARC quando enviam “from” o seu domínio sem se autenticarem como o seu domínio. A correção é a autenticação de domínio personalizado da plataforma — os seus CNAMEs de DKIM, mais um domínio de devolução personalizado onde for oferecido. A lacuna é normal: dos 740.321 domínios que autorizam o SendGrid, só 18,0% aplicam o DMARC, segundo o censo do Defaults.Exposed de 261.086.232 domínios (2026-06-29).

A correção são alguns registos DNS e dez minutos nas definições da sua plataforma. Abaixo: porque é que a autenticação partilhada da plataforma deixou de chegar em fevereiro de 2024, que interruptor ativar no Mailchimp, Brevo, Klaviyo e SendGrid, e os passos de correção por ordem — incluindo sair de um endereço From de correio gratuito, que nenhum registo DNS consegue salvar.

Porque é que os emails de newsletter falham o DMARC quando a plataforma diz que está tudo verificado?

Porque a plataforma autenticou-se a si própria, não a si. Por definição, um ESP envia as suas campanhas com o seu próprio domínio de devolução no Return-Path, e muitas vezes assina o DKIM também com o seu próprio domínio. Os recetores avaliam o SPF contra o domínio do Return-Path (RFC5321.MailFrom), não o cabeçalho From, portanto o SPF passa perfeitamente… para o domínio da plataforma.

O DMARC não quer saber se o SPF ou o DKIM passaram em abstrato. Pergunta se algum dos dois passou para o domínio no seu endereço From — essa correspondência chama-se alinhamento. O passe de SPF do ESP é no domínio de devolução dele, não no seu; sem DKIM de domínio personalizado, a assinatura dele está no domínio dele, não no seu. Nada alinha, portanto o seu domínio From falha o DMARC — enquanto o painel da plataforma mostra visto verde, porque, do ponto de vista dela, a autenticação está a funcionar. Ativar a autenticação de domínio personalizado (DKIM assinado como o seu domínio) é toda a correção. Para a mecânica completa do alinhamento, veja DMARC falha mas SPF e DKIM passam.

O que mudou em fevereiro de 2024?

A Google e a Yahoo começaram a aplicar requisitos para remetentes em massa: autenticação alinhada para o domínio From, uma política DMARC publicada, anulação de subscrição com um clique, e limites de taxa de spam. O atalho da infraestrutura partilhada — aproveitar a autenticação do ESP, enviar a partir de qualquer coisa — deixou de funcionar. Duas consequências para os remetentes de newsletter:

O conjunto completo de requisitos está no nosso artigo de dados sobre os requisitos da Google e da Yahoo para remetentes.

Como se chama o interruptor no Mailchimp, Brevo, Klaviyo e SendGrid?

Todas as plataformas têm a mesma funcionalidade com um nome diferente. O que produz sempre é um pequeno conjunto de registos CNAME para o seu DNS — é assim que a reconhece, seja qual for o nome no menu.

PlataformaNome da funcionalidade (aprox.)O que adiciona ao DNSNotas
MailchimpAutenticação de domínioCNAMEs de DKIM (k2._domainkey, k3._domainkey)Alinhamento só por DKIM — o Mailchimp já não usa um include de SPF; não adicione nenhum
BrevoAutentique o seu domínioConjunto de CNAME de DKIM + registo de verificaçãoVerifique o conjunto de registos atual na documentação do Brevo aquando da configuração
KlaviyoDomínio de envio dedicadoCNAMEs de DKIM + subdomínio de devolução (Return-Path)O domínio dedicado dá-lhe também alinhamento de SPF
SendGridAutenticação de domínio (segurança automatizada)Conjunto de CNAME (DKIM + return-path)Não precisa de include de SPF — os CNAMEs cobrem-no

Dois padrões que valem a pena notar. Primeiro, nenhuma destas plataformas quer um include: adicionado ao seu registo SPF — a autenticação moderna dos ESP é delegada por CNAME, e um include esquecido só gasta o orçamento de consultas de DNS. Segundo, a delegação por CNAME é uma funcionalidade: a plataforma roda as suas chaves DKIM por trás dos nomes delegados sem que tenha de voltar a tocar no DNS.

Como se corrigem as falhas de DMARC de newsletter, passo a passo?

  1. Execute a verificação gratuita em defaults.exposed antes de tocar no DNS. Mostra o estado real de SPF, DKIM e DMARC do seu domínio, para poder ver a lacuna de alinhamento que está prestes a fechar.
  2. Ative a autenticação de domínio personalizado na plataforma (tabela acima). Gera registos CNAME específicos da sua conta.
  3. Adicione os CNAMEs ao seu DNS exatamente como fornecidos. O erro clássico: painéis de DNS que acrescentam automaticamente a sua zona, transformando k2._domainkey.oseudominio.com em k2._domainkey.oseudominio.com.oseudominio.com. Cole apenas a parte do host se o seu painel acrescentar o domínio. Se a plataforma reportar depois “no key for signature”, o registo do seletor não chegou — veja DKIM “no key for signature”.
  4. Defina o domínio de devolução personalizado (Return-Path) onde a plataforma o oferecer. Isto alinha também a verificação de SPF, dando ao DMARC duas formas de passar. Onde não é oferecido (Mailchimp), o DKIM alinhado sozinho já é um passe completo de DMARC — uma verificação alinhada é tudo o que o DMARC exige.
  5. Mude o seu endereço From para o seu próprio domínio se ainda estiver em correio gratuito. [email protected], não [email protected]. Um requisito, não uma preferência.
  6. Verifique na plataforma, depois volte a verificar. Espere que a verificação da plataforma fique verde (o DNS pode demorar minutos a algumas horas), envie-se uma campanha a si próprio, e confirme que os cabeçalhos mostram o DKIM assinado pelo seu domínio. Depois percorra o resto que for assinalado na página corrigir o DMARC — se o seu domínio não tiver registo DMARC nenhum, é isso que faz nos próximos dez minutos.

Quantos remetentes de newsletter têm isto realmente certo?

O censo lê isto pelo lado do DNS: para cada plataforma, quantos domínios a autorizam — e quantos desses protegem o domínio que está a enviar, segundo o censo do Defaults.Exposed de 261.086.232 domínios (2026-06-29).

Plataforma (alvo SPF)Domínios que a autorizamDMARC aplicado
SendGrid (sendgrid.net)740.32118,0%
Mailgun (mailgun.org)1.306.69235,9%
Amazon SES (amazonses.com)551.44641,9%

Dados a 2026-06-29 do censo. “DMARC aplicado” = o domínio que autoriza publica p=quarantine ou p=reject.

Mesmo no topo da tabela, a maioria dos remetentes em plataformas profissionais deixa o domínio desprotegido: 41,9% dos 551.446 domínios que autorizam o Amazon SES aplicam o DMARC, 35,9% dos 1.306.692 do Mailgun — e só 18,0% dos 740.321 do SendGrid. A infraestrutura é profissional; a proteção do domínio, na maioria dos casos, não é. A tabela completa dos fornecedores — incluindo os alojamentos de caixas de correio — está em que fornecedor de email tem o SPF mais forte.

Perguntas frequentes

Preciso de adicionar o Mailchimp ao meu registo SPF? Não — e não o faça. O Mailchimp usa alinhamento só por DKIM através dos seus CNAMEs k2/k3 e já não publica um include de SPF para clientes. Um include:servers.mcsv.net antigo não faz nada pelo DMARC e desperdiça orçamento de consultas de DNS; a verificação alinhada aqui é o DKIM.

A autenticação de domínio vai tirar as minhas newsletters da pasta de spam? Remove a maior causa — correio não alinhado num domínio com uma política DMARC — e é um requisito rígido das regras da Google/Yahoo. Não vai corrigir problemas de qualidade da lista: taxas de reclamação altas e a falta de anulação de subscrição com um clique mantêm o correio em spam mesmo quando a autenticação é perfeita. Corrija primeiro a autenticação; é a parte com resposta certa.

Posso continuar a enviar campanhas a partir do meu endereço @gmail.com? Não. Os fornecedores de correio gratuito publicam políticas DMARC estritas precisamente para que mais ninguém consiga enviar como eles, e o seu ESP nunca conseguirá alinhar com gmail.com. Desde fevereiro de 2024 esse correio é rejeitado ou depositado em spam em massa. Um endereço From no seu próprio domínio é o único caminho.

Ativei a autenticação de domínio — porque é que o DMARC continua a falhar? Normalmente uma de três coisas: os CNAMEs foram estropiados por um painel de DNS que acrescenta a zona (passo 3), o domínio From da campanha não corresponde ao domínio que autenticou, ou uma origem de envio diferente está a falhar junto com a newsletter. Em todos os 261.086.232 domínios do censo de 2026-06-29, só 10,59% aplicam sequer o DMARC — se o seu aplica, está perto; volte a verificar e leia qual verificação não está alinhada.

Isto aplica-se a listas pequenas, abaixo de 5000 emails por dia? Os limiares mais rigorosos são formalmente para remetentes em massa, mas os recetores aplicam o básico da autenticação a todos, e os ESP agora exigem autenticação de domínio independentemente do volume. Trate-a como obrigatória: são alguns registos DNS, e evita que as suas campanhas quebrem no dia em que a sua lista crescer.

Envie o relatório ao proprietário

Se está a corrigir isto para um cliente — ou é dono da newsletter mas não do DNS — termine o trabalho com evidência. Volte a executar a verificação gratuita depois de os CNAMEs entrarem em vigor e reencaminhe o relatório classificado ao dono do negócio: linguagem simples, datado, alinhamento DMARC corrigido. É o artefacto que responde à renovação do seguro cibernético e ao próximo questionário de segurança de cliente — um antes-e-depois documentado, não “cliquei em uns botões no Mailchimp”.

Verifique o seu domínio → · DMARC falha mas SPF e DKIM passam → · Corrigir o DMARC → · Corrigir o DKIM → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.