Ordem prudente para configurar SPF, DKIM e DMARC

A autenticação de email com SPF, DKIM e DMARC pode fazer a diferença entre uma mensagem aceita e uma fatura que ninguém encontra. Se o domínio não consegue comprovar a identidade, os provedores têm menos sinais para confiar na mensagem. Isso faz parte das operações diárias atuais.

As equipes nem sempre ignoram os três protocolos. Às vezes configuram na ordem errada, publicam uma política rígida cedo demais e bloqueiam o próprio email. Se você ainda está resolvendo decisões básicas de email empresarial, faça isso primeiro e depois cuide da autenticação.

Este guia propõe uma sequência prudente: inventário, SPF, DKIM, DMARC com p=none, correção do alinhamento e aplicação gradual. Não é a única sequência possível para todo ambiente, mas reduz o risco de interromper encaminhamento, marketing e suporte legítimos.

Se você usa a TrekMail, a plataforma oferece verificações de DNS e, conforme plano e configuração, domínios personalizados, IMAP, catch-all, encaminhamento, migração e SMTP próprio ou gerenciado. Para adicionar um domínio, consulte o guia de configuração. Para começar do zero, leia como criar email com domínio.

O que SPF, DKIM e DMARC realmente fazem

São três mecanismos relacionados. O SPF autoriza IPs para o domínio MAIL FROM real, o DKIM valida a assinatura e os dados assinados e o DMARC solicita um tratamento quando as verificações falham ou não se alinham ao From visível.

Pense no SPF como uma lista de acesso, no DKIM como um lacre e no DMARC como um conjunto de regras. Requisitos atuais podem exigir os três, mas é prudente implantá-los em etapas após conhecer os caminhos reais.

Uma ordem de configuração prudente

Uma sequência comum é inventariar remetentes, publicar SPF, ativar DKIM, publicar DMARC sem restrição, corrigir alinhamento e avançar gradualmente. Ela reduz o risco de rejeitar email legítimo antes de conhecer todas as fontes.

1. Faça o inventário de cada sistema que envia em nome do domínio.
2. Publique um SPF que inclua os remetentes legítimos.
3. Ative DKIM em cada fornecedor compatível.
4. Publique DMARC com p=none e colete relatórios de vários períodos.
5. Corrija as falhas de alinhamento.
6. Avance para p=quarantine e depois p=reject se as evidências sustentarem a mudança.

A dificuldade não está tanto no tamanho dos registros, mas na complexidade real das fontes de envio.

Fase 1: inventário e SPF

O SPF costuma ser uma primeira mudança útil porque indica quais IPs podem enviar pelo domínio MAIL FROM. Não resolve tudo, mas fornece um ponto de partida e revela antigos fornecedores ainda autorizados.

Antes de mexer no DNS, liste email corporativo, cobrança, CRM, suporte, marketing, formulários, impressoras e qualquer sistema que use @yourdomain.com. Verifique também o domínio de envelope em mensagens reais.

Publique um único SPF, não um para o Google e outro para marketing. Vários registros TXT SPF no mesmo domínio geram erro. A documentação da TrekMail destaca isso nos exemplos de DNS.

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com ~all

Escolha ~all ou -all conforme uma política avaliada e caminhos verificados; nenhum deles substitui um inventário completo.

O grande limite do SPF são as consultas. Segundo a RFC 7208, a avaliação tem o limite de 10 consultas DNS geradas pelos mecanismos e modificadores pertinentes, incluindo avaliações aninhadas. Acumular include:, a ou mx pode causar permerror e impedir uma avaliação completa.

Você adiciona Google, HubSpot, Zendesk, QuickBooks, Mailchimp e um sistema antigo esquecido. O SPF parece completo, mas o destinatário atinge o limite durante a avaliação e obtém um erro.

Com muitos domínios, a gestão logo vira trabalho operacional. Audite fornecedores, remova include apenas após confirmar que não é usado e separe por subdomínio somente quando os caminhos MAIL FROM estiverem configurados e testados. Para vários clientes, uma hospedagem de email para vários domínios pode centralizar certas verificações.

Fase 2: DKIM e alinhamento

O DKIM vem depois porque o SPF é sensível ao encaminhamento. O encaminhamento pode mudar o IP e quebrar o SPF, enquanto o DKIM pode continuar válido se a assinatura alinhada sobreviver e os dados assinados respeitarem a canonicalização. Isso não ocorre em todos os caminhos.

Ative DKIM em cada serviço compatível: caixas, plataforma transacional, marketing e suporte. Se um serviço não assina com seu domínio, avalie o risco e as alternativas sem supor que exista uma opção de autenticação personalizada.

Um DNS DKIM típico é:

Type: TXT
Host: trek._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

Alguns fornecedores usam CNAME para DKIM quando há suporte. O método muda, mas ainda é preciso ativar o recurso e testar mensagens reais.

Use seletores separados quando o fornecedor permitir. Assim é mais fácil remover uma plataforma já desativada e confirmada como não utilizada sem afetar a assinatura do servidor principal.

O alinhamento é uma fonte discreta de falhas. Autenticação não basta: o DMARC verifica a correspondência do domínio autenticado com o From visível. As orientações atuais do Google para o tráfego aplicável exigem alinhamento SPF ou DKIM com o domínio organizacional do From e podem exigir ambos publicados. Consulte as perguntas frequentes para remetentes.

