Criar um registro SPF: organize remetentes e controle as consultas

Se você precisa criar um registro SPF para um domínio, o objetivo é simples: autorizar os remetentes certos sem transformar o DNS em uma confusão que vai dar problema meses depois. Muitas falhas começam do mesmo jeito. Você adiciona um fornecedor, depois outro. A Microsoft retorna um 550 5.7.515, o Google retorna um 550 5.7.26, e você acaba vasculhando registros TXT às 11 da noite.

Esse é o problema. SPF parece fácil até deixar de ser. O registro do domínio raiz vira um depósito de configurações, os includes recursivos se acumulam e uma avaliação adicional pode causar PermError. Se você administra um domínio empresarial, a infraestrutura de um cliente ou várias marcas, isso pode prejudicar a entrega, embora PermError não signifique rejeição automática. Para entender melhor a configuração do domínio, comece por e-mail empresarial para pequenas empresas.

Este guia apresenta uma arquitetura mais sustentável: manter o e-mail corporativo no domínio raiz, separar os envios em massa e de aplicativos em subdomínios efetivamente usados no envio e tratar o orçamento de consultas como um recurso limitado. Assim, os registros SPF ficam mais fáceis de manter, sem dispensar revisões quando os remetentes mudarem.

Por que tantos registros SPF falham

SPF pode falhar porque os destinatários limitam os termos que acionam consultas DNS durante a avaliação. Ao empilhar includes demais em um domínio, a política pode ultrapassar o limite, retornar PermError e prejudicar a entrega ou causar rejeição conforme a política do destinatário, mesmo que a sintaxe pareça correta.

O RFC 7208 é claro. Os termos que acionam consultas DNS incluem include, a, mx, ptr, exists e redirect. Os destinatários devem limitar a 10 os termos desse tipo avaliados, incluindo os recursivos; não se trata de contar todos os pacotes DNS. Ultrapassar o limite gera um erro permanente, não um aviso. O RFC também determina que vários registros SPF no mesmo nome de domínio causam PermError. Outros registros TXT, sem relação com SPF, podem coexistir.

É por isso que a recomendação habitual não basta. Guias genéricos sugerem criar um registro SPF colocando todos os remetentes em um valor TXT no @. Parece organizado, mas transforma o domínio raiz em infraestrutura compartilhada por newsletters, sistemas de suporte, alertas de aplicativos, ferramentas de prospecção e caixas de e-mail de pessoas. Se um fornecedor ampliar a cadeia de includes, todos os envios que dependem dessa política podem ser afetados.

Um padrão ruim: um único registro SPF no domínio raiz tentando autorizar todas as ferramentas que a empresa já usou.

As orientações do Google para remetentes também destacam a autenticação correta e o alinhamento consistente, especialmente para envios em massa. SPF é apenas parte do conjunto, mas uma falha nele costuma ser o primeiro sintoma visível.

A verdadeira restrição: o orçamento de 10 consultas

A regra é esta: ao criar a política SPF, você tem um orçamento fixo de 10 termos avaliados que acionam consultas DNS. A contagem é recursiva. Se um include leva a outros termos desse tipo e eles são avaliados, também entram na conta. Seu provedor DNS não corrige uma política SPF mal dimensionada.

O que entra no orçamento:

• include
• a
• mx
• ptr (evite usar)
• exists
• redirect

O que não entra no orçamento:

• ip4
• ip6
• all

As consultas sem resultado também merecem atenção. O RFC 7208 recomenda que os destinatários as limitem a duas. Um erro de digitação no destino de um include pode consumir parte dessa margem. Ultrapassar o limite recomendado, e não apenas atingi-lo, pode provocar outro PermError.

Se o domínio envia por vários fornecedores, calcule o orçamento real antes de publicar o registro SPF. O risco não depende apenas da quantidade de fornecedores, mas dos termos avaliados nas políticas deles e da sua arquitetura.

Criar um registro SPF com uma arquitetura separada

