Provedores de serviços gerenciados operam na interseção entre escala e complexidade.

Um erro de configuração de SPF que afeta um domínio pode criar um problema de entregabilidade. O mesmo erro incorporado em uma configuração compartilhada de MSP pode afetar dezenas ou centenas de domínios de clientes de uma vez.

Um novo serviço de envio pode levar domínios além do limite de consultas DNS do SPF. Uma migração pode deixar IPs de envio legítimos não autorizados. Uma dependência de terceiros esquecida pode se transformar em um permerror de SPF. E um registro SPF achatado manualmente pode silenciosamente se tornar obsoleto conforme os fornecedores mudam sua infraestrutura.

Para MSPs e MSSPs, o SPF, portanto, não é simplesmente um registro DNS a ser configurado durante a integração. É uma dependência que precisa permanecer precisa conforme os ambientes dos clientes mudam.

Este guia examina cinco falhas de configuração de SPF que os MSPs devem detectar antes que se tornem incidentes de entregabilidade em toda a base de clientes.

A aprovação do SPF não significa automaticamente que o DMARC passa.

O SPF autentica o domínio RFC5321.MailFrom — comumente representado pelo Return-Path. Para que o SPF satisfaça o DMARC, o domínio SPF autenticado também deve estar alinhado com o domínio no cabeçalho RFC5322.From visível. Alternativamente, uma assinatura DKIM válida e alinhada pode satisfazer o DMARC mesmo quando o SPF não passa.

I. 1. Excedendo o Limite de 10 Consultas do SPF

O que acontece

O SPF impõe um limite rígido sobre termos que causam consultas DNS avaliados durante uma verificação de SPF.

Sob a RFC 7208, os seguintes mecanismos e modificadores contam para o limite:

• include
• a
• mx
• ptr
• exists
• redirect

Avaliações aninhadas também contam.

Se a avaliação do SPF exceder 10 termos que causam consultas DNS, a implementação de SPF deve retornar permerror.

Isso se torna particularmente perigoso em ambientes MSP porque um registro SPF que parece simples pode depender de múltiplos registros aninhados.

Um cliente pode autorizar:

v=spf1 include:spf.msp-example.com include:marketing.example.net include:crm.example.net ~all

Esses três includes visíveis não representam necessariamente apenas três consultas SPF. Cada registro incluído pode conter mecanismos adicionais que causam consultas DNS.

Por que os MSPs enfrentam isso

O orçamento de consultas frequentemente cresce gradualmente conforme os clientes adicionam:

• Microsoft 365 ou Google Workspace
• plataformas de marketing
• sistemas de CRM
• plataformas de help desk
• provedores de e-mail transacional
• gateways de segurança
• sistemas ERP ou de faturamento
• serviços legados que nunca foram removidos

Um domínio pode operar com segurança por anos e então exceder o limite de SPF imediatamente após um remetente adicional ser autorizado.

Impacto na entregabilidade

Um permerror de SPF significa que o SPF não pode fornecer um resultado autenticado bem-sucedido para aquela mensagem.

Se não houver uma assinatura DKIM alinhada válida para satisfazer o DMARC, a mensagem pode falhar no DMARC.

O impacto prático pode incluir:

• permerror de SPF aparecendo nos resultados de autenticação
• falhas de DMARC onde o DKIM não fornece uma aprovação alinhada
• colocação na pasta de spam
• rejeição dependendo da política do receptor e outros sinais
• entrega inconsistente entre provedores de caixa de correio

Como os MSPs devem detectar isso

Não conte apenas as declarações include: visíveis no registro SPF de nível superior.

Avalie a árvore de dependências completa do SPF, incluindo aninhados:

include
a
mx
exists
redirect

O mecanismo ptr também conta para o limite, embora a RFC 7208 explicitamente desencoraje seu uso.

Para MSPs gerenciando grandes portfólios, a validação de consultas deve acontecer antes de cada mudança de SPF, não após os problemas de entrega aparecerem.

Exemplo de cenário de falha

Um MSP adiciona um novo gateway de segurança de e-mail a uma configuração SPF compartilhada.

O gateway introduz vários termos adicionais que causam consultas DNS através de suas próprias dependências SPF.

Domínios já próximos do limite de 10 termos ultrapassam o limite imediatamente.

