SPF, DKIM e DMARC explicados: impeça falsificações e chegue à caixa de entrada

• O SPF lista os servidores autorizados a enviar e-mails pelo seu domínio.
• O DKIM assina cada mensagem; a chave pública para verificá-la fica publicada no DNS.
• O DMARC diz aos destinatários o que fazer quando SPF e DKIM falham e envia relatórios para você. Ele só passa quando o domínio do endereço De visível corresponde.
• Comece com p=none, leia os relatórios e passe para quarantine e reject quando todos os remetentes legítimos passarem.

Desde fevereiro de 2024, Gmail e Yahoo exigem SPF ou DKIM de todos os remetentes. Remetentes em massa (para o Google, mais de 5.000 mensagens por dia para endereços Gmail) precisam de SPF, DKIM e um registro DMARC (p=none basta), domínio De alinhado com SPF ou DKIM, cancelamento de inscrição com um clique em e-mails de marketing e taxa de denúncias de spam abaixo de 0,3%.

Mesmo que você envie pouco, a falta de registros torna o seu domínio fácil de falsificar em golpes de phishing, e os destinatários confiam menos em e-mails desses domínios.

O SPF é um único registro TXT no seu domínio que começa com v=spf1, lista os remetentes permitidos e termina com uma regra para todos os demais. include: incorpora a lista de um provedor, ip4:/ip6: adicionam seus próprios servidores e mx autoriza os servidores MX do domínio.

• Publique exatamente um registro SPF. Dois registros v=spf1 fazem o SPF falhar (permerror); junte-os em um só.
• O SPF pode fazer no máximo 10 consultas DNS (cada include, a, mx, exists e redirect conta, inclusive os aninhados). Acima disso o SPF falha; remova os include que não usa mais.
• -all (fail) pede que remetentes não listados sejam rejeitados, ~all (softfail) que sejam tratados como suspeitos. Com DMARC, ~all é comum e seguro.
• O SPF verifica o remetente do envelope (Return-Path), não o endereço De que as pessoas veem, e quebra quando o e-mail é encaminhado. Por isso você também precisa do DKIM.

O servidor de envio assina os cabeçalhos e o corpo com uma chave privada; o destinatário busca a chave pública em seletor._domainkey.example.com e verifica a assinatura. O seletor é um nome escolhido pelo provedor (google, selector1, s1, k1…), de modo que cada serviço tem a sua chave.

Ative o DKIM em cada serviço pelo qual você envia (provedor de e-mail, ferramenta de newsletter, CRM, loja virtual) e publique o registro indicado, geralmente um TXT ou CNAME. Use chaves de 2048 bits quando houver opção. O DKIM sobrevive ao encaminhamento, o que o torna a metade mais confiável para o DMARC.

O DMARC fica em _dmarc.example.com. Uma mensagem passa no DMARC quando SPF ou DKIM passa e o domínio verificado corresponde (está alinhado) ao domínio do endereço De. Um provedor que assina com o próprio domínio não ajuda até você configurar o DKIM para o seu.

rua=mailto: pede aos destinatários relatórios agregados diários (XML) com os servidores que enviaram e-mails como o seu domínio e se passaram. É com esses relatórios que você encontra remetentes esquecidos antes de endurecer a política.

• Liste tudo o que envia e-mails como o seu domínio: caixas postais, formulários do site, newsletter, faturamento, central de suporte.
• Publique um único registro SPF que cubra todos e ative o DKIM em cada um deles.
• Adicione v=DMARC1; p=none; rua=mailto:… e leia os relatórios por duas a quatro semanas.
• Corrija cada remetente legítimo que falhar, depois mude para p=quarantine (aos poucos com pct=, se preferir) e mais tarde para p=reject.
• Domínios que nunca enviam e-mails devem publicar v=spf1 -all e v=DMARC1; p=reject para que ninguém consiga falsificá-los.

• MTA-STS e TLS-RPT fazem os outros servidores entregarem e-mails a você apenas por TLS verificado e relatarem problemas.
• O BIMI mostra o seu logotipo ao lado das mensagens nas caixas de entrada compatíveis; ele exige DMARC em quarantine ou reject.

A verificação de segurança de e-mail lê MX, SPF (com a contagem de consultas DNS), DKIM para seletores comuns ou o seu, DMARC, MTA-STS, TLS-RPT e BIMI, e aponta os problemas encontrados. Execute-a de novo após cada alteração no DNS; dependendo do TTL, os novos registros levam de alguns minutos a uma hora para aparecer.