A autenticação de email com SPF, DKIM e DMARC passou a ser uma tarefa essencial. Se o seu domínio envia emails empresariais em 2025 ou 2026, esses registros influenciam o tratamento das mensagens junto com vários outros sinais. Para entender primeiro o conjunto de ferramentas, leia sobre email empresarial para pequenas empresas.
Muitas equipes acham que os problemas vêm apenas do conteúdo. Às vezes isso ocorre, mas com frequência o domínio está mal configurado: um SPF incorreto, uma chave DKIM ausente ou uma política DMARC nunca publicada. Podem surgir incidentes como rejeições no Outlook, limitação de taxa no Gmail, campanhas no spam do Yahoo e encaminhamento confuso.
A solução é simples na teoria e trabalhosa na prática. O SPF informa quais IPs podem enviar para o domínio MAIL FROM real. O DKIM confirma que a mensagem foi assinada e que os dados assinados não sofreram alteração incompatível com a canonicalização. O DMARC solicita um tratamento quando as verificações falham e avalia se o domínio From visível está alinhado ao autenticado. Uma boa configuração reforça a base técnica, sem garantir entrega nem caixa de entrada.
O que SPF, DKIM e DMARC realmente fazem
Essas três camadas fazem parte dos sinais usados por provedores de caixa postal. O SPF verifica o caminho, o DKIM verifica a assinatura e o DMARC verifica alinhamento e política. Quando as regras aplicáveis a remetentes em massa exigem, publique os três; para o DMARC passar, basta um resultado SPF ou DKIM aprovado e alinhado.
| Protocolo | Função principal | O que verifica | Falha comum |
|---|---|---|---|
| SPF | Autorização | Se o IP de envio é permitido para o domínio de envelope | Consultas DNS em excesso ou mudança causada por encaminhamento |
| DKIM | Integridade | Se a mensagem foi assinada e os dados assinados continuam válidos | Seletor errado, chave antiga ou conteúdo alterado no trânsito |
| DMARC | Política e alinhamento | Se SPF ou DKIM passou e correspondeu ao domínio From visível | Uma ferramenta SaaS envia com domínio próprio e não se alinha |
Lembre-se: o DMARC não exige que SPF e DKIM passem juntos. Um deles precisa passar e estar alinhado ao domínio From visto pelo destinatário.
SPF: quem pode enviar email pelo seu domínio
A primeira camada é o SPF, uma lista de autorização. O servidor destinatário examina o domínio MAIL FROM, ou domínio de envelope, consulta seu registro TXT de SPF e determina se o IP conectado está autorizado. É rápido e útil, mas também frágil: encaminhamento e cadeias include extensas podem causar falha.
O SPF é publicado no DNS como TXT. Veja um exemplo:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allEssa linha significa:
v=spf1declara o tipo de registro.include:consulta a infraestrutura de envio publicada por outro domínio.-allindica que todo o restante deve falhar.
Muitas configurações esbarram no limite de 10 consultas da RFC 7208. A contagem inclui mecanismos e modificadores que geram consultas, além das avaliações aninhadas atrás de um include. Ao ultrapassar o limite, o destinatário pode retornar PermError: a avaliação SPF não foi concluída corretamente.
Você cancelou um CRM há dois anos, mas deixou o
include:. A plataforma de marketing acrescentou mais três e o suporte acrescentou outro. Tudo parecia certo até os destinatários avaliarem a cadeia completa.
O SPF também pode falhar após encaminhamento. Se uma universidade encaminhar a mensagem ao Gmail, o Gmail pode enxergar o servidor da universidade como origem. Um SPF correto no caminho direto pode falhar depois disso. Por esse motivo, o SPF sozinho não basta.
Se você envia pela TrekMail, a documentação mostra o include necessário e como integrá-lo sem duplicar registros: Registros DNS obrigatórios.
DKIM: quem assinou a mensagem e se ela mudou
A segunda camada é o DKIM. Ele assina a mensagem com uma chave privada e permite validar a assinatura com uma chave pública no DNS. Ao contrário do SPF, o DKIM pode sobreviver ao encaminhamento se a assinatura continuar válida e os dados assinados respeitarem a canonicalização. Alterações incompatíveis no corpo ou nos cabeçalhos assinados fazem a validação falhar.
Os registros DKIM ficam sob um seletor, como selector1._domainkey.example.com ou dkim._domainkey.example.com. O remetente assina com o seletor correspondente e o destinatário busca a chave pública no DNS.
Um valor típico é:
Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...As falhas operacionais costumam ser simples:
- As chaves foram trocadas, mas o servidor ainda usa o seletor antigo.
- Você mudou de fornecedor e não publicou a nova chave pública.
- O provedor de DNS alterou o longo valor TXT.
- Uma lista de discussão reescreveu o corpo e invalidou a assinatura.
Em uma configuração sólida, use chaves de 2048 bits como padrão quando o serviço e o DNS forem compatíveis, salvo motivo específico para outra opção. Sistemas legados de 1024 bits ainda existem, mas é melhor planejar uma substituição compatível em 2026.
Nos planos pagos da TrekMail, o email do domínio é assinado com sua chave DKIM quando o SMTP gerenciado está ativo, conforme a configuração atual. Isso pode preservar um caminho DMARC alinhado em certos encaminhamentos se a assinatura continuar válida. Para investigar falhas, consulte Meus emails vão para o spam.
DMARC: as regras que orientam os destinatários
A camada final é a política DMARC. Ela se apoia em SPF e DKIM, solicita um tratamento quando a autenticação falha e verifica o alinhamento entre o From visível e os domínios usados por SPF ou DKIM. Sem um caminho aprovado e alinhado, o DMARC falha.
Publique o registro em _dmarc.example.com. Comece com cautela:
v=DMARC1; p=none; rua=mailto:dmarc@example.comAvance quando houver evidências suficientes:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comv=DMARC1; p=reject; rua=mailto:dmarc@example.comp=none não solicita restrições de DMARC, mas a filtragem local continua. p=quarantine solicita que falhas sejam tratadas como suspeitas. p=reject solicita a rejeição. São políticas solicitadas, não garantias de ação ou entrega.
Outra dificuldade é o alinhamento. Exemplo:
Visible From:
newsletter@yourcompany.com
Return-Path:bounce.vendor.com
DKIM domain:vendor.com
O SPF pode passar. O DKIM pode passar. Ainda assim, o DMARC falha porque nenhum deles se alinha a yourcompany.com.
É um problema comum em Mailchimp, HubSpot, Zendesk e CRMs: o painel do serviço aparece verde, mas o domínio não está alinhado nas mensagens reais. As orientações atuais do Google para remetentes em massa a contas pessoais do Gmail exigem SPF e DKIM, com pelo menos um alinhado ao From em emails diretos. Também exigem um registro DMARC mínimo, ainda que seja p=none: Perguntas frequentes do Google para remetentes. Verifique sempre a versão e a aplicabilidade atuais.
SPF, DKIM ou DMARC: qual é mais importante?
Cada protocolo tem uma função distinta e nenhum substitui os demais. Uma assinatura DKIM válida costuma resistir melhor a certos encaminhamentos, o SPF continua exigido em muitas regras e o DMARC acrescenta política e alinhamento. A configuração adequada depende dos caminhos e requisitos aplicáveis.
| Pergunta | SPF | DKIM | DMARC |
|---|---|---|---|
| Verifica o IP de envio? | Sim | Não | Indiretamente pelo resultado SPF |
| Verifica a integridade da mensagem? | Não | Sim | Indiretamente pelo resultado DKIM |
| Resiste bem ao encaminhamento? | Não | Geralmente, se a assinatura continuar válida | Somente se SPF ou DKIM continuar alinhado |
| Publica uma política para destinatários? | Não | Não | Sim, como política solicitada |
| Ajuda a reduzir falsificação? | Em parte | Em parte | Sim, quando aplicado com outros sinais |
Em configurações simples, os três mecanismos são fáceis de administrar. Com um servidor e sem remetentes SaaS, SPF e DKIM costumam ser diretos. Ao combinar suporte, newsletter, CRM e encaminhamento no mesmo domínio, os relatórios DMARC ajudam a revelar o que está alinhado de fato.
Por que encaminhamento e listas ainda causam falhas estranhas
O encaminhamento pode quebrar SPF porque o servidor intermediário repassa a mensagem. O DKIM pode preservar um caminho válido, mas também falha se um intermediário modificar o corpo ou um cabeçalho assinado de modo incompatível. O resultado depende do caminho e da assinatura.
Por isso, uma configuração perfeita no papel pode falhar em destinatários reais. O SPF falha após a troca de IP, o DKIM porque uma lista acrescentou rodapé e o DMARC porque não restou um caminho alinhado.
Quando os três falham após encaminhamento, o ARC permite que intermediários registrem o histórico observado. O destinatário pode considerá-lo localmente, mas o ARC não preserva nem converte automaticamente um resultado DMARC. As orientações do Google tratam especificamente o alinhamento DMARC no tráfego indireto e recomendam cabeçalhos ARC. O remetente normalmente não configura ARC: mantenha o DKIM válido e evite cadeias frágeis. Se o encaminhamento for central, leia sobre encaminhamento de email.
Verificações ocultas que ainda prejudicam a entrega
Registros válidos não garantem a caixa de entrada. Os provedores também consideram DNS reverso, TLS, reclamações e cancelamento de inscrição. SPF, DKIM e DMARC são a base, não o sistema inteiro.
- DNS reverso confirmado por resolução direta: o IP precisa de PTR e esse nome deve resolver para o mesmo IP. O Google inclui DNS direto e reverso válidos entre os requisitos aplicáveis.
- TLS: grandes provedores esperam transporte por TLS; o Google cita emails sem TLS entre possíveis causas de falhas temporárias ou permanentes.
- Reclamações de spam: a orientação atual do Google para o tráfego aplicável recomenda manter a taxa abaixo de 0.1% e evitar que chegue a 0.3%.
- Cancelamento com um clique: para emails promocionais sujeitos a esses requisitos, os provedores esperam cabeçalhos no padrão RFC 8058 além do link visível.
Esses sinais importam ainda mais em um domínio novo. Uma campanha repentina e uma lista ruim podem prejudicar uma reputação com pouco histórico.
Como configurar SPF, DKIM e DMARC sem afetar a produção
Primeiro faça o inventário de todos os remetentes, publique registros coerentes, verifique-os em mensagens reais e avance gradualmente da observação para a aplicação. Pular o inventário pode interromper uma ferramenta SaaS esquecida.
- Liste cada serviço que usa o domínio: caixas, CRM, suporte, newsletter, formulários, cobrança e servidores.
- Reúna os remetentes em um único SPF. Nunca publique dois registros TXT de SPF.
- Publique DKIM para cada remetente que precise de seu próprio seletor.
- Publique primeiro DMARC com
p=nonee analise vários períodos representativos. - Corrija o alinhamento de cada remetente externo ativando domínio personalizado e teste mensagens reais.
- Avance em etapas para
p=quarantineep=rejectapós validar caminhos comuns e raros, com plano de reversão.
Para um domínio TrekMail com envio gerenciado, os registros básicos podem ter este formato conforme a configuração atual:
MX @ mail.trekmail.net. priority 10
TXT @ v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.netA documentação detalha o formato e a verificação em Registros DNS obrigatórios e Verificação do status DNS. Se você está em uma etapa anterior, leia configurar email no meu domínio.
Abordagem antiga e abordagem atual
A abordagem antiga era pagar por usuário por uma suíte ampla ou operar um servidor próprio e manter DNS, TLS, seletores e reputação. Outra abordagem separa as caixas do envio e usa uma plataforma que facilita registros, validação e migração sem vincular tudo ao número de usuários. A adequação depende do ambiente.
A TrekMail pode se encaixar nesse modelo. Segundo as condições descritas pela fonte, o Nano permite até 10 domínios, 5 GB compartilhados e SMTP próprio. Planos pagos começam em $3.50 por mês, incluem SMTP gerenciado e são oferecidos sem preço por caixa conforme as condições atuais. Dependendo do plano atual, também pode haver domínios personalizados, IMAP, catch-all, encaminhamento, migração IMAP e acesso à API nos níveis superiores. Os planos pagos oferecem teste gratuito de 14 dias que exige cartão de crédito. O Nano é apresentado como gratuito e sem cartão. Confira preços, recursos e limites atuais.
Esse modelo pode simplificar o trabalho com vários domínios: um painel, armazenamento compartilhado, registros DNS para copiar e migração no servidor, conforme o plano. A migração IMAP copia mensagens, não DNS, aplicativos nem caminhos. Consulte hospedagem de email para vários domínios e confira os números atuais em preços da TrekMail.
Conclusão: SPF, DKIM e DMARC são uma base técnica atual
Esses controles não são mais exclusivos de ambientes avançados. O SPF autoriza o IP para o domínio de envelope, o DKIM valida a assinatura e o DMARC vincula um caminho autenticado ao From e publica uma política solicitada.
Se só puder fazer uma tarefa esta semana, publique um SPF único e válido, um DKIM funcional e DMARC com p=none. Depois, teste cada remetente com mensagens reais, analise relatórios parciais em vários períodos, verifique caminhos raros e avance gradualmente com plano de reversão. Isso reduz incidentes evitáveis sem prometer resultados de entrega.