Nada sobre os aplicativos dos clientes mudou. Seus e-mails continuam sendo enviados normalmente. Mas os sistemas receptores avaliando o SPF agora retornam permerror.

Uma mudança de configuração compartilhada tornou-se um problema de autenticação de múltiplos clientes.

II. 2. A Infraestrutura de Envio Não Corresponde Mais ao SPF

O que acontece

MSPs frequentemente centralizam e-mail de saída através de:

• relays SMTP
• gateways de e-mail em nuvem
• plataformas de segurança
• infraestrutura de e-mail transacional
• serviços de envio compartilhados

Um registro SPF do cliente pode autorizar essa infraestrutura através de um include:

v=spf1 include:spf.msp-example.com ~all

Os problemas começam quando a infraestrutura muda, mas a autorização SPF não.

Causas típicas incluem:

1. migração para novos endereços IP de envio;
2. mudança entre data centers ou regiões de nuvem;
3. substituição de um relay SMTP ou gateway de segurança;
4. introdução de um novo provedor de saída;
5. roteamento de apenas parte do tráfego do cliente através da nova infraestrutura; ou
6. deixar a infraestrutura antiga autorizada após a migração.

Modo de falha

O SPF avalia se o IP conectado está autorizado para o domínio RFC5321.MailFrom.

Se o IP de envio atual não estiver autorizado pela política SPF daquele domínio, o SPF não passará.

Se também não houver uma aprovação DKIM alinhada, o DMARC falha.

Essa distinção importa:

Falha de SPF não equivale automaticamente a falha de DMARC.

O DMARC pode passar através de uma aprovação SPF alinhada ou uma aprovação DKIM alinhada.

Impacto na entregabilidade

A deriva de infraestrutura pode criar:

• falhas de SPF de remetentes legítimos
• falhas de DMARC quando o DKIM está indisponível, quebrado ou desalinhado
• entrega inconsistente entre diferentes sistemas de envio
• aumento de filtragem
• rejeição por alguns sistemas receptores
• relatórios de clientes de que apenas certos aplicativos ou tipos de mensagem estão falhando

Como os MSPs devem detectar isso

Compare:

IPs de envio observados

contra:

Endereços IP atualmente autorizados pelo SPF

Relatórios agregados de DMARC são particularmente úteis aqui porque revelam infraestrutura que está realmente enviando e-mail usando o domínio do cliente.

Para um MSP, a questão não deve ser simplesmente:

“O registro SPF é sintaticamente válido?”

Deve também ser:

“O registro SPF autoriza a infraestrutura que está realmente enviando e-mail hoje?”

III. 3. A Lacuna de Autenticação de Subdomínio

O que acontece

Uma das concepções erradas mais persistentes sobre SPF é que a política SPF de um domínio pai se aplica automaticamente aos seus subdomínios.

Não se aplica.

Um registro SPF publicado em:

example.com

não é automaticamente a política SPF para:

bounce.example.com
support.example.com
billing.example.com

A política SPF é avaliada para o domínio usado como identidade SPF — normalmente o domínio RFC5321.MailFrom.

Por exemplo, se um serviço envia usando:

Return-Path: [email protected]

A avaliação SPF diz respeito a billing.example.com.

A política SPF em example.com não é automaticamente herdada.

Modo de falha

Se o domínio RFC5321.MailFrom não tiver um registro SPF aplicável, o SPF normalmente retorna none.

Isso é diferente de fail, softfail ou permerror.

Como o SPF não produziu um identificador autenticado, ele não pode fornecer a aprovação SPF alinhada necessária para o DMARC.

O DMARC ainda pode passar se a mensagem carregar uma assinatura DKIM válida cujo domínio de assinatura se alinhe com o domínio From visível.

Por que os MSPs encontram isso

Subdomínios são frequentemente introduzidos por sistemas de terceiros:

bounce.client.com
mail.client.com
billing.client.com
support.client.com
notifications.client.com

Estes podem ser usados por:

• plataformas de suporte ao cliente
• CRMs
• plataformas de marketing
• sistemas de faturamento
• AWS SES
• provedores de e-mail transacional
• serviços de notificação de aplicativos

O domínio raiz pode, portanto, ter SPF, DKIM e DMARC perfeitamente válidos enquanto um caminho de envio separado usando um subdomínio está incorretamente autenticado.

