Verificação de SPF, DKIM e DMARC
Três registros DNS dizem ao resto do mundo qual e-mail vem de verdade do seu domínio. Esta verificação os lê como um servidor de recebimento faz e traduz cada termo que encontra.
A linha do remetente de um e-mail não prova nada
O e-mail foi projetado como um envelope de papel. O remetente escreve o endereço de retorno e ninguém confere. Um servidor em qualquer país pode enviar uma mensagem cuja linha De (From) mostra o seu domínio. Três acréscimos posteriores fecham essa brecha, e os três ficam na sua zona DNS como registros TXT.
- SPF, no próprio domínio
- Uma lista dos servidores autorizados a enviar pelo domínio. O receptor compara o endereço IP que se conecta com a lista.
- DKIM, em
selector._domainkey - Uma chave pública. O serviço de envio assina cada mensagem com a chave privada correspondente, para que o receptor saiba que ninguém alterou a mensagem e qual domínio responde por ela.
- DMARC, em
_dmarc - A sua instrução para o e-mail que não passa em nenhum dos dois testes com o seu próprio nome de domínio: entregar, mandar para o spam ou recusar. Ele também indica uma caixa de correio para relatórios diários.
Desde fevereiro de 2024, o Gmail e o Yahoo recusam envios em massa de domínios sem esses registros, e a Microsoft fez o mesmo em 2025 no Outlook.com.
O que a verificação examina
Ela começa pelos seus registros MX, para reconhecer o provedor de e-mail (Google Workspace, Microsoft 365, Proton Mail, Fastmail e outros oito). A partir daí sabe qual include SPF e quais seletores DKIM esperar.
| Registro | Marcado como falha | Marcado como alerta |
|---|---|---|
| SPF | Nenhum registro num domínio que tem servidores de e-mail; dois registros; mais de 10 consultas DNS; um include que não tem SPF próprio ou que volta em loop; um termo escrito errado; +all; mais de duas consultas que não retornam nada | 8 a 10 consultas; ?all ou nenhum all; ptr; termos colocados depois de all; o seu provedor de e-mail ausente da lista |
| DKIM | Uma chave publicada que não pode ser usada: RSA com menos de 1024 bits, valor p= danificado, algoritmo desconhecido | Nenhuma chave em nenhum dos nomes testados; uma chave de 1024 bits; a marca de teste t=y |
| DMARC | Nenhum registro; dois registros; nenhum p= válido; um endereço de relatório ou valor de tag malformado | p=none; pct abaixo de 100; sp=none sob uma política mais rígida; relatórios enviados a outro domínio que não concordou em recebê-los |
As consultas são contadas através de todos os includes aninhados, e normalmente é aí que o limite de 10 é estourado sem ninguém perceber. Para um subdomínio, a busca do DMARC sobe até o domínio pai e aplica o valor sp= dele. O veredito geral é o pior dos três resultados. Três registros opcionais (MTA-STS, TLS-RPT, BIMI) só são informados como publicados ou não.
Um domínio cujo SPF inteiro é v=spf1 -all é tratado como um domínio que não envia nada. Nesse caso, a falta de chave DKIM é normal, e o DMARC sugerido é p=reject.
Como encontrar o seu seletor DKIM
As chaves DKIM não têm endereço fixo. Cada serviço de envio escolhe um rótulo, chamado seletor, e o DNS não oferece nenhum jeito de listá-los. A verificação testa umas três dezenas de nomes comuns, como google, selector1, k1 e s1. Então “nenhuma chave encontrada” muitas vezes só quer dizer que a sua tem outro nome.
- Envie uma mensagem do seu domínio para uma caixa de correio que você consiga abrir.
- Exiba o código-fonte bruto: “Mostrar original” no Gmail, “Exibir código-fonte da mensagem” no Outlook, “Visualizar > Mensagem > Todos os Cabeçalhos” no Apple Mail.
- Encontre a linha que começa com
DKIM-Signature:e leia duas tags.d=é o domínio que assina es=é o seletor.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mta2024; …
Aqui você digitaria mta2024 no campo do seletor. Se d= mostra o nome da sua plataforma de newsletter e não o seu domínio, a mensagem está assinada, mas não por você, e essa assinatura não conta para o DMARC. O nosso decodificador de cabeçalhos de e-mail lê essas linhas para você.
Como consertar numa ordem segura
Faça uma lista de tudo o que envia em nome do seu domínio: caixas de correio, plataforma de newsletter, loja virtual, central de atendimento, o formulário de contato do site. Coloque cada um num único registro SPF. Depois ative o DKIM em todo serviço que oferecer, já que o DKIM sobrevive ao encaminhamento e o SPF não.
Publique o DMARC com p=none e um endereço rua=, e leia os relatórios por algumas semanas com o leitor de relatórios DMARC. Quando todas as fontes legítimas passarem, mude para quarantine, depois para reject. O gerador de registros escreve os dois registros.
Esta verificação lê o DNS e nunca vê nenhuma das suas mensagens. Ela não consegue confirmar que um serviço assina de fato com a chave encontrada, nem que o domínio que assina bate com o seu endereço De (From). Para isso você precisa dos cabeçalhos de uma mensagem entregue.
Perguntas frequentes
Por que meus e-mails vão para o spam se SPF, DKIM e DMARC passam?
A autenticação prova quem enviou a mensagem. Ela não diz se as pessoas querem recebê-la. Os filtros também pesam a taxa de reclamações, a reputação do endereço IP e do domínio de envio, os links da mensagem e como os destinatários reagiram a e-mails anteriores. Comece por uma consulta de listas negras.
Um domínio pode ter dois registros SPF?
Não. Dois registros TXT que começam com v=spf1 geram um erro permanente e os receptores agem como se você não tivesse nenhum. Junte os dois num só v=spf1 com todos os termos include: e ip4: e um único all no fim.
O que significa “SPF PermError: too many DNS lookups”?
Processar o seu registro exigiu mais de 10 consultas DNS. Cada include, a, mx, exists e redirect custa uma, e os includes dentro de um include também contam. Remova serviços que você não usa mais, ou troque a e mx por endereços ip4: fixos, que não custam nada.
O SPF deve terminar com ~all ou -all?
Com o DMARC em vigor, os dois funcionam, porque é o DMARC que decide o que acontece com uma mensagem que falha. ~all é a escolha mais segura enquanto você ainda está descobrindo os remetentes. Nunca use +all, que autoriza qualquer servidor da internet.
p=none é suficiente para o Gmail e o Yahoo?
Sim, as regras deles para remetentes em massa aceitam p=none. Tudo o que isso lhe dá são relatórios, e o e-mail falsificado continua sendo entregue. A proteção começa em quarantine.
Preciso de DMARC num domínio que nunca envia e-mail?
É aí que ele é mais fácil e mais útil, porque um domínio estacionado é um disfarce cômodo para phishing. Publique v=spf1 -all no domínio e v=DMARC1; p=reject; em _dmarc.