Configurar um registro SPF: etapas e exemplos de provedores

A configuração do registro SPF permite que o servidor destinatário verifique se um IP está autorizado a enviar usando seu domínio como remetente do envelope. Não é necessariamente a primeira verificação, nem a única. Um erro SMTP 550 5.7.26 pode indicar falha de autenticação, mas não comprova que o SPF seja a causa. Desde fevereiro de 2024, Google e Yahoo aplicam requisitos de autenticação que variam conforme o tipo de remetente e o volume de envio.

Os problemas mais comuns são registros duplicados, ultrapassar o limite de 10 termos que exigem consultas DNS e escolher um qualificador final inadequado. Essas falhas podem prejudicar a entrega por dias antes de serem percebidas. E as mensagens de devolução nem sempre explicam o motivo.

Este guia aborda a configuração do SPF: sintaxe, exemplos para TrekMail com SMTP gerenciado ou próprio, publicação no DNS e validação pela linha de comando. Se você ainda não configurou o e-mail do domínio, comece por configurar e-mail no seu domínio e depois volte à etapa de autenticação.

O que o SPF faz

O SPF (Sender Policy Framework) publica em um registro TXT do DNS uma política para avaliar os IPs autorizados a enviar usando uma identidade do seu domínio. O resultado depende dos mecanismos e qualificadores, sem determinar sozinho a aceitação ou rejeição da mensagem. Definido na RFC 7208, o SPF verifica a identidade MAIL FROM, ou remetente do envelope, ou HELO quando aplicável, não o cabeçalho From que o destinatário vê.

Sem SPF, os destinatários não podem consultar essa política para verificar se o IP está autorizado a usar seu domínio no envelope. Outros sinais de autenticação continuam importantes: SPF sozinho não impede toda falsificação nem garante a entrega na caixa de entrada.

A regra de um único registro

O nome consultado para essa identidade pode ter apenas um registro SPF. Dois registros TXT começando com v=spf1 causam PermError; o destinatário decide como tratar o erro. Um registro TXT pode conter várias strings entre aspas, concatenadas durante a avaliação. Preserve os demais TXT de verificação: a regra não proíbe outros registros TXT na zona. Duplicatas podem aparecer ao trocar de provedor ou adicionar uma ferramenta de marketing sem incorporar a autorização existente.

Edite ou combine o registro SPF existente antes de publicar outro. Durante uma migração, mantenha os remetentes ainda ativos em uma única política. Não apague o registro primeiro, pois isso deixaria um intervalo sem SPF.

Etapa 1: liste todos os serviços que enviam usando seu domínio

Antes de alterar o DNS, liste os serviços que enviam como @yourdomain.com e confira o domínio usado no remetente do envelope. Um remetente legítimo esquecido pode receber fail com uma política -all. Essa revisão pode levar cinco minutos em uma configuração simples, mais em ambientes complexos, e evitar horas de diagnóstico.

Remetentes comuns para revisar:

• E-mail corporativo: TrekMail, Google Workspace, Microsoft 365
• Mensagens transacionais: Amazon SES, SendGrid, Mailgun, Postmark
• Marketing: Mailchimp, HubSpot, Klaviyo, Brevo
• Ferramentas SaaS: Zendesk, Freshdesk, Shopify, Intercom

Alguns serviços usam seu próprio domínio de retorno, como bounce.mailchimp.com, e não precisam estar no SPF do seu domínio para esse fluxo. Outros permitem um domínio de retorno personalizado para o alinhamento DMARC. Consulte a documentação do fornecedor e as configurações da conta antes de incluí-los ou deixá-los de fora.

Etapa 2: monte seu registro SPF

Um registro SPF é uma string TXT no DNS. A estrutura é a mesma em qualquer configuração; os mecanismos mudam. Veja a função de cada componente:

Etapa 3: configuração SPF por fornecedor

Escolha o cenário adequado à sua infraestrutura. Os registros abaixo são exemplos: confira as instruções atuais do fornecedor e os valores específicos da sua conta antes de publicar. Se vários fornecedores usam a mesma identidade, combine os mecanismos include em um único registro.

Cenário A: SMTP gerenciado do TrekMail (planos Starter e Agency)

Se seu plano TrekMail inclui SMTP gerenciado, este é um exemplo para o serviço. Confirme o valor mostrado no painel:

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

Esse include aponta para os IPs de entrega gerenciados pelo TrekMail. Acrescente outros remetentes autorizados, se necessário.

Cenário B: SMTP próprio no TrekMail (plano gratuito ou configuração personalizada)

Se você usa TrekMail para receber mensagens e conecta outro fornecedor SMTP para enviar, autorize os IPs desse fornecedor no domínio realmente usado no remetente do envelope. A mensagem pode passar pelo TrekMail, mas a entrega final utiliza os IPs do fornecedor SMTP.

# Amazon SES
v=spf1 include:amazonses.com -all

# SendGrid
v=spf1 include:sendgrid.net -all

Cenário C: Google Workspace

v=spf1 include:_spf.google.com -all

Cenário D: Microsoft 365

v=spf1 include:spf.protection.outlook.com -all

Cenário E: configuração híbrida (TrekMail e plataforma de marketing)

Usa TrekMail para o e-mail da equipe e HubSpot para campanhas? Se ambos precisam de autorização no mesmo domínio do envelope, combine os mecanismos. É para isso que serve a regra de um único registro:

v=spf1 include:spf.trekmail.net include:456789.spf05.hubspotemail.net -all

O include do HubSpot é específico do seu portal. Obtenha o valor nas configurações DNS do HubSpot, em vez de copiar este exemplo.

