SPF, DKIM e DMARC para provedor de internet: o que são e como configurar

Quando o sistema de gestão dispara o boleto, a primeira pergunta que o Gmail, o Outlook ou o servidor da empresa do cliente faz é: quem garante que isso veio mesmo do provedor? A resposta mora em três registros públicos no DNS, o serviço que traduz o nome do seu domínio em endereços e guarda outras informações sobre ele.

SPF (Sender Policy Framework) é a lista de quem pode mandar e-mail em nome do seu domínio. O destino confere se o servidor que entregou a mensagem está nessa lista. É a RFC 7208.

DKIM (DomainKeys Identified Mail) é uma assinatura digital. O servidor de envio assina cabeçalho e corpo com uma chave privada, e a chave pública fica no DNS. Se alguém alterar a mensagem no caminho, ou assinar sem ter a chave, a conferência falha. É a RFC 6376.

DMARC (Domain-based Message Authentication, Reporting and Conformance) amarra os dois. Diz ao destino o que fazer quando SPF e DKIM falham (nada, quarentena ou rejeição) e para onde enviar relatórios sobre quem anda usando o seu domínio. É a RFC 7489.

Desde 1º de fevereiro de 2024, o Google exige SPF ou DKIM de qualquer remetente. De quem manda cerca de 5.000 mensagens ou mais por dia para contas do Gmail, exige SPF e DKIM, DMARC (pode ser p=none) e remetente alinhado. O Yahoo publicou exigências equivalentes na mesma data. A Microsoft aplica regras parecidas no Outlook.com e no Hotmail desde 5 de maio de 2025.

O SPF é um registro do tipo TXT (texto) no domínio raiz: o próprio provedor.com.br, sem nada na frente. Um exemplo genérico:

v=spf1 include:spf.servico-de-envio.com.br ~all

v=spf1 identifica o registro. include: puxa a lista de servidores do serviço que envia por você. ~all diz que quem não está na lista provavelmente não é autorizado (softfail); a versão -all é mais dura (fail). O Google recomenda ~all.

Duas regras da RFC 7208 derrubam muita gente. Um domínio só pode ter um registro SPF: com dois, o resultado é permerror (erro permanente) e o SPF deixa de passar para todo mundo. Se já existe SPF do e-mail corporativo, acrescente o include dentro dele. E a avaliação do SPF não pode passar de 10 consultas de DNS (contam include, a, mx, ptr, exists e redirect); passou de 10, permerror de novo.

O serviço de envio gera um par de chaves, guarda a privada e entrega a pública para você publicar como TXT em seletor._domainkey.provedor.com.br. O seletor é um apelido que permite ter várias chaves ao mesmo tempo e aparece na assinatura (etiqueta s=) junto com o domínio que assinou (etiqueta d=).

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

v=DKIM1 é a versão, k=rsa o tipo de chave e p= a chave pública, uma sequência longa de letras e números. A RFC 8301, que atualizou a DKIM, proíbe chaves menores que 1.024 bits e recomenda 2.048. O erro mais comum é colar a chave com quebra de linha ou espaço no meio: o registro fica inválido e a assinatura falha em todo e-mail.

O DMARC é um TXT em _dmarc.provedor.com.br:

v=DMARC1; p=none; rua=mailto:dmarc@provedor.com.br

p= é a política: none (só observe), quarantine (trate como suspeito; em geral vai para a pasta de spam) ou reject (recuse na entrega). rua= é o endereço que recebe os relatórios agregados: um resumo, em geral diário, de quais servidores enviaram em nome do seu domínio e se passaram.

Comece em p=none. Não é frouxidão, é medição: nada muda na entrega, e em uma semana você descobre quais sistemas mandam e-mail com o seu domínio, inclusive os que ninguém lembrava (portal do cliente, monitoramento da rede). A orientação do Google é ficar em none por pelo menos uma semana, subir para quarantine numa fatia pequena das mensagens (o exemplo do Google usa pct=5) e só chegar a reject com os relatórios limpos. A Microsoft recomenda o mesmo caminho. Publicar reject de cara é a forma mais rápida de bloquear o próprio boleto.