Se o Mailchimp assina com seu próprio domínio e usa seu Return-Path, SPF e DKIM podem passar enquanto o DMARC falha para o seu From. Se houver suporte, ative a autenticação personalizada do fornecedor e verifique o resultado real. Não há correção universal fora dos recursos disponíveis.

O encaminhamento é um caso clássico. Se a equipe usa muito, consulte configuração e correção do encaminhamento. O resultado depende do caminho, da assinatura e das alterações intermediárias.

Fase 3: DMARC sem restrição solicitada

O DMARC costuma começar com p=none, que não solicita restrições de DMARC enquanto você coleta dados parciais. Esse valor não coloca o analisador em um modo especial nem desativa a filtragem local.

Veja um registro inicial:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

Você pode usar o alinhamento relaxado padrão ou o estrito conforme domínios e caminhos testados. O estrito não é sempre melhor. Não avance imediatamente para rejeição sem conhecer cada remetente legítimo e seu alinhamento.

Os relatórios DMARC são úteis, mas incompletos; um analisador ajuda na leitura. SPF fail com uma assinatura DKIM válida e alinhada ainda pode resultar em DMARC pass, principalmente após certos encaminhamentos. Se ambos falham, investigue: pode ser falsificação ou uma fonte legítima esquecida. Na TrekMail, consulte o guia de problemas de spam.

Nesta fase aparecem sistemas esquecidos, scanners mal configurados, newsletters antigas e possíveis tentativas de falsificação. Compare cada classificação com inventário, logs e mensagens reais antes de decidir.

Fase 4: corrigir o que os relatórios mostram

Os relatórios fornecem indícios sobre alinhamento e autenticação, mas não determinam sozinhos qual fonte é falsa. Separe falhas legítimas de possíveis abusos e valide o tráfego real em vários períodos representativos.

As falhas costumam entrar nestes grupos:

• Um remetente real está ausente no SPF.
• Um fornecedor assina DKIM, mas não com seu domínio.
• Marketing usa um domínio bounce padrão e o SPF não se alinha.
• Um dispositivo envia diretamente em vez de usar um relay autenticado.
• Um IP desconhecido tenta falsificar o domínio From.

Impressoras e scanners frequentemente enviam diretamente. Um relay SMTP configurado pode ser mais controlável. Os planos pagos da TrekMail incluem SMTP gerenciado conforme as condições atuais; o Nano é oferecido com SMTP próprio conforme essas condições. O guia de configurações IMAP e SMTP documenta hosts e portas atuais. A TrekMail é apresentada como serviço IMAP, não POP3.

Quando relatórios, logs, testes reais e caminhos críticos raros forem validados em vários períodos representativos, avance com cautela e prepare a reversão.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

Comece por quarantine se combinar com o risco e depois avalie reject quando inventário e alinhamento forem confiáveis. São políticas solicitadas; o destinatário mantém seu critério.

Como verificar os registros pela linha de comando

A verificação é importante porque painéis podem mostrar dados antigos, caches persistem e fornecedores podem demorar a atualizar. Consulte o DNS diretamente e envie mensagens de teste por cada sistema.

Verifique o SPF:

dig txt example.com +short

Verifique o DKIM de um seletor:

dig txt trek._domainkey.example.com +short

Verifique o DMARC:

dig txt _dmarc.example.com +short

Procure um único SPF, uma chave DKIM válida e a política DMARC pretendida. Se uma mudança não aparecer, considere o TTL e consulte um resolvedor externo sem supor que uma visão represente todos os destinatários.

Confira também DNS reverso, TLS e taxas de reclamação. A autenticação é uma base, não uma solução mágica, e não compensa listas ruins ou envios imprudentes.

Abordagem antiga e abordagem atual

Uma abordagem tradicional cobra por caixa em uma suíte ampla ou exige manter servidor, DNS, TLS, seletores e reputação. Outra permite controlar domínio, caminho SMTP e autenticação em uma plataforma cujo modelo não está ligado ao número de caixas, conforme as condições.

Segundo a fonte e sujeito a mudanças, o Starter começa em $3.50 por mês, o Nano é oferecido a $0 com SMTP próprio e planos pagos incluem SMTP gerenciado. Os recursos podem incluir domínios personalizados, IMAP, catch-all, encaminhamento, migração IMAP no servidor e API nos níveis superiores. Confira sempre plano, configuração, preço e limites atuais; a migração IMAP copia mensagens, não DNS nem aplicativos.

Essa é a abordagem operacional: configure a autenticação, mantenha-a e avalie o modelo comercial sem presumir economia automática. Para entender a oferta, leia configurar email no meu domínio e consulte os preços da TrekMail.

Conclusão

SPF, DKIM e DMARC formam um sistema relacionado. O SPF autoriza um IP para MAIL FROM, o DKIM valida a assinatura e o DMARC avalia o alinhamento e publica uma política solicitada. A implantação gradual reduz o risco de interrupções causadas pela própria configuração.

Em resumo: inventarie, publique um SPF, ative DKIM onde houver suporte, use DMARC com p=none, corrija o alinhamento e avance depois dos testes. É um caminho operacional prudente para 2025 e 2026, não uma garantia universal. Para consultar as condições atuais, acesse a TrekMail.