O DMARC é um tópico sobre o qual já se falou muito, mas a mesma pergunta ainda surge: as mesmas regras se aplicam quando a HubSpot está envolvida?
Em muitas configurações da HubSpot, os problemas de DMARC aparecem depois de uma mudança de domínio ou de uma queda no posicionamento da caixa de entrada, de modo que a primeira reação é culpar a HubSpot. O que realmente está acontecendo não é óbvio a princípio, e as respostas habituais que as pessoas procuram não explicam totalmente o problema.
Portanto, neste artigo, explicaremos como funciona o DMARC na HubSpot, por que ele causa tanta confusão e como deve ser o “funcionamento” em sua própria configuração. Vamos começar!
Principais conclusões
- O DMARC não corrige a capacidade de entrega por si só. Ele define regras, expõe os problemas do remetente e protege o seu domínio, mas não ajudará na colocação na caixa de entrada se a sua reputação e o seu envolvimento forem fracos.
- O posicionamento da caixa de entrada melhora quando a autenticação é combinada com o envolvimento. Quando SPF, DKIM e DMARC estão alinhados, o comportamento consistente do usuário é o que ajuda os provedores de caixa de correio a reconstruir a confiança no seu domínio.
O que é um registro DMARC da HubSpot?
DMARC (autenticação de mensagem baseada em domínio) é a regra que você publica no DNS do seu domínio, e os provedores de caixa de correio a utilizam para decidir o que fazer quando um e-mail não é autenticado como deveria.
A parte da HubSpot é mais simples. A HubSpot pode enviar e-mails de marketing sob o domínio da sua marca somente depois de provar, por meio de registros DNS, que você concedeu permissão. Quando isso acontece, o DMARC verifica se as mensagens que afirmam ser do seu domínio têm um caminho de autenticação válido que corresponda ao domínio mostrado no endereço De.
Essa correspondência é o ponto principal.
O DMARC não exige perfeição. Ele não exige que o SPF e o DKIM sejam aprovados sempre, mas exige que pelo menos um seja aprovado para o mesmo domínio que os destinatários veem. Se houver uma aprovação alinhada, o DMARC poderá ser aprovado. Se tanto o SPF quanto o DKIM falharem, o DMARC tratará a mensagem como não confiável, e sua política informará aos provedores o grau de rigor com que ela deve ser aplicada.
É por isso que “SPF aprovado” ainda pode levar a uma falha no DMARC e que o HubSpot pode parecer configurado corretamente enquanto o posicionamento da caixa de entrada vai lentamente para o lado.
Por que o DMARC falha mesmo quando o SPF ou o DKIM “passam”?
Há o domínio que as pessoas veem na linha De. Há as verificações de SPF do domínio (o lado do remetente do envelope/caminho de retorno da mensagem). E há o domínio que o DKIM usa para carimbar uma assinatura no e-mail. Em uma boa configuração, pelo menos uma dessas verificações nos bastidores corresponde ao domínio From. Em uma configuração confusa, elas não correspondem.
O DMARC faz uma pergunta simples: este e-mail corresponde ao domínio do qual você afirma ser? Se o SPF for aprovado, mas estiver vinculado a um domínio diferente do que está na linha De, o DMARC não será aprovado. O mesmo acontece se a autenticação DKIM assinar a mensagem, mas a assinatura pertencer a outro domínio. Uma aprovação incongruente ainda conta como uma falha.
É por isso que as dores de cabeça do DMARC da HubSpot geralmente apresentam um comportamento semelhante:
- Mensagens marcadas como parcialmente autenticadas
- Campanhas que oscilam entre a caixa de entrada e o spam sem nenhum motivo óbvio
- Relatórios DMARC mostrando remetentes que você nem sabia que ainda estavam ativos
E isso não é um caso extremo raro. É o que acontece quando um domínio coletou anos de ferramentas de ESPs antigos, CRMs esquecidos e sistemas transacionais aleatórios, e ninguém nunca voltou para limpar o rastro.
Como a HubSpot se encaixa nos protocolos de autenticação de e-mail
Quando você conecta um domínio de envio de e-mail na sua conta da HubSpot, você não está “ativando o DMARC“. Você está fazendo algo mais básico: dizendo ao mundo, por meio do DNS, que a HubSpot tem permissão para enviar como você.
A HubSpot conta com os mesmos blocos de construção de autenticação de e-mail que todos os principais remetentes. Eles são apenas armazenados em seu DNS, não dentro do editor de campanhas.
- O DKIM (DomainKeys Identified Mail) é configurado com dois registros CNAME para que a HubSpot possa adicionar uma assinatura válida às mensagens que envia para o seu domínio.
- SPF (Sender Policy Framework) é um registro TXT que lista quem tem permissão para enviar. A HubSpot precisa ser incluída nessa lista e mesclada ao seu registro existente, não adicionada como um registro separado.
- O DMARC (autenticação de mensagem baseada em domínio) é separado. Ele não “ajuda o HubSpot a enviar”. Ele verifica se o SPF ou o DKIM correspondem ao domínio no seu endereço De e, em seguida, aplica sua política quando isso não acontece.
É por essa separação que as pessoas ficam presas. A HubSpot pode passar no processo de verificação e ainda assim falhar no DMARC porque a falha diz respeito a como os registros do seu domínio funcionam como um todo, não apenas por meio da HubSpot.
Os suspeitos usuais quando se trata de configuração incorreta se resumem a isso:
- O SPF é dividido em vários registros, portanto, o SPF falha ou se torna não confiável
- Assinatura DKIM com um domínio diferente daquele que você está usando no campo From (De)
- O DMARC é definido como quarentena/rejeição antes que todos os remetentes legítimos sejam configurados corretamente.
Quando você traça uma linha clara entre “o que a HubSpot envia” e “o que o seu DNS reivindica”, a depuração fica muito menos complicada.
Escolhendo uma política DMARC sem prejudicar o desempenho do e-mail
As políticas DMARC são fáceis de listar, mas difíceis de usar corretamente, e podem facilmente se tornar uma armadilha se você não souber o que está fazendo.
- p=none está monitorando. Ele coleta relatórios e, na maioria das vezes, fica fora do caminho.
- p=quarentena penaliza as falhas, normalmente encaminhando-as para spam.
- p=reject faz o que parece fazer. Ele rejeita totalmente o e-mail.
O grande erro é adotar a aplicação antes de você saber quem está enviando e-mails como seu domínio. A HubSpot pode estar bem, mas algum sistema esquecido, como um CRM antigo, ainda pode estar usando o mesmo domínio.
Há também configurações menores de DNS que afetam o rigor do DMARC, como modo de alinhamento, subdomínios e porcentagem de implementação. Se essas configurações estiverem incorretas, o DMARC bloqueará e-mails que pareçam não confiáveis, mesmo que não sejam.
Os erros de DNS que fazem a HubSpot parecer culpada
A maioria dos problemas que as pessoas rotulam como “problemas de DMARC da HubSpot” não começa na HubSpot. Eles começam no DNS e em suas configurações de domínio mais amplas. A HubSpot é o remetente que você percebe quando a entrega falha.
Um dos erros mais comuns é colocar o registro DMARC no local errado. O DMARC só funciona quando é publicado no host _dmarc do domínio do qual você está enviando. Se você o colocar no domínio raiz ou anexá-lo à conexão de domínio errada, os provedores de caixa de correio não o verão da maneira que você espera.
O SPF causa problemas com a mesma frequência. Um domínio deve ter um registro SPF da HubSpot. Quando ele é dividido em vários registros, geralmente após adicionar outra ferramenta ou fazer uma alteração rápida, o SPF para de validar de forma previsível. Isso cria problemas de alinhamento, e o DMARC reage de acordo.
O histórico do domínio é outro fator importante. Os domínios que passaram por vários ESPs, CRMs ou serviços transacionais tendem a acumular sobras de inclusões SPF e remetentes parcialmente removidos. Esses itens não são totalmente problemáticos, mas atrapalham o sinal e podem aparecer posteriormente como fontes inesperadas nos dados do DMARC.
Alguns provedores de DNS alteram a forma como os registros são resolvidos, especialmente para CNAMEs, e isso pode interferir nas configurações de DKIM que dependem de uma resolução direta.
Nenhuma dessas alterações é importante para um registro DMARC, e é exatamente por isso que elas são ignoradas. Mas elas são mais do que suficientes para causar falhas de autenticação, mesmo quando o HubSpot está configurado corretamente.
Relatórios DMARC: a única maneira confiável de ver o que está acontecendo
Os relatórios DMARC são a coisa mais próxima que você terá de uma resposta direta. Sem eles, você estará adivinhando com base em alguns e-mails de teste, um painel de aprovação/reprovação ou o que quer que uma ferramenta de verificação decida mostrar a você naquele dia.
Esses relatórios informam a você quem está enviando e-mails como seu domínio, de quais endereços IP essas mensagens se originam e se o SPF ou o DKIM estão sendo aprovados com alinhamento. Essa última parte é importante. É assim que você descobre as surpresas usuais quando uma ferramenta de sistema antiga que você esqueceu de desligar ou um e-mail que tecnicamente “passa”, mas ainda falha no DMARC.
Os relatórios agregados são a verdadeira matéria-prima aqui. Eles vêm em lotes e parecem confusos no início, mas são excelentes para mostrar a você padrões ao longo do tempo:
- Remetentes que você espera e aqueles que não espera
- IPs que continuam falhando no alinhamento
- Caminhos de autenticação que parecem bons, mas não passam no DMARC
Existem relatórios forenses, mas a maioria das pessoas os evita. O suporte varia de acordo com o provedor; a privacidade é uma preocupação comum, e eles raramente oferecem algo além do que os relatórios agregados já fornecem. Na maioria das configurações da HubSpot, os dados agregados são suficientes para passar de suposições a fatos utilizáveis.
DMARC versus engajamento: O que ajuda no posicionamento da caixa de entrada?
O DMARC ajuda os provedores de caixas de correio a determinar se um e-mail tem permissão para ser entregue. É isso aí. Ele não decide onde vai parar.
Depois que uma mensagem é aceita, os provedores de caixa de entrada e os filtros de spam monitoram como os destinatários respondem a ela. Eles a abrem ou a ignoram? Você a lê ou a exclui imediatamente? Você a marca como spam ou a retira da pasta de spam? Qualquer que seja o engajamento, ele se acumula ao longo do tempo e determina o grau de confiança que um domínio conquista.
Essa diferença entre “aceito” e “confiável” é onde o InboxAlly pode ajudar. Quando um domínio precisa se recuperar, ou quando um novo domínio precisa de um bom começo, o InboxAlly usa contas-semente que simulam usuários reais abrindo e-mails, percorrendo-os, clicando em links e respondendo.
Quando esse tipo de atividade dá suporte a uma configuração devidamente autenticada, você fornece aos filtros da caixa de entrada dados melhores para trabalhar. Com o tempo, isso os ajuda a entender seus padrões de envio e a tratar seus e-mails como e-mails legítimos.
Se tudo isso soa familiar e você está lutando contra o posicionamento na caixa de entrada, agende uma demonstração gratuita do InboxAlly e veja como ele se ajusta à sua configuração de alcance de e-mail.
Resumo
Obrigado a você por ler.
Se há algo que você deve levar em consideração, é isso: O DMARC não é um atalho que você queira usar. Quando os métodos de autenticação são configurados corretamente, tudo o mais se torna mais fácil de diagnosticar e melhorar.
Dedique um tempo para você acertar o básico. Use relatórios para ver o que realmente está acontecendo. Preste atenção em como os provedores de caixa de entrada respondem ao longo do tempo, e não apenas se uma verificação “passa”.
Você não precisa de perfeição no primeiro dia. Você precisa progredir na ordem certa. Primeiro, uma configuração limpa. Em seguida, sinais reais. O resto vem depois.