Registro SPF: configuração, exemplos e erros comuns

Ao preparar uma infraestrutura de e-mail em 2026, o registro SPF é uma parte importante da autenticação. Uma configuração incorreta pode contribuir para spam ou rejeição, mas SPF não determina sozinho se a mensagem chega à caixa de entrada.

Desde fevereiro de 2024, Google e Yahoo aplicam requisitos de autenticação mais exigentes ao tráfego abrangido por suas regras. Um SPF ausente ou incorreto pode participar de rejeições como SMTP 550, conforme a política e as demais verificações, sem gerar necessariamente essa resposta para todos os envios.

Para uma empresa com um único domínio, o problema pode afetar uma apresentação a investidores. Para um prestador que administra 500 domínios de clientes, pode gerar uma segunda-feira cheia de chamados sobre envios ao Gmail. A revisão prévia reduz riscos, embora não evite todas as ocorrências.

Este guia explica o papel do SPF, como construir o registro, quais erros podem afetar o e-mail e como manter a configuração ao administrar muitos domínios.

O que SPF faz e o que não faz

Sender Policy Framework (SPF) é um protocolo de autorização baseado em DNS, definido no RFC 7208. Publica uma política que permite ao servidor receptor verificar quais servidores estão autorizados para determinada identidade SMTP. Não é uma proteção geral de segurança nem autentica todo o conteúdo.

Como funciona a verificação

Ao receber uma mensagem de alice@yourcompany.com, o Gmail não verifica diretamente o From visível na interface com SPF. Avalia o domínio do remetente do envelope SMTP, refletido no Return-Path na entrega, ou HELO nos casos aplicáveis. Consulta sua política DNS e compara o IP da conexão às autorizações.

Uma regra de autorização correspondente pode gerar pass. Se a avaliação chegar a SoftFail (~all) ou HardFail (-all), retorna esse resultado. Eles não ordenam automaticamente aceitação ou rejeição; existem outros resultados e o receptor decide o tratamento.

A diferença entre From e Return-Path

Os 90% citados no texto de origem são ilustrativos, não uma estatística medida. A distinção essencial é que SPF não verifica diretamente o From visível no Outlook ou Apple Mail, e sim a identidade SMTP aplicável.

O cuidado: o Mailchimp pode usar um Return-Path próprio para tratar falhas de entrega, como bounce-mc.us1.mailchimp.com. O receptor consulta então SPF do Mailchimp, não necessariamente do seu domínio. Seu registro pode ser válido e não participar desse envio.

Por isso SPF sozinho não basta para verificar a identidade visível. Veja como SPF, DKIM e DMARC interagem no guia de configuração da autenticação de e-mail.

Por que SPF continua necessário

SPF complementa DKIM e DMARC. Sua ausência pode descumprir requisitos aplicáveis; a Microsoft pode retornar 550 5.7.515 Access Denied em determinados fluxos sujeitos a suas regras de autenticação. Não atribua esse código universalmente a SPF nem dispense a revisão técnica.

Configuração básica com um provedor

Uma pequena empresa que envia com TrekMail, Google Workspace ou Microsoft 365, talvez junto a uma ferramenta de marketing, precisa de uma política SPF coerente para cada domínio SMTP utilizado. Com poucos serviços, a configuração pode ser simples, mas há um erro frequente a evitar.

Regra básica: no máximo um registro SPF aplicável por nome de domínio; se publicar SPF, ele deve ser único.

Ao adicionar um serviço, não publique um segundo TXT SPF no mesmo nome. Várias políticas SPF aplicáveis produzem PermError; o receptor não as combina. Outros TXT sem relação com SPF podem coexistir normalmente.

Componentes de um registro

Consulte o guia de configuração SPF para exemplos passo a passo. Valide os modelos com as instruções atuais dos provedores antes de publicar.

TrekMail para pequenas empresas

O texto de origem compara Google Workspace a $6-$18 por usuário ao mês, com dez usuários a $720-$2,160 por ano. Também cita Starter do TrekMail a $3.50 por mês, até 100 usuários. São referências ilustrativas, não cotações atuais. Adicionar include:spf.trekmail.net pode fazer parte do SPF se corresponder ao transporte utilizado, mas exige revisar todos os remetentes e o restante da autenticação. O modelo de preço fixo depende de limites e condições vigentes, sem garantir e-mail funcional com uma única linha.

Vários provedores: o caso das agências

Uma agência com dezenas de domínios pode encontrar HubSpot para vendas, Zendesk para suporte, Klaviyo para marketing e TrekMail para e-mail corporativo. Faça o inventário dos fluxos: nem todos precisam entrar no SPF raiz se utilizarem outros domínios de envelope.

