Esta ferramenta é executada no servidor
Como funciona
O protocolo de e-mail não verifica quem envia: qualquer servidor pode colocar seu domínio no remetente. Três registros DNS fecham essa porta. O SPF lista quais servidores podem enviar em nome do domínio. O DKIM assina cada mensagem com uma chave privada cuja parte pública é publicada no DNS. O DMARC une os dois: exige que pelo menos um passe e coincida com o domínio visível do remetente, diz ao receptor o que fazer com o que falha e pede relatórios de tudo o que foi enviado com seu nome.
Desde fevereiro de 2024, Gmail e Yahoo exigem SPF, DKIM e DMARC de quem envia mais de 5.000 mensagens por dia aos seus usuários, e a falta de qualquer um deles se traduz em e-mails rejeitados ou na pasta de spam. Por isso vale revisar os três juntos: um SPF impecável adianta pouco sem DMARC, e um DMARC em reject com um DKIM mal publicado bloqueia seu próprio e-mail.
A verificação é feita a partir do nosso servidor com consultas DNS públicas, como faria qualquer servidor de e-mail. O SPF é avaliado por completo, seguindo cada include e redirect para contar as consultas DNS, porque passar do limite de 10 anula o registro inteiro. Também são consultados os registros MX e os opcionais MTA-STS, TLS-RPT e BIMI.
Exemplos
github.comSPF · 10 / 10Oito includes de provedores (Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…) e os que eles incluem levam a avaliação exatamente ao limite de 10 consultas DNS. Mais um provedor e o SPF inteiro passaria a dar erro permanente.example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sA configuração correta para um domínio que não envia nem recebe e-mail: MX nulo, SPF que não autoriza ninguém e DMARC em reject. Protege os domínios estacionados, que são um alvo comum de falsificação.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %Uma implantação gradual: só uma em cada quatro mensagens que falham vai para o spam, e os relatórios chegam à caixa indicada em rua para detectar remetentes legítimos ainda não autenticados.Casos de uso
- Diagnosticar por que os e-mails do domínio caem no spam ou são rejeitados pelo Gmail, Outlook ou Yahoo.
- Verificar que o SPF não passe de 10 consultas DNS antes de adicionar um novo provedor de envios, como um CRM ou uma plataforma de newsletters.
- Verificar se a chave DKIM de um provedor ficou bem publicada depois de configurá-la.
- Planejar a passagem do DMARC de none para quarantine e para reject sem cortar o e-mail legítimo.
- Auditar os domínios de um cliente ou de uma empresa adquirida, incluindo os estacionados que não deveriam enviar e-mail.
- Revisar a configuração de um remetente suspeito durante a análise de um phishing.
Perguntas frequentes
Por que diz que não encontrou DKIM se meu domínio assina os e-mails?
Porque o DKIM não permite listar as chaves de um domínio: cada uma fica em <seletor>._domainkey.<domínio> e é preciso conhecer o seletor para consultá-la. A ferramenta testa os seletores mais usados, mas muitos provedores usam nomes próprios ou com data. Abra um e-mail enviado pelo domínio, procure o cabeçalho DKIM-Signature e copie o valor de s=; com esse seletor a verificação é exata.
O que acontece se o SPF passar de 10 consultas DNS?
A RFC 7208 obriga o receptor a devolver um erro permanente (permerror), e para o DMARC isso conta como falha do SPF. Consomem consultas os mecanismos include, a, mx, ptr e exists e o modificador redirect, incluindo os que aparecem dentro de cada include; ip4 e ip6 não consomem. Para reduzir o número, remova provedores que não são mais usados, substitua includes por faixas ip4 ou envie a partir de subdomínios com SPF próprio.
~all ou -all?
Com DMARC ativo a diferença é pequena: o receptor aplica a política DMARC e não o qualificador do SPF. ~all é o habitual porque alguns receptores rejeitam na hora com -all antes de avaliar o DKIM, o que pode fazer perder e-mails reencaminhados que o DKIM teria salvado. Sem DMARC, -all é a única forma de pedir que o não autorizado seja rejeitado.
Como passo o DMARC de none para reject sem perder e-mail?
Comece em p=none com um endereço em rua e leia os relatórios agregados por algumas semanas: eles mostram cada servidor que envia com seu domínio e se passa em SPF ou DKIM. Autentique os remetentes legítimos que faltarem, passe para quarantine com pct baixo, suba o pct aos poucos e termine em reject. O salto direto para reject costuma bloquear sistemas de faturamento, CRMs ou sistemas internos de que ninguém se lembrava.
Uma chave DKIM de 1024 bits é suficiente?
Funciona, porque a RFC 8301 exige que os receptores aceitem chaves de 1024 a 4096 bits, mas a mesma norma recomenda que quem assina use pelo menos 2048. Chaves abaixo de 1024 não são consideradas válidas. Trocar para 2048 é simples: publica-se a chave nova com outro seletor, muda-se a assinatura e depois se revoga a antiga deixando p vazio.
Para que servem MTA-STS, TLS-RPT e BIMI?
O MTA-STS (RFC 8461) pede aos servidores que enviam que exijam TLS ao entregar nos seus MX, o que evita ataques que rebaixam a conexão para texto puro. O TLS-RPT (RFC 8460) envia relatórios quando essas entregas falham. O BIMI mostra o logotipo da marca ao lado do remetente nos clientes que o suportam, e só funciona com DMARC em quarantine ou reject. Nenhum é obrigatório, mas os três somam.