Como os MSPs devem detectar isso

Primeiro, identifique os domínios que estão sendo realmente usados como domínios RFC5321.MailFrom / Return-Path.

Em seguida, verifique o SPF para esses domínios.

Por exemplo:

dig TXT bounce.client.com
dig TXT billing.client.com
dig TXT notifications.client.com

A questão importante não é simplesmente se um subdomínio existe.

É se esse subdomínio está sendo usado como uma identidade SPF para e-mail de saída e, se sim, se a política SPF correspondente autoriza corretamente o remetente.

Exemplo de cenário de falha

Um cliente introduz uma nova plataforma transacional usando:

bounce.client.com

como seu domínio Return-Path.

O MSP verifica o SPF em:

client.com

e assume que a configuração está completa.

Mas bounce.client.com não tem política SPF.

O SPF, portanto, não pode autenticar aquela identidade de envio. Se a configuração DKIM da plataforma também estiver faltando ou desalinhada, o DMARC falha.

A configuração do domínio raiz estava correta.

A identidade de envio não estava.

IV. 4. A Dependência SPF de Terceiros Que Quebra

O que acontece

Registros SPF modernos comumente dependem de serviços de terceiros:

v=spf1 include:spf.provider-a.example include:spf.provider-b.example ~all

Cada include: cria uma dependência externa.

O proprietário do domínio está efetivamente confiando em outra organização para manter infraestrutura SPF válida.

Problemas surgem quando:

1. um fornecedor desativa um include SPF antigo;
2. uma organização migra entre produtos;
3. o domínio referenciado desaparece;
4. o fornecedor publica um registro SPF inválido;
5. um serviço legado é desligado sem que o registro SPF do cliente seja atualizado.

Modo de falha

A RFC 7208 define comportamento específico para include:.

Se a avaliação do domínio incluído produzir none — por exemplo, porque nenhum registro SPF existe lá — a avaliação do include produz permerror.

Isso significa que uma dependência de terceiros quebrada pode afetar a avaliação SPF do domínio do cliente mesmo que ninguém tenha alterado o registro DNS do cliente.

Impacto na entregabilidade

Uma dependência quebrada pode causar:

• permerror de SPF
• perda de uma aprovação SPF alinhada para DMARC
• falha de DMARC quando o DKIM alinhado não passa
• autenticação inconsistente entre portfólios de clientes
• problemas súbitos de entrega sem nenhuma mudança DNS local óbvia

Isso é especialmente importante para MSPs porque o mesmo include de terceiros pode aparecer em muitos domínios de clientes.

Uma dependência externa pode, portanto, criar uma falha correlacionada em todo o portfólio.

Como os MSPs devem detectar isso

As dependências SPF devem ser monitoradas continuamente.

Os MSPs devem saber:

• quais fornecedores aparecem nos registros SPF dos clientes;
• quais domínios esses fornecedores requerem;
• quais clientes dependem de cada fornecedor;
• se essas dependências ainda resolvem corretamente; e
• se seus conteúdos SPF mudaram.

Um registro DNS estar inalterado não significa que a política SPF efetiva está inalterada.

Suas dependências podem ter mudado por baixo dele.

V. 5. O Achatamento Estático de SPF Torna-se Obsoleto

O que acontece

O achatamento de SPF às vezes é usado para reduzir consultas DNS.

Em vez de manter um include de terceiros:

v=spf1 include:spf.vendor.example ~all

os endereços IP atuais por trás daquele include são resolvidos e colocados diretamente no registro SPF:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 ~all

Como os mecanismos ip4 e ip6 não contam para o limite de 10 termos de consulta DNS do SPF, o achatamento pode reduzir a pressão de consulta.

Mas o achatamento estático transfere a responsabilidade de manter esses endereços atualizados do fornecedor para o administrador do domínio.

O problema

Provedores de e-mail de terceiros podem mudar sua infraestrutura de envio.

Eles podem:

• adicionar faixas de IP;
• remover faixas de IP;
• expandir para novas regiões;
• mover infraestrutura; ou
• mudar fornecedores subjacentes.

Se o MSP copiou os endereços IP do fornecedor há seis meses e nunca os atualiza, o registro SPF achatado torna-se um snapshot obsoleto.

Modo de falha

E-mail originado de um IP de fornecedor recém-introduzido pode não corresponder mais ao registro SPF achatado.