Combine em uma política os serviços que realmente usam a mesma identidade SMTP, respeitando o limite de 10 consultas dos termos avaliados.

O limite de 10 consultas

O RFC 7208 §4.6.4 limita a 10 os mecanismos e modificadores avaliados que exigem consultas DNS, incluindo os aninhados. Não é uma contagem de pacotes DNS individuais. A restrição limita o trabalho e possíveis abusos, mas também pode afetar configurações legítimas.

Termos que consomem orçamento: include:, a, mx, exists, redirect. A lista não é completa: ptr também entra nesse orçamento.

Termos que não consomem esse orçamento: ip4:, ip6:, all

O cuidado com include aninhado

Adicionar include:bluehost.com parece consumir 1 termo. Como exemplo hipotético, se essa política também avaliar spf.protection.outlook.com e mail.bluehost.com, três termos poderiam ser avaliados. Além disso, spf.protection.outlook.com pode ter sua própria cadeia. O exemplo não representa necessariamente os registros atuais nem um percurso obrigatório de toda a cadeia.

Se a avaliação ultrapassar 10 termos pertinentes, retorna PermError, diferente de fail. O receptor pode rejeitar ou filtrar conforme sua política; não significa perda silenciosa garantida de todo o e-mail.

Como revisar o orçamento

Não adivinhe. Use a linha de comando ou um visualizador confiável. No Mac ou Linux:

dig +short txt yourdomain.com

Consulte depois os domínios de cada include: e siga a avaliação pertinente, incluindo mecanismos DNS e modificadores, não apenas include. O guia de consultas e limites do registro SPF explica a auditoria das dependências e a correção de excessos.

Flattening ou separação por subdomínios

Se a configuração se aproxima do limite de 10 ou o ultrapassa, avalie estas duas opções. Nem toda agência necessariamente chega ao limite.

Opção 1: flattening SPF, com manutenção

Flattening resolve dependências include: e as substitui por autorizações IP explícitas, como ip4:. Termos ip4: não consomem esse orçamento; centenas de IPs ainda podem trazer limites de tamanho e manutenção. Não é uma substituição mecânica válida para qualquer política, especialmente conforme as famílias de endereços e as macros.

O risco: HubSpot, Klaviyo e outros serviços podem mudar os IPs. Após alguns meses, uma lista fixa poderia ficar obsoleta, deixar de autorizar novos servidores ou manter endereços que não deveriam continuar permitidos.

Se optar por flattening, mantenha um processo confiável de detecção de mudanças, revisão das autorizações, atualização DNS, testes e reversão. A automação ajuda, mas não elimina riscos nem supervisão.

Opção 2: separação por subdomínios

Outra alternativa distribui identidades de envio entre subdomínios. SPF avalia o domínio do envelope SMTP, refletido no Return-Path; esse domínio deve mudar de fato para a separação funcionar.

O marketing precisa usar team@company.com ou pode enviar com news@marketing.company.com? Alterar apenas o From visível não basta: configure também a identidade técnica apropriada.

Domínio raiz (company.com) - Mantenha uma política adequada ao e-mail corporativo e aos serviços essenciais. Exemplo ilustrativo a verificar:

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

Subdomínio de marketing (marketing.company.com) - Configure aqui os serviços que realmente usam esse domínio de envelope. Exemplo, não registro pronto para publicação:

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

Cada avaliação de um domínio de envelope distinto tem orçamento de 10 termos; include aninhado não abre um orçamento novo. Confira alinhamento DMARC relaxado ou estrito. Separar marketing.company.com facilita a gestão, mas não protege absolutamente o endereço do diretor: receptores podem agregar reputação por domínio organizacional ou IP.

Consulte os modelos de configuração SPF e a configuração para vários remetentes. Adapte exemplos ao inventário e às instruções atuais dos provedores.

Validação após a publicação

Salvar o registro no editor DNS não encerra o trabalho. Estas verificações ajudam a confirmar publicação e envios reais.

1. Verificar a atualização DNS

Mudanças podem levar minutos ou horas, conforme publicação e caches TTL. Além do cache local, consulte um resolvedor público e os servidores autoritativos quando necessário:

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8 seleciona o DNS público do Google, que também pode ter cache. Ver o registro ali confirma essa resposta, não a atualização imediata de todos os resolvedores ou receptores.

2. Validar a sintaxe

Revise erros de sintaxe e regras que podem alterar a avaliação:

