SPF, DKIM e DMARC: como configurar o domínio e reduzir o risco de o e-mail da loja cair no spam

DMARC: o que fazer quando a prova falha

O DMARC diz ao servidor de destino como tratar a mensagem que não passa no SPF nem no DKIM. A página “Configurar o DMARC” descreve três opções de política: entregar normalmente (none), mandar para o spam (quarantine) ou rejeitar (reject). O DMARC também pode enviar relatórios ao dono do domínio, que mostram quem está enviando e-mail em nome dele.

Há um detalhe que explica muitos casos de falha: o alinhamento. Pela mesma página, a mensagem só passa no DMARC se o domínio do campo “De:” corresponder ao domínio autenticado pelo SPF ou pelo DKIM. Basta um dos dois. Uma mensagem assinada pela ferramenta de e-mail marketing com o domínio da própria ferramenta, e não com o da loja, pode passar no DKIM e ainda assim falhar no DMARC.

Antes de configurar: quem envia e-mail em nome da loja

Na avaliação do ConnectWeek, um erro frequente é esquecer um remetente. A página do SPF manda identificar todos os serviços que enviam e-mail pelo domínio antes de escrever o registro. Em uma loja virtual, a lista costuma ter mais nomes do que parece:

• o serviço de e-mail da equipe, usado no atendimento;
• a plataforma da loja, que envia confirmação de pedido e aviso de envio;
• a ferramenta de e-mail marketing, que envia campanhas e os fluxos automáticos, como o de carrinho abandonado;
• o sistema de atendimento ao cliente, quando responde chamados por e-mail;
• o sistema de gestão, quando envia nota ou boleto bancário por e-mail;
• formulários do site que disparam mensagens automáticas.

Em geral, cada fornecedor informa na ajuda ou no painel os valores de SPF e de DKIM que a loja deve publicar. Vale reunir esses valores em um único documento antes de abrir o painel do domínio.

A ordem de configuração, passo a passo

Nas páginas do Google, os três registros são do tipo TXT, um campo de texto do DNS. Eles são criados no painel da empresa onde o domínio foi registrado ou onde o DNS é administrado. A tabela resume o que cada um leva, conforme as três páginas de configuração do Google.

1. Publicar o SPF. O registro começa com v=spf1, traz um include: para cada serviço de envio e termina com ~all, a marcação que o Google recomenda. O exemplo da página para quem só usa o Google Workspace é v=spf1 include:_spf.google.com ~all. A página informa que o registro aceita até 10 marcações include:.
2. Ativar o DKIM em cada serviço. Cada ferramenta gera a sua chave e informa o nome, o tipo e o valor do registro a criar. A loja copia esses dados para o DNS e volta à ferramenta para concluir a ativação.
3. Esperar. As páginas do Google informam que SPF e DKIM podem levar até 48 horas para começar a funcionar. A página do DMARC pede que os dois autentiquem mensagens por pelo menos 48 horas antes de o DMARC ser publicado.
4. Criar uma caixa de e-mail para os relatórios. O Google recomenda um endereço ou grupo dedicado, porque o volume de relatórios do DMARC pode ser grande.
5. Publicar o DMARC em modo de observação. A recomendação da página é começar com a política none, que não bloqueia nada e só gera relatórios. Um registro inicial tem este formato: v=DMARC1; p=none; rua=mailto:dmarc@sualoja.com.br. O endereço depois de rua= é a caixa criada no passo anterior.
6. Ler os relatórios e tornar a política mais rígida. Quando os relatórios mostrarem que todos os serviços da loja passam na autenticação, a política pode mudar para quarantine e, mais tarde, para reject. A página do Google recomenda mudar a política com o tempo para quarantine ou reject e descreve a marcação pct, que aplica a política a apenas uma parte das mensagens no começo.

Quem usa subdomínio para enviar e-mail, como news.sualoja.com.br, precisa de um registro de SPF para cada subdomínio, segundo a página do SPF.

Como testar se a configuração funcionou

O teste mais simples usa uma conta do Gmail. A loja envia uma mensagem de cada serviço para essa conta: um e-mail da equipe, uma confirmação de pedido de teste e uma campanha. No Gmail, ao lado do botão “Responder”, o menu “Mais” tem a opção “Mostrar original”. A tela que abre exibe o resultado de SPF, DKIM e DMARC. A página do DKIM orienta a procurar a linha Authentication-Results no cabeçalho, a parte técnica da mensagem, que deve trazer algo como DKIM=pass.

O teste precisa ser repetido para cada serviço da lista de quem envia e-mail em nome da loja. Pode acontecer de o e-mail da equipe passar e a confirmação de pedido falhar, porque a plataforma da loja ficou fora do SPF ou sem DKIM próprio.

Depois do teste, o acompanhamento passa para o Postmaster Tools, onde a loja cadastra o domínio e acompanha a taxa de spam.

O que a autenticação não resolve

SPF, DKIM e DMARC provam a origem da mensagem. Eles não garantem a caixa de entrada. As diretrizes do Google tratam de outros fatores: enviar apenas para quem pediu para receber, oferecer um jeito fácil de cancelar a inscrição e manter baixa a taxa de reclamação. Uma lista comprada continua gerando reclamações de spam mesmo com os três registros corretos.

A manutenção também conta. A página do SPF lembra que o registro precisa ser atualizado quando a loja troca de ferramenta de envio. Sem isso, as mensagens do serviço novo podem ser marcadas como spam. O cuidado vale sobretudo para as mensagens ligadas ao pedido, que o cliente espera receber. Elas estão descritas no artigo sobre o fluxo de mensagens do pós-venda.