O SPF então falha em autenticar aquele caminho de envio.

Novamente, o DMARC não falha necessariamente: uma assinatura DKIM alinhada válida ainda pode produzir uma aprovação de DMARC.

Mas o domínio perdeu um de seus caminhos de autenticação.

Por que isso importa para MSPs

O achatamento estático pode converter um problema operacional — consultas DNS excessivas — em outro:

sincronização contínua de infraestrutura de envio de terceiros.

Em um grande portfólio de clientes, manter manualmente registros achatados rapidamente se torna impraticável.

Melhor abordagem operacional

Se o achatamento for usado, ele deve ser acompanhado de monitoramento contínuo e sincronização automatizada.

O MSP deve ser capaz de detectar quando a política SPF autoritativa de um provedor upstream muda e atualizar a autorização efetiva de acordo.

O achatamento deve ser tratado como um processo gerenciado ativamente, não como uma mudança DNS única.

Por Que os Problemas de SPF Se Tornam Mais Perigosos na Escala de MSP

O protocolo SPF subjacente é o mesmo se uma organização gerencia um domínio ou mil.

O risco operacional não é.

MSPs introduzem dependências compartilhadas:

Modelos SPF compartilhados
        ↓
Infraestrutura de envio compartilhada
        ↓
Serviços de terceiros compartilhados
        ↓
Automação DNS compartilhada
        ↓
Centenas de domínios gerenciados

Um erro no topo dessa cadeia pode se propagar por todo o portfólio.

Isso torna a governança de SPF tão importante quanto a configuração de SPF.

VI. O Que os MSPs Devem Documentar

1. Inventário de Dependências SPF

Mantenha um registro de:

• cada provedor de e-mail de saída;
• sua autorização SPF necessária;
• clientes usando aquele provedor;
• domínios Return-Path associados;
• dependências SPF aninhadas; e
• consumo atual de consultas DNS.

Isso torna possível entender o raio de impacto de uma mudança de provedor.

2. Fontes de Envio Reais

A configuração DNS sozinha não mostra tudo que está usando o domínio de um cliente.

Compare a autorização SPF contra infraestrutura de envio observada a partir de telemetria de autenticação e relatórios agregados de DMARC.

Fontes desconhecidas devem ser investigadas.

Fontes legítimas podem precisar de autorização.

Fontes não autorizadas podem indicar spoofing ou um serviço não aprovado.

3. Mapeamento de Return-Path e Subdomínio

Documente as identidades SPF reais usadas por cada serviço de envio.

Por exemplo:

Microsoft 365
From: client.com
Return-Path: client.com

Plataforma Transacional
From: client.com
Return-Path: bounce.client.com

Plataforma de Marketing
From: client.com
Return-Path: marketing.client.com

Isso torna problemas de autenticação e alinhamento de DMARC muito mais fáceis de diagnosticar.

4. Controle de Mudanças de SPF

Antes de implantar uma mudança de SPF, valide:

• total de termos que causam consultas DNS;
• includes aninhados;
• autorização de IP de envio;
• domínios Return-Path;
• dependências de terceiros;
• sintaxe SPF; e
• alinhamento DMARC esperado.

Para configurações compartilhadas, calcule quais domínios de clientes serão afetados antes da implantação.

5. Remoção de Remetentes Legados

Registros SPF tendem a acumular serviços antigos.

Cada autorização desnecessária:

• aumenta a complexidade;
• pode consumir consultas DNS;
• expande o conjunto de infraestrutura autorizada a enviar; e
• torna a solução de problemas futuros mais difícil.

Descomissionar um serviço deve incluir remover sua autorização SPF.

SPF É Apenas Uma Parte do DMARC

O SPF não deve ser avaliado isoladamente.

Sob o DMARC, o domínio From visível deve se alinhar com pelo menos um identificador autenticado com sucesso.

Em termos práticos:

APROVAÇÃO de SPF Alinhado
        OU
APROVAÇÃO de DKIM Alinhado
        ↓
     APROVAÇÃO de DMARC

Se nenhum produzir uma aprovação alinhada:

Nenhuma APROVAÇÃO de SPF alinhado
        +
Nenhuma APROVAÇÃO de DKIM alinhado
        ↓
     FALHA de DMARC