• Espaço antes de v=spf1 pode impedir a identificação correta da política.
• ip4: 192.1.1.1 - O espaço após os dois-pontos é incorreto.
• Vários mecanismos all: o primeiro sempre corresponde, e os termos seguintes não são avaliados.
• Entradas include: duplicadas podem desperdiçar orçamento no percurso avaliado, embora não sejam sempre erro sintático.

Use um validador. O assistente DNS do TrekMail pode ajudar conforme as verificações disponíveis; confira também o resultado publicado.

3. O limite de consultas sem resultado

O RFC 7208 recomenda no máximo 2 consultas sem resultado, como NXDOMAIN ou resposta sem dados pertinentes. Esse limite pode depender da implementação; ultrapassá-lo, não apenas atingi-lo, pode gerar PermError.

Por exemplo, include:spf.trekmaill.net contém uma letra adicional. Se o nome não existir, a consulta poderia representar 1 resultado vazio; porém, um include sem política SPF pode produzir PermError por si só. Dois erros de digitação não demonstram universalmente excesso do limite de consultas vazias.

Verifique as respostas DNS, não apenas o texto: uma política pode ter sintaxe correta e dependências inexistentes.

4. Analisar os cabeçalhos de um envio real

Envie para uma conta Gmail que você controla. No menu de três pontos, escolha “Mostrar original” e procure Authentication-Results adicionado pelo servidor receptor confiável. Exemplo ilustrativo:

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutral ou spf=softfail merece revisão se você esperava pass, mas pode refletir uma política intencional ou encaminhamento. Confira IP, domínio avaliado e percurso; isso não comprova falha DMARC se DKIM for válido e alinhado. Consulte a verificação do status DNS.

Erros que afetam o e-mail

Esses padrões aparecem em ocorrências de SPF. Conhecê-los ajuda a investigar, sem atribuir uma proporção medida de todos os chamados.

1. SPF e encaminhamento

SPF compara o IP da conexão com a política da identidade SMTP. Essa dependência pode complicar o encaminhamento.

Alice envia a Bob, que encaminha a Charlie. Se o remetente do envelope de Alice for mantido, Charlie compara o IP de Bob àquela política. SPF pode falhar mesmo em uma mensagem legítima, conforme autorizações e implementação do encaminhamento.

SPF sozinho não resolve todos esses casos. DKIM assina dados específicos do corpo e dos cabeçalhos; a assinatura pode sobreviver se eles não forem alterados de forma incompatível. Deve continuar válida e alinhada para DMARC. SRS pode permitir SPF para o domínio do intermediário sem restaurar o alinhamento com o From original.

Veja a interação entre SPF, DKIM e SRS no encaminhamento de e-mail de domínio, sem presumir posicionamento garantido.

2. O mecanismo ptr

No início dos anos 2000, usava-se o mecanismo ptr, baseado em DNS reverso:

v=spf1 ptr -all

O RFC desaconselha ptr pelo custo e pelas limitações, mas ele continua definido no protocolo. Isso não comprova que o Gmail ignore toda política que o inclui. Ao herdar ptr, faça inventário das autorizações e teste sua substituição; não o confunda com o PTR do servidor, que tem outra função.

3. O risco de +all

Este exemplo ilustra uma configuração perigosa; não o publique:

v=spf1 include:spf.google.com +all

Os qualificadores significam:

• -all = HardFail para IPs cuja avaliação chega a esse termo; o receptor decide se rejeita.
• ~all = SoftFail para esses IPs; não impõe aceitação com marcação.
• +all = Pass para qualquer IP cuja avaliação alcance esse termo.

+all pode autorizar IPs arbitrários para a identidade SPF avaliada e facilitar abuso. Erros ou regras negativas anteriores ainda podem intervir e o receptor aplica outras verificações; não garante uma falsificação bem-sucedida. Uma política com +all precisa ser revisada. Substitua +all por autorizações limitadas, como -all, após inventário e testes dos remetentes legítimos.

4. Return-Path de serviços externos

Uma ferramenta de marketing pode usar seu domínio de falhas de entrega sem que Return-Path esteja ausente. Domínio de rastreamento não é necessariamente domínio de envelope personalizado. Para SPF alinhado, o domínio avaliado deve se alinhar ao From, por domínio organizacional no modo relaxado ou exatamente no estrito. DMARC também pode passar com uma assinatura DKIM válida e alinhada.

Alguns provedores permitem um subdomínio de retorno, como bounce.yourcompany.com. Confira suporte, instruções e modo de alinhamento; não é sempre obrigatório se DKIM já oferece um caminho alinhado. Consulte alinhamento DMARC e reputação do domínio.

Geradores: utilidade e cuidados