Etapa 4: publique no DNS

A configuração exige um único registro TXT SPF no nome de domínio correspondente. Acesse Cloudflare, Namecheap, GoDaddy, Route 53 ou o provedor que hospeda seu DNS.

1. Tipo: TXT
2. Host/Nome: @ para o domínio raiz, ou deixe vazio conforme o provedor
3. Valor: Sua string SPF completa, por exemplo v=spf1 include:spf.trekmail.net -all
4. TTL: 3600 (1 hora)

Se já existe um registro SPF, edite-o para incorporar a nova política. Não adicione um segundo SPF nem apague o primeiro antes de preparar a substituição. Confira o resultado: registros duplicados geram PermError e podem afetar a entrega.

Etapa 5: valide seu registro SPF

Não presuma que a configuração funcionou. Confira pela linha de comando. As consultas mostram a resposta do resolvedor utilizado, que também pode ter dados em cache; elas não representam necessariamente o que todos os destinatários veem naquele momento.

# Mac, Linux, or Windows PowerShell
nslookup -q=txt yourdomain.com

# Linux/Mac alternative
dig txt yourdomain.com +short

Confira três pontos:

• Existe exatamente um registro começando com v=spf1; ele pode aparecer dividido em várias strings entre aspas
• Todos os mecanismos include necessários estão presentes
• Termina com -all ou ~all, conforme a política escolhida

Se encontrar dois registros distintos começando com v=spf1, combine-os preservando todos os remetentes legítimos e remova a duplicata.

Como resolver erros SPF comuns

Muitos problemas de configuração SPF envolvem os três pontos abaixo. Eles ajudam a direcionar o diagnóstico, mas não substituem a leitura da mensagem de devolução completa.

1. O limite de 10 consultas (PermError)

O SPF limita a 10 os termos avaliados que exigem consultas DNS, inclusive nas políticas aninhadas. Cada include avaliado conta, assim como os termos a, mx, exists, ptr e redirect aplicáveis; referências do fornecedor podem acrescentar outros termos. Não é um limite de 10 pacotes DNS nem apenas da quantidade de fornecedores. Exceder o limite gera PermError, e o destinatário pode rejeitar a mensagem.

Sintoma: Validadores retornam PermError ou "too many DNS lookups".

Solução: Mova determinados fluxos, como Mailchimp ou Zendesk, para um subdomínio como support.yourdomain.com, se o fornecedor permitir usá-lo como domínio do remetente do envelope. Esse nome tem sua própria política e seu limite de 10 termos. Alterar apenas o endereço visível não basta; verifique também o alinhamento DMARC.

2. Caixas pessoais da Microsoft (550 5.7.515)

O código 550 5.7.515 se relaciona aos requisitos de autenticação para remetentes de alto volume destinados ao Outlook.com pessoal. Eles exigem aprovação tanto de SPF quanto de DKIM, além de DMARC com pelo menos uma dessas verificações alinhada ao From visível. O código não comprova que o SPF esteja correto nem que a reputação do IP seja a causa: revise a resposta completa e mensagens representativas. Em outros fluxos, uma única verificação válida e alinhada pode bastar para o DMARC. Veja a base de segurança para e-mail empresarial para configurar DKIM e DMARC.

3. SoftFail (~all) e HardFail (-all)

~all retorna SoftFail e ?all retorna Neutral, não Fail. Depois de validar a configuração e conferir todos os remetentes, considere mudar para -all, sem tratar isso como proteção completa contra falsificação.

Configuração SPF com TrekMail

Gerenciar DNS e investigar erros SMTP toma tempo. Se estiver disponível na sua conta, o assistente SPF/DKIM/DMARC do TrekMail orienta a configuração para SMTP gerenciado ou próprio. Confirme os valores exibidos para seu domínio.

Para agências que gerenciam dezenas de domínios, uma configuração SPF consistente facilita as revisões. Conforme os recursos da conta, o painel multidomínio do TrekMail mostra verificações dos registros DNS esperados. Isso não substitui a validação criptográfica de DKIM nem testes de SPF e alinhamento DMARC em mensagens reais, e não comprova entrega na caixa de entrada. Veja hospedagem de e-mail para vários domínios e como criar e-mail com domínio próprio.

A referência histórica menciona Starter a partir de $3.50 por mês com SMTP gerenciado, Nano gratuito sem cartão nem vencimento de teste, e teste de 14 dias nos planos pagos com cartão obrigatório. No modelo Nano descrito, todo envio, inclusive respostas, exige SMTP externo próprio; o envio gerenciado dos planos pagos depende das permissões do plano e da configuração compatível do cliente. Confira preços, disponibilidade e condições atuais antes de contratar. Conheça o TrekMail e as opções de teste.

Checklist completo da configuração SPF

Antes de fechar esta página, revise estas sete etapas. Uma configuração simples pode levar menos de 15 minutos, mas o inventário de remetentes e a atualização dos caches DNS podem exigir mais tempo.

1. Você listou todos os serviços que enviam usando seu domínio
2. Confirmou que existe zero ou um registro SPF, não dois
3. Montou uma única string v=spf1 cobrindo os fornecedores necessários
4. Publicou como TXT em @ para o domínio raiz, com TTL 3600
5. Atualizou ou combinou o registro anterior sem deixar um intervalo sem política SPF
6. Verificou com dig txt yourdomain.com +short
7. Confirmou um único registro começando com v=spf1 e terminando com -all quando apropriado à sua política

Simplifique a gestão do e-mail. Conheça o envio com TrekMail.