Uma forma de reduzir o risco é separar o e-mail entre pessoas dos envios em massa ou de aplicativos. Mantenha o provedor principal de caixas de e-mail no domínio raiz e configure os remetentes especializados com subdomínios que eles realmente usem no MAIL FROM ou return-path. Alterar somente o From visível não separa o orçamento SPF. O alinhamento DMARC continua necessário por SPF ou DKIM, conforme o modo estrito ou relaxado.

O padrão é este:

1. Domínio raiz @ para mensagens entre pessoas.
2. Subdomínios de MAIL FROM ou return-path para newsletters, suporte, alertas transacionais e outros remetentes especializados.
3. Um registro SPF por nome de host, sem duplicatas nem políticas antigas esquecidas. Outros TXT sem relação com SPF podem coexistir.

Exemplo de registro no domínio raiz para envio gerenciado pelo TrekMail, sujeito à configuração atual:

v=spf1 include:spf.trekmail.net -all

A política é fácil de revisar: um include e uma terminação explícita. Esse include pode ter dependências recursivas; confira o custo efetivo.

Exemplo ilustrativo para um subdomínio de marketing, que deve ser conferido nas orientações oficiais atuais de cada fornecedor:

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Mailchimp e HubSpot só consomem o orçamento de marketing.example.com se esse for o domínio realmente usado no MAIL FROM ou return-path e se a configuração deles permitir esse modelo. Nesse caso, mudanças nas políticas SPF desses serviços não afetam diretamente a política de example.com. O alinhamento DMARC ainda exige configuração adequada.

O TrekMail também se encaixa nessa organização. A documentação de domínios apresenta include:spf.trekmail.net como include básico do envio gerenciado. O verificador DNS pode ajudar a identificar conflitos, mas não substitui uma verificação completa. Se você está configurando caixas de e-mail e DNS, consulte Adicionar um domínio ao TrekMail e Verificar o status do DNS.

Passo a passo: criar valores SPF sem improvisar

Para criar registros SPF fáceis de manter, primeiro inventarie todos os remetentes, atribua o nome de host correto a cada um e só depois monte o TXT. Não comece pelo DNS: comece por identificar quem envia e qual domínio de envelope usa. Isso evita o acúmulo de includes arbitrários no domínio raiz.

Siga este processo:

1. Liste todos os serviços que enviam e-mail usando seu domínio.
2. Classifique cada remetente como corporativo, transacional, de suporte ou de marketing.
3. Defina o nome de host de MAIL FROM de cada remetente e verifique o alinhamento DMARC.
4. Use a menor política SPF que autorize todos os envios legítimos daquele host.
5. Publique um TXT de SPF por host; outros TXT sem relação com SPF podem coexistir.

Depois monte o registro real, seguindo as orientações oficiais atuais do fornecedor e a configuração de MAIL FROM personalizado.

Exemplo de SMTP gerenciado pelo TrekMail:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

Exemplo combinado de TrekMail e SMTP próprio para Nano ou configurações híbridas, não uma receita universal:

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

No TrekMail Nano, o modelo descrito exige seu próprio provedor SMTP para enviar. Autorize o fornecedor que realmente entrega a mensagem e o domínio de envelope correspondente; hospedar as caixas no TrekMail não exige incluir TrekMail e SES juntos automaticamente. O exemplo combinado só serve quando ambos são necessários, e o SES exige seguir as instruções de MAIL FROM personalizado. Segundo as condições apresentadas no artigo, os planos pagos começam em $3.50/mês e incluem SMTP gerenciado. O Nano é descrito como gratuito, sujeito às condições vigentes. Os planos pagos também oferecem teste gratuito de 14 dias com cartão de crédito obrigatório. Confira as condições atuais e consulte SMTP próprio (BYO) e SMTP gerenciado pelo TrekMail.

Publicar e verificar o registro

Depois de criar o SPF, publique-o como TXT e verifique o que o DNS público retorna. Não confie apenas na interface do registrador, em um painel com dados em cache ou no indicador verde de uma ferramenta. Consulte o domínio e confirme que existe somente um registro SPF válido. Esses comandos normalmente consultam um resolvedor com cache: não garantem resposta direta dos servidores autoritativos nem um prazo exato de propagação.