Geradores SPF variam em qualidade e alcance. Podem ajudar, mas é necessário revisar o que verificam e as informações fornecidas.

Ferramentas úteis

Visualizadores de cadeias include: ajudam a auditar dependências e termos avaliados. Algumas ferramentas de entregabilidade de e-mail oferecem essa função; confirme se cobrem o percurso pertinente.

Validadores de sintaxe detectam certos erros de separadores e caracteres. Dependências ausentes e consultas vazias também exigem avaliação DNS, não apenas análise do texto.

Pontos que exigem revisão

Um assistente de um clique pode gerar ?all, que retorna Neutral para os IPs que chegam a esse termo. Não equivale a pass nem comprova universalmente desconfiança. Escolha -all ou ~all conforme inventário, testes e objetivos; não presuma que o padrão seja adequado.

Divisão de cadeias TXT: cada cadeia admite até 255 octetos. Um SPF longo pode ocupar várias cadeias entre aspas em um único registro. Elas são concatenadas sem inserir espaços e devem conservar os separadores necessários:

• Estrutura correta: "v=spf1 include:a..." "include:b... -all" representa duas cadeias em um registro, mas esse exemplo abreviado precisa de um separador apropriado na concatenação.
• Incorreto: dois TXT SPF independentes causam PermError.

Confira como o provedor DNS publica as cadeias e valide o texto concatenado. Um gerador pode dividi-las incorretamente e produzir sintaxe inválida.

Consulte o guia de ferramentas e configuração SPF para orientar a revisão, sem presumir que toda ferramenta citada esteja validada para seu caso.

Configuração e centralização com TrekMail

As grandes suítes oferecem funções úteis a alguns clientes e menos relevantes a outros. Alguns planos cobram por usuário; compare recursos, contratos e necessidades sem assumir que todas as funções adicionais são desnecessárias.

Se TrekMail for o único transporte autorizado, este padrão pode servir de exemplo após verificar as instruções atuais:

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

Apenas hospedar um domínio no TrekMail não torna essa política completa: podem existir outros remetentes ou SMTP externo. A infraestrutura gerenciada pode cuidar de IP, PTR e recursos de feedback dentro de seu alcance. Isso não elimina o aumento gradual dos fluxos, a revisão de abuso nem garante entrega.

Um prestador com 50 domínios que usam exclusivamente o mesmo transporte poderia publicar 50 políticas equivalentes. Repetir uma configuração cem vezes facilita a padronização, mas cada cliente precisa de inventário e validação próprios. O modelo sem cobrança por assento depende do plano e não elimina diferenças legítimas entre domínios.

Para migrar, consulte a visão geral da migração IMAP e os registros DNS necessários. IMAP copia dados acessíveis das caixas; MX, SPF, DKIM e DMARC são preparados separadamente, com testes e plano de transição. A importação em massa de domínios pode estar disponível conforme painel e plano: consulte como importar domínios.

Boas práticas para SPF

Os requisitos de autenticação se tornaram mais exigentes em 2024 para determinados serviços e volumes. Um registro SPF adequado ajuda a cumpri-los, mas sua ausência ou validade não determina sozinha o destino de todo e-mail legítimo.

Resumo das verificações:

1. Audite a publicação. Execute dig +short txt yourdomain.com e diferencie SPF de outros TXT. Vários SPF aplicáveis, não simplesmente vários TXT, causam PermError.
2. Combine as autorizações pertinentes. Uma política por nome para serviços que usam esse domínio de envelope, com cadeias TXT corretamente concatenadas.
3. Conte os termos avaliados. Use um visualizador. Acima de 10, considere reduzir dependências ou separar identidades por subdomínio; flattening exige manutenção.
4. Avalie -all. Considere mudar de ~all após inventário e testes. Substitua +all por autorizações limitadas sem interromper remetentes legítimos.
5. Confira Return-Path e alinhamento. Para Mailchimp ou HubSpot, avalie um domínio de falhas de entrega personalizado quando necessário. DMARC exige SPF aprovado e alinhado ou uma assinatura DKIM válida e alinhada.
6. Não pare no SPF. Encaminhamento pode afetar SPF e também DKIM se alterar dados assinados. Configure os três: SPF, DKIM e DMARC.

Um registro ilustrativo de 50 bytes merece o mesmo cuidado que um longo. Valide a configuração inicial e após mudanças; uma revisão anual pode complementar o acompanhamento, não substituí-lo.

Centralize o DNS quando fizer sentido. Confira a opção gratuita do TrekMail e as condições atuais de sua hospedagem de preço fixo e ferramentas SPF, DKIM e DMARC.