O servidor envia, o log diz “250 OK”, e mesmo assim o e-mail chega na caixa de spam, ou volta com uma recusa que fala em SPF, DKIM ou DMARC. Quase sempre a causa está no DNS: são quatro registros que dizem ao mundo quem recebe e quem pode enviar e-mail pelo seu domínio.
Esta é a Parte 3 da série. Na Parte 1 vimos os registros básicos, incluindo o MX, e na Parte 2 o PTR, a primeira checagem que um servidor de e-mail faz. Agora vamos fechar o assunto: MX, SPF, DKIM e DMARC, o que cada um prova, como eles se encaixam e a ordem certa de implantar sem derrubar o próprio e-mail.
Duas direções: receber e provar quem envia
O MX cuida da chegada: diz para quais servidores os e-mails do seu domínio devem ser entregues. Os outros três cuidam da saída: ajudam quem recebe uma mensagem sua a decidir se ela veio mesmo de você.
SPF: quais servidores podem enviar e-mail usando o seu domínio no envelope.
DKIM: a mensagem vem assinada, e a chave para conferir a assinatura está no seu DNS.
DMARC: amarra os dois ao endereço que o destinatário vê no campo De (From) e diz o que fazer quando a checagem falha.
MX: para onde vai o e-mail
Revisão rápida da Parte 1: o MX aponta para os servidores que recebem o e-mail do domínio, cada um com uma prioridade. O menor número é tentado primeiro. Os registros reais do Gmail, consultados em 03/11/2026:
gmail.com. IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. IN MX 40 alt4.gmail-smtp-in.l.google.com.Duas regras evitam dor de cabeça: o destino do MX precisa ter registro A ou AAAA, e não pode ser um CNAME (RFC 2181). E um domínio que não recebe e-mail pode dizer isso explicitamente com o “MX nulo” da RFC 7505 (example.com. IN MX 0 .), que faz os remetentes desistirem na hora em vez de tentar por dias.
SPF: quem pode enviar pelo seu domínio
O SPF (RFC 7208) é um registro TXT na raiz do domínio que começa com v=spf1 e lista quem pode enviar. Um detalhe importante: ele confere o domínio do envelope (o MAIL FROM da conversa SMTP, que aparece como Return-Path), e não o From que o destinatário vê. É por isso que o SPF sozinho não impede a falsificação do remetente visível.
O Gmail usa um redirecionamento para manter a lista num nome separado. Os registros reais, em 03/11/2026 (a lista do _spf.google.com foi encurtada):
gmail.com. IN TXT "v=spf1 redirect=_spf.google.com"
_spf.google.com. IN TXT "v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ... ~all"Num domínio de empresa, o registro costuma juntar o provedor de e-mail e as ferramentas que enviam em nome dele (exemplo fictício):
example.com. IN TXT "v=spf1 include:_spf.provedor-email.example include:envios.crm.example ip4:203.0.113.25 -all"O final define o que fazer com quem não está na lista: -all (falha), ~all (falha leve, softfail) ou ?all (neutro). Nunca use +all: ele autoriza qualquer servidor do mundo.
Os três erros que mais quebram o SPF
Dois registros SPF no mesmo nome. Acontece quando alguém cria um TXT novo para uma ferramenta em vez de editar o existente. A RFC 7208 manda tratar isso como erro permanente (permerror): o SPF para de funcionar para todos.
Mais de 10 consultas DNS. Cada
include,a,mx,existseredirectconta, inclusive os que estão dentro dos includes. Passou de 10, é permerror. Listas grandes de ferramentas estouram esse limite sem ninguém perceber.Esquecer um remetente. O sistema de cobrança, o CRM e a ferramenta de newsletter também enviam com o seu domínio. Se não estão no SPF, falham.
DKIM: a assinatura da mensagem
Com o DKIM (RFC 6376), o servidor de saída assina partes do cabeçalho e o corpo da mensagem e acrescenta um cabeçalho DKIM-Signature. Dois campos dele importam para o DNS: d=, o domínio que assina, e s=, o seletor. Quem recebe busca a chave pública em <seletor>._domainkey.<domínio>:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=2026a; ...
2026a._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."O Gmail, por exemplo, publica a chave do seletor 20230601 em 20230601._domainkey.gmail.com. O seletor existe para permitir a troca de chave sem parar o envio: você publica a chave nova com outro seletor, passa a assinar com ela e só depois remove a antiga.
Duas vantagens sobre o SPF: a assinatura viaja com a mensagem, então sobrevive ao encaminhamento (o SPF costuma falhar quando alguém reencaminha o e-mail), e ela prova que o conteúdo não foi alterado no caminho. Use chave RSA de 2048 bits: o Google exige pelo menos 1024 e recomenda 2048.
DMARC: amarrando tudo ao From
O DMARC é um TXT em _dmarc.<domínio>. Ele faz duas coisas que SPF e DKIM não fazem sozinhos:
Alinhamento. Para o DMARC passar, pelo menos um dos dois precisa passar com o mesmo domínio do From: o domínio do envelope (SPF) ou o
d=da assinatura (DKIM). Um SPF que passa para o domínio do provedor de newsletter não ajuda o seu From.Política. Diz ao destino o que fazer quando a checagem falha:
p=none(só observar),p=quarantine(mandar para o spam) oup=reject(recusar). E pede relatórios agregados comrua=.
Os registros reais do Gmail e do Yahoo, consultados em 03/11/2026, mostram dois estágios diferentes (os endereços de relatório foram encurtados):
_dmarc.gmail.com. IN TXT "v=DMARC1; p=none; sp=quarantine; rua=mailto:..."
_dmarc.yahoo.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:...; ruf=mailto:..."O Yahoo recusa o que falha; o Gmail observa no domínio principal e manda para o spam nos subdomínios (sp=).
O DMARC mudou em maio de 2026
Em maio de 2026 o DMARC virou padrão da IETF com a RFC 9989, que substitui a RFC 7489. O registro continua com v=DMARC1 e os registros existentes seguem valendo. As mudanças práticas: a tag pct saiu da especificação (por isso ela aparece no registro do Yahoo, mais antigo), entrou a tag np para subdomínios que não existem, e o domínio organizacional passou a ser descoberto por uma busca no próprio DNS (o “DNS tree walk”), em vez de uma lista externa de sufixos.
A ordem certa de implantar
Publicar p=reject no primeiro dia é o jeito mais rápido de bloquear o seu próprio e-mail. A sequência segura:
Levante todos os remetentes: provedor de e-mail, CRM, cobrança, newsletter, servidores próprios, impressoras que enviam e-mail.
Ajuste o SPF num registro só, dentro do limite de 10 consultas.
Ative o DKIM em cada remetente, com o seu domínio no
d=.Publique o DMARC com
p=noneerua=e leia os relatórios por algumas semanas. Eles mostram quem envia em seu nome e o que está falhando.Endureça aos poucos:
p=quarantinee, quando os relatórios estiverem limpos,p=reject.
O que os grandes provedores exigem
Desde fevereiro de 2024, as diretrizes de remetente do Google valem para quem envia para contas pessoais do Gmail:
Todos os remetentes: SPF ou DKIM, PTR válido (o FCrDNS da Parte 2), envio por TLS e taxa de spam baixa.
Quem envia perto de 5.000 mensagens por dia ou mais: SPF e DKIM, DMARC publicado (pode ser
p=none), From alinhado com SPF ou DKIM e descadastro com um clique nas mensagens de marketing.
Ou seja: para quem envia em volume, os três registros deixaram de ser boa prática e viraram condição para entregar.
Diagnóstico na prática
Para conferir o que o seu domínio publica:
dig MX example.com +short
dig TXT example.com +short | grep spf1
dig TXT 2026a._domainkey.example.com +short
dig TXT _dmarc.example.com +shortPara saber o que o destino achou de uma mensagem que você enviou, abra o original (no Gmail, “Mostrar original”) e procure o cabeçalho Authentication-Results:
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comOs três pass com o mesmo domínio são o objetivo. Um spf=pass com o domínio de outra empresa no smtp.mailfrom é o sinal clássico de falta de alinhamento.
Checklist rápido
PTR do IP de envio confirmado pelo direto (Parte 2).
Um único SPF, com todos os remetentes e no máximo 10 consultas.
DKIM ativo em todos os remetentes, com o seu domínio e chave de 2048 bits.
DMARC publicado com
rua=, começando emp=none.Relatórios lidos antes de subir para quarantine e reject.
Resumindo
O MX diz onde o seu e-mail chega; SPF, DKIM e DMARC ajudam o destino a confiar no que você envia.
O SPF confere o envelope; um único registro, no máximo 10 consultas.
O DKIM assina a mensagem; a chave fica em
seletor._domainkey.O DMARC exige alinhamento com o From e define a política; desde maio de 2026 ele é a RFC 9989.
Implante na ordem: remetentes, SPF, DKIM, DMARC em none, e só então quarantine e reject.
Na Parte 4, o assunto é DNS e VoIP: como um telefone ou um PBX descobre o servidor SIP com NAPTR e SRV. Se você quer reforçar a base de redes, conheça os nossos cursos.