Mac ou Linux:

dig txt example.com +short

Windows:

nslookup -type=txt example.com

Você deve encontrar um único valor SPF começando com v=spf1, sem outra política SPF duplicada ou um registro antigo esquecido após uma migração. Outros valores TXT sem relação com SPF são compatíveis.

Verificações rápidas:

• Começa com v=spf1
• Termina com -all depois de concluir o inventário de remetentes e os testes
• Contém apenas os remetentes que você realmente usa
• Existe uma única política SPF por host, não várias

Ao trocar de fornecedor, revise os registros anteriores: podem restar MX e SPF que não correspondem mais à configuração desejada. A documentação DNS do TrekMail aborda esses casos. Para uma migração mais ampla, estes guias podem ajudar: como criar e-mail com domínio próprio e hospedagem de e-mail para vários domínios.

Erros comuns de SPF e como começar a corrigi-los

Muitas falhas de SPF vêm de um excesso de termos avaliados que acionam consultas DNS, registros SPF duplicados, domínios de envio incorretos ou erros nos includes. Um mapa claro de remetentes facilita identificar esses problemas. Improvisar costuma tornar o diagnóstico caro rapidamente.

Estas regras práticas evitam muita dor de cabeça:

1. Use ip4 para remetentes estáticos sob seu controle. Isso não consome termos do orçamento de consultas.
2. Separe o MAIL FROM dos envios de marketing daquele usado pela direção quando o fornecedor permitir, preservando o alinhamento DMARC.

A documentação do Google ajuda a definir o objetivo completo: autenticação e alinhamento, não SPF isoladamente. SPF pode passar e DMARC falhar se o domínio do From visível não estiver alinhado ao domínio de envelope autenticado, conforme o modo estrito ou relaxado, e não houver uma assinatura DKIM alinhada que passe. Consulte as perguntas frequentes do Google sobre as diretrizes para remetentes se estiver investigando a entrega de envios em massa.

Quando o TrekMail pode facilitar o trabalho

O TrekMail pode ajudar a manter uma configuração consistente em vários domínios. O modelo descrito reúne um include para envio gerenciado, armazenamento compartilhado, cobrança sem tarifa por usuário, migração IMAP integrada e SMTP próprio ou gerenciado conforme o plano. Verifique disponibilidade, limites e condições atuais; um único include não garante baixo custo recursivo.

Para quem empreende sozinho, a vantagem pode ser a simplicidade: hospedar as caixas no TrekMail, manter a política raiz organizada e evitar cobrança por usuário conforme o plano. Para equipes, a padronização pode facilitar a entrada de colaboradores e reduzir erros DNS. Para agências e MSPs, oferece um padrão reutilizável em muitos domínios, desde que cada remetente e migração sejam verificados.

Trocar configurações SPF frágeis e diferentes para cada cliente por uma arquitetura repetível, um painel comum e uma política raiz verificada melhora a operação. Não se trata apenas de encurtar uma sequência TXT.

Como referência do artigo, o Nano oferece 10 domínios, 5GB de armazenamento compartilhado e SMTP próprio sem cartão obrigatório. Se você precisa de envio gerenciado e limites maiores, os planos pagos descritos começam em $3.50/mês, com teste gratuito de 14 dias que exige cartão de crédito. Consulte os preços do TrekMail para confirmar os planos, limites e condições atuais.

Conclusão: criar um registro SPF mais fácil de manter

Para criar registros SPF duradouros, deixe de pensar em uma lista enorme de permissões no domínio raiz e pense em arquitetura. Domínio raiz para mensagens entre pessoas. Subdomínios de MAIL FROM para remetentes especializados. Includes mínimos. -all explícito quando o inventário estiver completo. Verificação DNS após publicar, considerando caches e alinhamento DMARC.

Essa abordagem ajuda a controlar o orçamento de consultas e a reduzir falhas inesperadas. Não elimina revisões quando os fornecedores mudam, mas as facilita. Se você está renovando sua infraestrutura de e-mail, conheça o TrekMail e verifique se o modelo e as condições atuais atendem ao seu crescimento.