E-mails de phishing podem sair em nome do seu domínio sem você saber. SPF / DKIM / DMARC impedem isso. Veja o papel de cada um e como configurá-los com segurança.
O papel de cada um
| Configuração | Papel (em uma linha) |
|---|---|
| SPF | Declara no DNS quais servidores podem enviar por este domínio |
| DKIM | Adiciona uma assinatura criptográfica provando que o e-mail está inalterado e vem de uma fonte legítima |
| DMARC | Declara o que fazer se SPF/DKIM falharem e recebe relatórios (a configuração que une os três) |
Os três são registros de texto (TXT) no DNS. Para example.com, eles ficam assim (os valores são exemplos).
| Configuração | Onde fica | Valor de exemplo |
|---|---|---|
| SPF | example.com | v=spf1 include:_spf.mail-service.example ~all |
| DKIM | selector._domainkey.example.com | v=DKIM1; k=rsa; p=(chave pública emitida pelo seu serviço de envio) |
| DMARC | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
No include: do SPF, use o valor que o seu serviço de envio de e-mails indicar. A chave pública do DKIM também é emitida pelo serviço de envio, então você não precisa criá-la.
Como o e-mail é verificado
Os destinatários (Gmail, etc.) checam SPF e DKIM em uma mensagem recebida e então aplicam sua política DMARC para decidir "passar / quarentena / rejeitar".
Então SPF e DKIM sozinhos podem "checar mas não fazer nada"; só com uma política DMARC eles de fato "impedem o spoofing".
O ponto que passa despercebido: o alinhamento de domínios
A chave do veredito do DMARC é que os domínios coincidam. O DMARC só passa quando o domínio do remetente que o destinatário vê no aplicativo de e-mail (o cabeçalho From) coincide com um domínio verificado pelo SPF ou pelo DKIM.
O SPF não checa o remetente visível; ele checa o domínio do remetente de envelope, usado nos bastidores da entrega. Por isso, um atacante pode passar no SPF com o próprio domínio e escrever o seu domínio apenas no campo From.
Se o SPF passa mas não coincide com o domínio do From, e o DKIM também não fornece essa coincidência, o DMARC reprova a mensagem. É justamente essa checagem que permite ao DMARC barrar a falsificação do endereço From.
Como configurá-los com segurança
Um registro SPF correto
Autorize todo remetente legítimo (o seu próprio, serviços de e-mail, etc.). Mantenha um registro SPF por domínio (vários registros tendem a quebrá-lo).
Habilite a assinatura DKIM
Ative o DKIM na sua plataforma de e-mail e publique a chave pública no DNS, para que o e-mail legítimo seja assinado.
Comece o DMARC em p=none
Não rejeite de imediato. Comece com p=none (apenas monitorar) + relatórios para confirmar que e-mails legítimos não estão sendo descartados.
Aperte gradualmente
Quando os relatórios mostrarem que nenhum remetente legítimo está sendo perdido, avance p=quarantine → p=reject, alcançando por fim "o spoofing é rejeitado".
O "exatamente um" do passo 1 vem da especificação. A RFC 7208 diz que, se um domínio tiver mais de um registro SPF, o resultado é permerror (erro permanente). A mesma especificação limita a 10, em toda a avaliação, as consultas DNS geradas por include e termos parecidos; passar disso também dá permerror. Ao adicionar um serviço de e-mail, acrescente-o ao registro único existente em vez de criar outro.
Erros comuns
| Erro | O que acontece | Correção |
|---|---|---|
| Dois registros SPF | O SPF retorna permerror | Junte-os em um só |
includes aninhados demais | As consultas DNS passam de 10 → permerror | Remova os includes de serviços que você não usa |
| DKIM não habilitado em um serviço de envio | Os e-mails desse serviço falham no DMARC | Habilite o DKIM no serviço e publique-o no DNS |
| DMARC parado em p=none | E-mails forjados continuam passando | Leia os relatórios e suba até reject |
| Nada configurado num domínio que não envia e-mails | Não dá para barrar spoofing em nome desse domínio sem uso | Publique v=spf1 -all e DMARC p=reject |
Como verificar o seu próprio domínio
- Digite seu domínio no verificador de SPF / DKIM / DMARC para ver se os três registros existem e o que há de errado com eles
- Para olhar diretamente pela linha de comando, rode
dig +short TXT example.com(SPF) edig +short TXT _dmarc.example.com(DMARC) - Envie uma mensagem do seu domínio para um endereço do Gmail e use "Mostrar original" no Gmail para confirmar que
SPF,DKIMeDMARCindicamPASS - Quando os relatórios do DMARC (rua) começarem a chegar, verifique toda semana se há remetentes que você não reconhece
Para um site cuja propriedade você verificou, a auditoria de segurança do site checa esses registros junto com as configurações do lado web.
Um caso real: e-mail forjado "do seu próprio endereço"
"Recebi um e-mail ameaçador do meu próprio endereço para mim mesmo" é um caso típico sobre o qual a IPA do Japão e outros órgãos já alertaram. Na maioria das vezes não se trata de invasão da conta; o campo de remetente simplesmente foi reescrito. Como o remetente pode escrever qualquer coisa nesse campo, esse tipo de e-mail pode chegar à caixa de entrada em domínios que não elevaram o DMARC até reject. Como identificar e o que fazer está explicado aqui:
- Spam vindo do seu próprio endereço de e-mail (em inglês; confirme em cinco minutos se você foi invadido)
- E-mail forjado usando o seu próprio domínio (como ler os cabeçalhos e barrá-lo com SPF, DKIM e DMARC)
Atualização da especificação (maio de 2026)
O DMARC foi revisado em maio de 2026 como RFC 9989, que torna obsoleta a RFC 7489 anterior. As três políticas — p=none, p=quarantine e p=reject — não mudaram.
O que mudou: a tag pct (a porcentagem a aplicar) foi removida e substituída por uma tag t, que sinaliza modo de teste, e foi adicionada uma tag np para a política de subdomínios inexistentes. Os registros existentes não param de funcionar de uma hora para outra, mas não use pct ao escrever um novo.
A visão deste site: você também está protegendo seus usuários
SPF/DKIM/DMARC não é só sobre seus e-mails chegarem; também protege seus usuários do phishing que se passa pelo seu domínio. O phishing é, em última instância, uma forma de roubar credenciais e chaves.
Muitos domínios param no SPF/DKIM e nunca elevam o DMARC à imposição (reject). Não pare em p=none; leia os relatórios e suba até reject para que isso importe.
Fontes (primárias)
- IETF RFC 7208, "Sender Policy Framework (SPF)" (em inglês) — datatracker.ietf.org (um registro por domínio; no máximo 10 consultas DNS)
- IETF RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures" (em inglês) — datatracker.ietf.org
- IETF RFC 9989, "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)" (maio de 2026; torna obsoleta a RFC 7489) (em inglês) — datatracker.ietf.org
- Google, "Email sender guidelines" (em inglês) — support.google.com (requisitos a partir de 1º de fevereiro de 2024; requisitos para quem envia 5.000+ mensagens por dia)
Leia a seguir
- O que fazer: Como identificar e barrar e-mails forjados · Spam vindo do seu próprio endereço de e-mail (em inglês)
- Glossário: O que é phishing · O que é .env
- Ferramenta: Verificador de SPF / DKIM / DMARC