Esta distinção é crítica ao solucionar problemas de entregabilidade.

Um erro de SPF não significa automaticamente que o DMARC falhou.

Da mesma forma, uma aprovação de SPF não significa automaticamente que o DMARC passou se o domínio SPF autenticado não se alinhar com o domínio From visível.

Os requisitos atuais de DMARC são definidos pela RFC 9989, publicada em maio de 2026, que substitui a especificação original de DMARC na RFC 7489.

Como o Skysnag Ajuda MSPs a Gerenciar SPF em Escala

Gerenciar SPF manualmente torna-se cada vez mais difícil conforme o número de clientes, serviços de envio e dependências DNS cresce.

A plataforma MSP da Skysnag foi projetada para centralizar e automatizar o gerenciamento de autenticação de e-mail em ambientes de clientes.

VII. Gerenciamento Multi-Tenant

Gerencie domínios de clientes através de um ambiente MSP centralizado em vez de solucionar problemas de cada domínio independentemente.

Isso fornece às equipes MSP visibilidade em nível de portfólio sobre configuração de autenticação e atividade de envio.

VIII. Descoberta Automatizada de Remetentes

O Skysnag identifica fontes de envio de saída para que os MSPs possam entender qual infraestrutura está realmente usando domínios de clientes.

Isso ajuda a distinguir remetentes legítimos mas não documentados de fontes não autorizadas.

IX. Hospedagem e Otimização de SPF

O Skysnag fornece gerenciamento e otimização de SPF automatizados projetados para prevenir falhas de DNS e reduzir os riscos operacionais associados à manutenção manual de configurações SPF complexas.

X. Achatamento de SPF e Prevenção de Deriva

Onde a otimização de SPF requer achatamento, o gerenciamento contínuo é crítico.

Os recursos de hospedagem e otimização de SPF do Skysnag incluem achatamento automatizado e prevenção de deriva, reduzindo o risco de que a autorização estática se torne obsoleta conforme a infraestrutura de envio muda.

XI. Análise de DMARC Centralizada

Dados agregados de DMARC fornecem visibilidade sobre resultados de autenticação entre fontes de envio.

Combinado com gerenciamento centralizado, isso permite que os MSPs identifiquem problemas de autenticação sem investigar manualmente sistemas de e-mail individuais.

XII. Gerenciamento Completo de Autenticação de E-mail

O SPF é apenas um componente da autenticação de e-mail moderna.

O Skysnag permite que os MSPs gerenciem:

• DMARC
• SPF
• DKIM
• MTA-STS
• TLS-RPT
• BIMI

de um ambiente unificado.

Principais Conclusões

O SPF tem um limite rígido de 10 termos de consulta DNS.
Excedê-lo resulta em permerror. Dependências SPF aninhadas contam para esse limite.

As políticas SPF não herdam automaticamente de domínios pai.
Os MSPs precisam entender os domínios RFC5321.MailFrom reais usados pelos serviços de envio de seus clientes.

Um registro SPF válido ainda pode autorizar a infraestrutura errada.
A configuração deve ser comparada com fontes de envio reais.

Includes SPF de terceiros são dependências externas.
Uma mudança DNS do lado do fornecedor pode afetar a autenticação do cliente sem qualquer mudança no próprio registro SPF do cliente.

O achatamento estático de SPF requer manutenção contínua.
Mudanças na infraestrutura do fornecedor podem tornar autorizações de IP previamente corretas obsoletas.

Falha de SPF não é automaticamente falha de DMARC.
DKIM alinhado pode satisfazer independentemente o DMARC.

Na escala de MSP, a visibilidade importa tanto quanto a configuração.
Modelos e infraestrutura compartilhados transformam erros DNS individuais em riscos operacionais de todo o portfólio.

XIII. Gerencie SPF em Todo o Seu Portfólio de Clientes

Problemas de SPF tornam-se mais difíceis de detectar — e mais caros de corrigir — conforme o número de domínios gerenciados cresce.

O Skysnag oferece aos MSPs e MSSPs gerenciamento centralizado de autenticação de e-mail, descoberta automatizada de remetentes, otimização de SPF, visibilidade de DMARC e gerenciamento multi-tenant projetado para escala.

Previna a deriva de autenticação antes que ela se torne um incidente de entregabilidade do cliente.

Explore o Skysnag para MSPs