Quem pode enviar e-mail em nome do seu domínio

O problema que esses registros resolvem

O protocolo de e-mail foi desenhado em 1982, numa rede onde todos os participantes se conheciam. Ele não tem nenhuma verificação de remetente embutida: qualquer servidor no mundo pode abrir uma conexão e afirmar que a mensagem vem de financeiro@suaempresa.com.br. Nada no protocolo original impede isso.

É por isso que fraude por e-mail em nome de empresa continua funcionando. O golpe clássico manda um boleto alterado, ou um pedido urgente de transferência assinado pelo diretor, e o endereço no campo De: é genuinamente o da empresa. O destinatário confere o remetente, bate, e paga.

SPF e DMARC são as duas camadas que fecham essa porta. Nenhuma delas é opcional hoje: Google e Microsoft passaram a exigir autenticação de quem envia volume, e uma caixa corporativa que não valida remetente está cada vez mais sozinha.

SPF: a lista de quem pode enviar

SPF é um registro TXT publicado na raiz do domínio que lista quais servidores estão autorizados a enviar e-mail por ele. Quando uma mensagem chega, o servidor de destino consulta esse registro e compara com o IP de quem está entregando. Se não bater, aplica o que o registro mandar.

A parte que decide tudo é o final. O mecanismo all define o que fazer com origem não listada, e o qualificador antes dele muda completamente o efeito: -all rejeita, ~all aceita marcando como suspeita, ?all manda ignorar o resultado e +all autoriza qualquer um.

Publicar +all é o erro mais grave e mais comum, porque parece configuração. O registro existe, uma ferramenta de auditoria acusa SPF presente, e ele não protege absolutamente nada — na verdade é pior do que a ausência, porque cria a impressão de que o assunto está resolvido.

TXT  @  "v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

O limite de dez consultas

O SPF tem um limite que pega quase toda empresa em crescimento: a avaliação não pode disparar mais de dez consultas de DNS. Cada include:, a, mx, exists e redirect conta — e um include: pode ter includes dentro dele, que também contam.

Quando o total passa de dez, a avaliação retorna permerror, e a maioria dos destinatários trata isso como se não houvesse SPF. O registro está publicado, sintaticamente correto, e simplesmente não é aplicado. É uma falha silenciosa: nada quebra visivelmente, e ela costuma aparecer meses depois de contratar mais uma ferramenta de disparo.

A saída é achatar. Substitua includes encadeados pelos blocos de IP efetivamente usados, com ip4: e ip6:, e revise a lista quando trocar de provedor — endereço de terceiro que ficou para trás é autorização permanente para quem herdar aquele IP.

DMARC: a política e o relatório

SPF sozinho tem um buraco: ele valida o endereço do envelope, que o destinatário não vê, e não o campo De:, que é o que aparece na tela. Uma mensagem pode passar no SPF de um domínio e exibir outro no De:.

DMARC fecha isso exigindo alinhamento — o domínio que passou na validação precisa ser o mesmo que aparece para quem lê. E acrescenta duas coisas que SPF não tem: uma política explícita do que fazer quando falha, e relatórios agregados de quem andou enviando em seu nome.

A política tem três valores. Em p=none nada é bloqueado e você só coleta dados; é o ponto de partida certo, e o ponto de parada errado. Em p=quarantine a mensagem vai para spam. Em p=reject ela é recusada na entrega.

Os relatórios são a parte subestimada. Publicar rua= faz chegarem, todo dia, resumos em XML de todo servidor que enviou dizendo ser o seu domínio — inclusive o sistema de RH que ninguém lembrava que mandava e-mail. Sem essa lista, endurecer a política derruba mensagem legítima e alguém manda voltar atrás.

TXT  _dmarc  "v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com.br; fo=1"

Erros que aparecem com mais frequência

• Mais de um registro SPF no domínio. Dois TXT começando com v=spf1 invalidam os dois: a especificação manda tratar como permerror. Quando entra um provedor novo, o include: dele vai no registro existente, não em um segundo.
• Ficar em p=none para sempre. É modo de observação, não de proteção. Sem avançar para quarantine e depois reject, o DMARC não impede fraude nenhuma.
• Publicar rua= para uma caixa que ninguém abre. Relatório agregado só serve se alguém lê — nem que seja uma vez por semana, nas primeiras semanas.
• Esquecer os subdomínios. A tag sp= define a política deles; sem ela, herdam a do domínio. Subdomínio que não envia e-mail deveria estar em reject desde o primeiro dia.
• Confiar que DKIM está certo porque o provedor disse que configurou. DKIM depende de uma chave publicada no seletor certo, e trocar de provedor sem republicar quebra sem aviso.

Como validar que a correção pegou

Depois de publicar, espere o TTL do registro anterior expirar — mudança de DNS não é instantânea, e consultar cedo demais devolve o valor antigo em cache. Rode a verificação de novo aqui e confira se o registro que aparece é o que você publicou.

Depois disso, o teste real é o relatório. Em 24 a 48 horas os primeiros XML começam a chegar no endereço de rua=. Leia por algumas semanas antes de endurecer a política: eles mostram exatamente quais remetentes legítimos ainda falham, e é essa lista que evita derrubar e-mail de verdade quando você passar para reject.