Passar no SPF e no DKIM não basta para o DMARC. O domínio que passou precisa ser o mesmo que aparece no campo De (From), o que o cliente vê. A RFC 7489 chama isso de alinhamento. No modo padrão, relaxado, basta o domínio principal ser o mesmo (cobranca.provedor.com.br alinha com provedor.com.br); no estrito, tem que ser idêntico.

Por isso um provedor não pode disparar boletos com remetente @gmail.com ou @hotmail.com. Você não controla o DNS do gmail.com, não publica SPF nem DKIM lá, e o Google manda não usar De do Gmail fora dos servidores dele, avisando que isso afeta a entrega. O De precisa alinhar com o domínio do SPF ou com o do DKIM; basta um dos dois, mas um precisa.

O alinhamento por DKIM é o mais fácil: a assinatura leva d=provedor.com.br e o De é @provedor.com.br. O alinhamento por SPF depende do endereço de retorno (o envelope, invisível para o cliente) estar no seu domínio, o que exige um registro extra apontando para o serviço de envio.

O que mais aparece quando um provedor confere o DNS pela primeira vez:

• Dois registros SPF no mesmo domínio: permerror, e o SPF não vale para ninguém.
• SPF com mais de 10 consultas de DNS, em geral por acumular includes de serviços antigos.
• Esquecer o include do serviço que dispara os boletos: o SPF existe, mas não autoriza quem envia.
• DKIM assinado com o domínio do serviço, e não com o seu: a assinatura passa, mas não alinha, e o DMARC falha.
• Chave DKIM colada com quebra de linha, ou seletor errado no nome do registro.
• DMARC em reject sem ter olhado os relatórios em none.
• Remetente em domínio gratuito (@gmail.com, @hotmail.com) no campo De.

O teste mais honesto é mandar um boleto real para uma conta sua no Gmail. Abra a mensagem, clique nos três pontos ao lado de Responder e em "Mostrar original". No topo aparece um resumo com SPF, DKIM e DMARC. Mais abaixo, na linha Authentication-Results, o que você quer ver é spf=pass, dkim=pass e dmarc=pass, com header.d= e header.from= no seu domínio.

Se dkim=pass mas dmarc=fail, é alinhamento: o header.d= está no domínio de outra empresa. Se spf=permerror, procure registro duplicado ou excesso de consultas. Se aparece none em vez de pass, faltou o registro ou a assinatura: espere a propagação do DNS (minutos a algumas horas) e confira o nome exato.

Para olhar o DNS de fora, o Google Admin Toolbox (toolbox.googleapps.com/apps/checkmx) checa SPF e, informando o seletor, o DKIM. Se o boleto já está sumindo, o guia Boleto caindo no spam: causas e como resolver mostra por onde começar o diagnóstico.

Ao cadastrar o domínio em app.sendmix.net, o painel lista os registros exatos para publicar, cada um com nome, tipo e valor: a verificação de propriedade, o SPF com o include correto (com o aviso de somar ao registro existente), a chave DKIM de 2.048 bits gerada só para o seu domínio, um CNAME opcional (um apelido no DNS) que alinha o endereço de retorno, e um DMARC sugerido em p=none.

Publicou, clica em Verificar. O painel consulta o DNS público e mostra o estado de cada registro. Depois a checagem se repete sozinha: se um registro some (troca de DNS, migração de site, alguém "limpando" a zona), o domínio passa para o estado degradado e o painel avisa antes de você descobrir pelo cliente. O painel também recusa remetente em domínio gratuito no campo De, porque não há como alinhar; o endereço do Gmail pode ir como Responder para.

O que nenhum registro faz é garantir caixa de entrada, e desconfie de quem garantir. SPF, DKIM e DMARC dizem ao destino que a mensagem é legítima; onde colocá-la continua sendo decisão do Gmail, do Outlook ou do servidor da empresa. Por isso o SendMix guarda, por mensagem, a resposta do destino: quando o cliente diz que não recebeu o boleto, você vê se foi aceito, adiado ou recusado, e com qual motivo.