Sua configuração SPF funciona bem com um remetente. Depois você adiciona Google Workspace, Mailchimp, Zendesk e uma API transacional, e a Microsoft começa a devolver mensagens com 550 5.7.515. O registro que parecia limpo no lançamento acabou de ultrapassar o limite de 10 consultas, e agora todas as mensagens de saída falham silenciosamente na autenticação.
Essa é a armadilha. O SPF tem um teto rígido incorporado ao protocolo, e muitas equipes o atingem quando adicionam o terceiro ou quarto serviço de envio. A solução habitual, colar outro include:, deixa de funcionar justamente quando se torna mais necessária. Para aprender a sintaxe básica, comece pelo nosso guia de registro SPF para e-mail. Este artigo trata da arquitetura: como criar uma configuração SPF que aceite vários remetentes, sobreviva a mudanças de fornecedor e não precise ser reescrita a cada trimestre.
Por que a configuração SPF falha com vários remetentes
A configuração SPF falha porque a RFC 7208 limita a avaliação a 10 consultas DNS por registro. Cada mecanismo include, a, mx, exists e redirect conta, e a contagem é recursiva. Se o include de um fornecedor contiver outros três includes, todos consomem seu limite. Ao chegar a 11, os servidores destinatários retornam PermError e podem rejeitar a mensagem.
O padrão de falha costuma ser o mesmo. Você começa com dois includes e bastante folga. O marketing adiciona HubSpot, o suporte adota Freshdesk e a engenharia usa SendGrid nos alertas do aplicativo. A cadeia de cada fornecedor tem mais níveis do que a documentação sugere. De repente, são 12 consultas, e o Google retorna 550 5.7.26 em todas as mensagens.
| Mecanismo | Consome uma consulta? | Observação operacional |
|---|---|---|
include: | Sim, incluindo os aninhados | Padrão para fornecedores, mas o aninhamento é imprevisível |
ip4: / ip6: | Não | Sem custo de consulta; use para remetentes estáticos sob seu controle |
mx | Sim | Muitas vezes usado em excesso; substitua por ip4 quando possível |
a | Sim | Ineficiente para SPF; prefira ip4 |
ptr | Sim | Obsoleto. Não use |
redirect | Sim | Transfere a avaliação para o registro de outro domínio |
-all / ~all | Não | Final da política; sempre inclua um |
A conta não é complicada. Ela apenas fica invisível até que algo quebre. Por isso, a configuração SPF para vários remetentes precisa começar pela arquitetura, não por copiar e colar.
Audite seu registro SPF antes de adicionar qualquer coisa
O primeiro passo de toda configuração SPF com vários remetentes é remover o que não deveria estar ali. Muitos domínios carregam includes de serviços cancelados há meses ou anos, e cada um desperdiça parte do limite de consultas. Primeiro limpe, depois construa.
Confira o que realmente está publicado:
dig txt yourdomain.com +shortDepois acompanhe cada include para descobrir sua profundidade:
dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +shortCompare o resultado com seus relatórios agregados de DMARC. Se nenhum tráfego realmente vier dos IPs de um fornecedor, aquele include só ocupa espaço. Remova-o.
Três ganhos rápidos durante a auditoria:
- Substitua
mxpelo IP real usandoip4:; isso economiza uma consulta. - Remova includes de serviços que você não usa mais.
- Procure registros SPF duplicados. Dois registros TXT que começam com
v=spf1no mesmo domínio provocam PermError imediatamente.
Só isso costuma liberar 2-3 consultas. Para acompanhar uma limpeza detalhada, veja nosso guia de configuração de registro SPF.
Segmentação por subdomínio: a configuração SPF que cresce
A configuração SPF que lida com vários remetentes de forma confiável sem atingir o teto de 10 consultas é a segmentação por subdomínio. O SPF é avaliado pelo domínio de Return-Path, não pelo cabeçalho From visível. Mova remetentes não corporativos para subdomínios, e cada fluxo ganha um novo limite de 10 consultas.
Este é o padrão:
Domínio raiz: apenas e-mail entre pessoas
Mantenha o domínio raiz limpo. Inclua nele somente seu principal provedor de caixas postais.
v=spf1 include:spf.trekmail.net -allUm include e uma consulta. O e-mail da direção não para de funcionar porque o marketing adicionou outra ferramenta.
Subdomínio de marketing: campanhas e newsletters
; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -allHubSpot e Mailchimp consomem consultas de news.example.com, não do domínio raiz. Se esse subdomínio sofrer limitação, o e-mail corporativo continua circulando.
Subdomínio de suporte: sistemas de tickets
; help.example.com
v=spf1 include:mail.zendesk.com -allSubdomínio transacional: alertas e recibos de aplicativos
; alerts.example.com
v=spf1 include:amazonses.com -allQuando o Zendesk envia como support@help.example.com, o destinatário consulta o DNS de help.example.com. O registro SPF do domínio raiz nem é acessado. Esse é o objetivo.
| Forma antiga | Forma nova |
|---|---|
| Todos os remetentes espremidos em um único registro SPF raiz | O domínio raiz contém apenas o principal provedor de caixas postais |
| Uma mudança de fornecedor pode interromper todos os envios | As falhas ficam isoladas no subdomínio afetado |
| O limite de consultas é compartilhado entre todos | Cada subdomínio recebe seu próprio limite de 10 consultas |
| O SPF é reescrito sempre que uma ferramenta é adicionada | A arquitetura resiste à troca de fornecedores |
Flattening de SPF: o último recurso
Se os requisitos do negócio obrigarem todo o e-mail a sair do domínio raiz, sem permitir subdomínios, o flattening de SPF é uma saída. Ele resolve os includes dos fornecedores em endereços IP brutos e os lista como mecanismos ip4:, que não consomem consultas. Funciona, mas cria um problema de manutenção.
O risco é a desatualização. Provedores SaaS alteram seus IPs regularmente. Se a SendGrid adicionar uma nova faixa amanhã e o registro achatado ainda listar os endereços de ontem, as mensagens de saída começarão a falhar no SPF. Não faça flattening manual, a menos que consiga verificar o registro diariamente. Use um serviço de SPF dinâmico automatizado que monitore os IPs dos fornecedores e atualize o registro TXT em intervalos definidos.
Flattening é uma solução paliativa, não uma arquitetura. A segmentação por subdomínio é a correção estrutural. Use o flattening apenas quando todas as outras alternativas tiverem sido realmente esgotadas.
Verifique se a configuração SPF está funcionando
Depois de qualquer alteração no SPF, confira o que o DNS público realmente retorna. Não confie no painel da registradora, em interfaces com cache nem nos indicadores verdes da tela de um fornecedor. Consulte o domínio diretamente e confirme que há exatamente um registro SPF válido por nome de host.
# Check the root record
dig txt example.com +short
# Check a subdomain
dig txt news.example.com +short
# Verify DMARC while you're at it
dig txt _dmarc.example.com +shortVocê deve encontrar um registro TXT iniciado por v=spf1 em cada nome de host. Não dois. Também não um atual acompanhado de outro esquecido em uma migração de dois anos atrás.
Depois envie uma mensagem de teste ao Gmail, abra o e-mail, clique no menu de três pontos, escolha "Mostrar original" e procure:
SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASSQualquer resultado FAIL ou SOFTFAIL indica um problema na configuração SPF. Corrija antes de enviar em volume. Se também estiver investigando dificuldades de reputação além do SPF, nosso guia sobre sinais de reputação do remetente apresenta o cenário mais amplo.
Como a TrekMail simplifica o SPF em vários domínios
Configurar SPF em um domínio é trabalhoso. Fazer isso em 50 domínios de clientes, cada um com fornecedores de envio e DNS diferentes e variados níveis de abandono, consome muito tempo. A TrekMail mantém uma presença SPF pequena e previsível para deixar espaço para todo o resto.
O include principal é include:spf.trekmail.net. Uma consulta. Sem redirecionamentos aninhados ou cadeias de expansão imprevisíveis. Compare com o Microsoft 365, que costuma consumir 2-3 consultas por meio de redirecionamentos internos, ou com o Google Workspace, cujo comportamento pode variar por região.
Para profissionais independentes, isso mantém a configuração SPF simples mesmo depois de adicionar uma ferramenta de marketing. Para equipes, reduz erros de DNS durante a entrada. Para agências que administram dezenas ou centenas de domínios de clientes, oferece um modelo repetível: adicione o include da TrekMail, separe os outros fornecedores em subdomínios e evite o problema do limite de consultas. Se você gerencia e-mail para várias marcas, consulte a arquitetura de hospedagem de e-mail em vários domínios.
O verificador de status do DNS da TrekMail também sinaliza conflitos de SPF no painel antes que provoquem falhas em produção. Você vê o problema antes dos clientes. Para consultar toda a configuração, veja os registros DNS obrigatórios na documentação.
Conclusão: crie a arquitetura SPF uma vez e pare de alterá-la
Uma boa configuração SPF começa pela arquitetura, não pela sintaxe. Audite includes antigos. Distribua os remetentes entre subdomínios para que cada fluxo receba seu próprio limite de 10 consultas. Mantenha o domínio raiz limpo: um provedor de caixas postais, um include e um -all. Verifique com dig, não por painéis.
Se você deseja manter esse modelo em um ou cem domínios sem cobrança por usuário, a TrekMail oferece hospedagem de vários domínios por valor fixo, um único include SPF limpo, armazenamento compartilhado e um verificador DNS que detecta erros de configuração cedo. Conforme as condições atuais, o plano Nano atende a 10 domínios com SMTP próprio, sem cartão de crédito e gratuitamente. Os planos pagos começam em $3.50/month no Starter com SMTP gerenciado e incluem teste grátis de 14-day (cartão obrigatório). Consulte os planos vigentes em trekmail.net/pricing.
