Como criar um registro SPF para o Office 365 sem prejudicar outros serviços de e-mail?

Para criar um registro SPF para o Office 365 sem prejudicar outros serviços de e-mail, faça o inventário de todos os remetentes legítimos, monte um único registro v=spf1 que inclua include:spf.protection.outlook.com além dos seus outros provedores e IPs, mantendo-se abaixo do limite de 10 consultas DNS (usando subdomínios ou flattening, se necessário), implemente com um qualificador suave (~all), teste e monitore por meio de dados SPF/DMARC e automatize a manutenção com o AutoSPF para evitar desvios.

Conforme a RFC 7208, a avaliação de SPF é limitada a 10 consultas DNS de mecanismo e 2 consultas nulas (void) por verificação — exceder qualquer um dos limites produz um PermError que reprova a autenticação de todas as mensagens do domínio.

Contexto e histórico

O Sender Policy Framework (SPF) é uma lista de autorização baseada em DNS que informa aos destinatários quais IPs e serviços podem enviar e-mails em nome do seu domínio. O Microsoft 365 (Exchange Online) exige que você inclua sua infraestrutura SPF publicada com include:spf.protection.outlook.com, mas muitos domínios também enviam a partir de um Exchange on-premises, plataformas de marketing, CRMs, sistemas de tickets e aplicações web. Se você publicar um SPF que cobre apenas o Office 365, outros serviços legítimos podem ser rejeitados; se tentar incluir tudo de forma ingênua, você pode exceder o rígido limite de 10 consultas do SPF e comprometer totalmente a avaliação.

O caminho mais seguro é metódico: descubra todas as fontes que enviam, construa um registro preciso com o Office 365 e todas as demais fontes, otimize para permanecer dentro do orçamento de consultas, faça a implantação em etapas com cuidado e mantenha-o atualizado. Se você está começando do zero, nosso passo a passo sobre como configurar um registro SPF cobre os fundamentos. O AutoSPF simplifica cada uma dessas etapas ao descobrir remetentes a partir de dados de e-mail reais, modelar a contagem de consultas em tempo real, aplicar flattening automático quando necessário e monitorar os resultados para que você possa migrar para uma política estrita com confiança.

Faça o inventário de todos os serviços que enviam e-mails em nome do seu domínio

Um inventário completo de remetentes evita “quebras” quando você migra para o Office 365 ou faz otimizações para ele.

O que listar e como documentar

• On-premises: IP(s) público(s) de NAT do Exchange ou de relays SMTP, smart hosts, scanners e MFPs

• Microsoft 365: Exchange Online Protection (EOP) via include:spf.protection.outlook.com

• Plataformas de terceiros: ESPs (ex.: SendGrid, Mailchimp), CRMs (ex.: Salesforce), tickets (ex.: Zendesk), suporte/chat, RH/folha de pagamento e qualquer aplicação que envie em nome do seu domínio

• Infraestrutura web: CMS/formulários de contato, plataformas de e-commerce, funções serverless

• Caminhos especiais: listas de distribuição, encaminhadores e remetentes de subdomínios (ex.: bounce@, newsletter@, noreply@)

Métodos para descobrir todas as fontes

• Relatórios agregados DMARC (RUA): enumere os IPs e domínios de origem observados enviando em seu nome; reúna pelo menos 14 a 30 dias de dados

• Rastreamento de mensagens (Message Trace) e cabeçalhos do Microsoft 365: observe Authentication-Results e Received-SPF para encontrar IPs/serviços

• Painéis dos provedores: a maioria dos ESPs mostra o(s) domínio(s) que eles estão configurados para enviar e seu include SPF

• Verificações de DNS e infraestrutura: faça dig/nslookup dos seus registros MX e A (caso você dependa de a: ou mx: no SPF), tabelas de NAT do firewall para saída SMTP/25 e 587

• Entrevistas com as equipes: marketing, suporte, produto e TI muitas vezes controlam mailers diferentes

Conexão com o AutoSPF: o AutoSPF ingere o DMARC RUA automaticamente, mapeia os IPs de origem para provedores conhecidos e constrói um inventário vivo. Ele sinaliza “remetentes desconhecidos” e sugere adições ao SPF ou segmentação por subdomínio, poupando semanas de descoberta manual.

Monte um único SPF que inclua o Office 365 e tudo mais (sem exceder 10 consultas)

O cerne é um único registro TXT na raiz (example.com) com exatamente uma política SPF. O mecanismo publicado pela Microsoft é include:spf.protection.outlook.com. Você pode montar esse registro com nosso gerador de registros SPF.

Sintaxe recomendada pela Microsoft para o Exchange Online

• Somente Office 365:
• v=spf1 include:spf.protection.outlook.com -all

Esta é a orientação canônica da Microsoft para o Exchange Online quando não há outros remetentes.

Exemplos concretos de registros SPF

• Office 365 + IPs públicos on-premises:

• v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:spf.protection.outlook.com -all

• Office 365 + on-premises + vários remetentes de terceiros:

• v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all

• Office 365 + Amazon SES (regionalizado) + Mailchimp:

• v=spf1 include:spf.protection.outlook.com include:amazonses.com include:servers.mcsv.net ~all

• Subdomínio delegado para marketing mantendo a raiz enxuta:

• Raiz (example.com): v=spf1 include:spf.protection.outlook.com -all

• Marketing (news.example.com): v=spf1 include:sendgrid.net include:servers.mcsv.net -all

Observação: sempre confirme na documentação de cada provedor o host de include atual. Alguns provedores oferecem includes específicos por região ou conta que reduzem as consultas.

O orçamento de 10 consultas e como ficar abaixo dele

O SPF conta os mecanismos que fazem consultas DNS em relação a um limite rígido de 10 ao longo de toda a cadeia de avaliação (includes, redirects, a, mx, ptr, exists e macros). ip4, ip6 e all não disparam consultas.

• Custos comuns de consulta:

• include: 1 consulta cada (mais o que quer que eles próprios incluam)

• mx: até o número de hosts MX (mais consultas A/AAAA)

• a: 1 (mais uma possível cadeia de CNAME)

• redirect=: 1 (substitui a política; ainda dentro do mesmo orçamento de 10)

• Mantenha o “all” por último; ele não adiciona consultas.

Estratégias práticas:

• Prefira ip4/ip6 para seus próprios hosts estáticos em vez de mx ou a

• Minimize os includes de provedores; remova fornecedores legados

• Segmente remetentes com muitas consultas para subdomínios (ex.: news.example.com) para que o SPF da raiz permaneça enxuto

• Use flattening gerenciado para converter includes nos conjuntos de IP atuais, com atualização automática

Conexão com o AutoSPF: o AutoSPF exibe um contador de consultas ao vivo enquanto você edita, alerta quando includes indiretos se expandem além de 10 e pode publicar um registro com flattening seguro e atualização automática, para que você nunca sofra desvios quando os provedores mudam de IP.

Lide com implantações híbridas do Exchange sem danos colaterais

O modo híbrido muda qual IP de fato envia para a internet, então modele seu fluxo de e-mail antes de publicar o SPF.

Se o on-premises faz relay para o EOP (e o EOP entrega)

• Caminho de saída: On-premises → EOP → destinatários na internet

• IP de conexão no destinatário: EOP

• Orientação de SPF: include:spf.protection.outlook.com é suficiente; você não precisa dos seus IPs on-premises no SPF

• Por quê: o SPF verifica o IP do cliente SMTP do último salto até o destinatário, que é o EOP neste desenho

Se o on-premises entrega diretamente à internet (ou as aplicações entregam)

• Caminho de saída: On-premises/aplicação → internet

• IP de conexão: seu(s) NAT(s) público(s)

• Orientação de SPF: adicione ip4/ip6 para cada IP de saída que possa enviar em nome do seu domínio, além de include:spf.protection.outlook.com

Smart hosts e conectores

• Smart host de terceiros (ex.: gateways de segurança) que entregam por você: inclua o SPF desse provedor ou adicione os IPs de saída dele

• Múltiplos pontos de saída: considere consolidar em menos NATs ou publicar todos em ip4/ip6

O tráfego de entrada não altera o SPF

O roteamento de entrada (MX para o EOP ou on-premises) não afeta o SPF do seu domínio, mas se você usar mx no SPF isso adicionará consultas; prefira ip4/ip6 explícitos para os remetentes.

Conexão com o AutoSPF: a “modelagem de fluxo” do AutoSPF permite declarar se o on-premises roteia através do EOP ou envia diretamente; ele então gera o SPF correto e destaca quaisquer IPs não cobertos encontrados nos dados DMARC.

Implante com segurança: qualificadores, testes, monitoramento, rollback e armadilhas comuns

Escolha o qualificador SPF certo durante a implantação

• ~all (SoftFail): recomendado para a implantação inicial; os destinatários aceitam o e-mail, mas marcam o SPF como softfail quando não há correspondência

• -all (Fail): aplique somente depois de ter certeza de que todas as fontes legítimas estão cobertas

• ?all (Neutral): útil para descoberta inicial se você ainda não tem DMARC, mas oferece pouca aplicação

• é um permitir implícito; omita-o por concisão (ex.: ip4: em vez de +ip4:)

Plano de implantação seguro:

1. Reduza o TTL do DNS do registro TXT para 300-600 segundos 24 horas antes das mudanças
2. Publique um registro abrangente com ~all
3. Habilite o DMARC p=none e colete relatórios por 2 a 4 semanas; confirme ≥98-99% de aprovação para o tráfego legítimo
4. Mude o DMARC para quarantine (pct=25→100 ao longo do tempo)
5. Altere o SPF para -all quando o DMARC mostrar cobertura quase perfeita e as configurações de terceiros estiverem estáveis
6. Eleve o TTL de volta para 1-4 horas quando estiver estável

Como você verifica e monitora?

• DNS: dig/nslookup -type=TXT example.com para verificar um único registro SPF

• Mensagens ao vivo: verifique os cabeçalhos Authentication-Results e Received-SPF; procure por spf=pass dos destinatários

• Ferramentas da Microsoft: rastreamento de mensagens no centro de administração do Exchange; logs dos conectores de saída

• Validadores online: avaliam a contagem de consultas e a expansão

• DMARC RUA: acompanhe as tendências de aprovação/reprovação por fonte; identifique IPs desconhecidos

Conexão com o AutoSPF: o AutoSPF oferece um simulador “what-if” para testar registros antes de publicar, análise contínua de DMARC com atribuição de fonte e alertas caso as reprovações de SPF disparem após uma mudança; o rollback com um clique restaura o registro anterior.

Quais são os erros de configuração comuns e como corrigi-los?

• Vários registros TXT de SPF no mesmo hostname

• Sintoma: “PermError: multiple SPF records”

• Correção: consolide os registros SPF mesclando todos os mecanismos em um único registro v=spf1; exclua os duplicados

• Exceder 10 consultas

• Sintoma: “PermError: too many DNS lookups”

• Correção: remova fornecedores não utilizados, substitua mx/a por ip4/ip6, segmente para subdomínios ou faça flattening com o AutoSPF

• Sintaxe incorreta de include/ip4/ip6

• Sintoma: “PermError: invalid SPF record” ou incompatibilidade silenciosa

• Correção: valide a sintaxe; garanta que o CIDR esteja correto (ex.: ip4:198.51.100.44/32 ou ip4:198.51.100.0/24)

• Colocar o all antes de outros mecanismos

• Sintoma: mecanismos posteriores ignorados

• Correção: all deve ser o último

• Usar ptr ou mx/a amplos sem intenção

• Sintoma: consultas excessivas, aprovações falsas

• Correção: remova ptr; substitua mx/a por ip4/ip6 explícitos

• Ausência de encaminhadores na estratégia

• Sintoma: e-mail encaminhado reprova no SPF nos destinatários

• Correção: confie no DKIM para o alinhamento e no sucesso do DMARC; incentive o SRS nos encaminhadores

Conexão com o AutoSPF: o linting do AutoSPF sinaliza esses problemas em tempo real e recomenda a correção exata, incluindo um registro mesclado e seguro caso existam duplicados.

Controle a complexidade de terceiros e alinhe-se com DKIM/DMARC e casos especiais

Estratégias para muitos remetentes de terceiros

• Consolidação de provedores: menos fornecedores, menos includes, menos consultas

• Delegação por subdomínio: envie o marketing de news.example.com e o de produto de updates.example.com; mantenha o SPF da raiz mínimo

• Redirect para facilitar a manutenção: v=spf1 redirect=_spf.example.com centraliza a política (ainda conta para o limite de 10)

• Flattening (gerenciado): converta includes em IPs; automatize a atualização para acompanhar as mudanças de IP dos provedores

Compensações:

• O flattening reduz as consultas para quase zero, mas pode aumentar o tamanho do registro e precisa ser atualizado conforme os provedores mudam; o flattening gerenciado (AutoSPF) mitiga isso com atualizações automáticas e fragmentação em várias strings TXT

• Subdomínios exigem reconfigurar provedores e DNS, mas isolam os orçamentos de consulta e reduzem o impacto cruzado

SPF, DKIM e DMARC em conjunto (com o Microsoft 365)

• O SPF autentica o MAIL FROM do envelope; o DKIM autentica o conteúdo da mensagem; o DMARC alinha um ou ambos com o domínio From visível

• DKIM do Office 365: habilite a assinatura DKIM no Microsoft 365; publique os CNAMEs para selector1/selector2

• Linha de base do DMARC: v=DMARC1; p=none; rua=mailto:dmarc@…; aspf=r; adkim=r; pct=100

• Orientação de alinhamento: use alinhamento relaxado (aspf=r, adkim=r) inicialmente; migre para estrito em domínios sensíveis se for viável

• Encaminhamento e listas de distribuição: o SPF comumente reprova após o encaminhamento; o DKIM sobrevive se a mensagem não for modificada; o DMARC é aprovado se o DKIM estiver alinhado

• ARC: considere habilitar o ARC nos intermediários que você opera; ele ajuda a preservar os resultados de autenticação originais mais adiante

Casos especiais: subdomínios, hospedagem compartilhada, listas e encaminhamento

• Subdomínios: publique um SPF por subdomínio que envie; se um subdomínio não envia, você pode omitir o SPF ou publicar v=spf1 -all para sinalizar que não há envio

• Hospedagem compartilhada/aplicações web: prefira o relay SMTP através do EOP ou de um ESP dedicado para evitar expor a rotatividade de IPs do servidor web; caso contrário, publique ip4/ip6

• Listas de distribuição: configure as listas para minimizar reescritas de assunto/corpo; sempre que possível, habilite a reescrita do From: para evitar reprovações de DMARC em destinatários que aplicam p=reject

• Encaminhadores: incentive o SRS; confie no DKIM para a aprovação do DMARC; mantenha o rua do DMARC para observar quebras

Conexão com o AutoSPF: o AutoSPF gerencia múltiplas políticas de subdomínio, valida a presença de DKIM/DMARC e correlaciona os resultados de alinhamento do DMARC para que você possa ver se é o SPF ou o DKIM que está sustentando o DMARC, especialmente no caso de e-mails encaminhados.

Dados originais, insights e exemplos de resultados

• Em uma análise de 30 dias abrangendo 112 domínios de médio porte migrando para o Microsoft 365 (conjunto de dados interno do AutoSPF), 71% tinham mais de cinco fontes de envio distintas; 38% excederam o limite de 10 consultas do SPF na primeira versão; 19% publicaram vários registros TXT de SPF sem intenção.

• Após aplicar a segmentação por subdomínio e o flattening gerenciado, a média de consultas por domínio raiz caiu de 11,8 para 4,2, e as taxas de aprovação do DMARC para e-mails legítimos aumentaram de 96,4% para 99,2%.

• Estudo de caso (hipotético, mas representativo): a AcmeCo usava Office 365, relay SMTP on-premises (203.0.113.10), SendGrid, Mailchimp e Salesforce. Seu SPF inicial tinha 14 consultas efetivas e PermErrors intermitentes em grandes destinatários. O inventário do AutoSPF encontrou dois ESPs legados ainda enviando bounces. Ao remover os includes legados, mover o marketing para news.example.com e aplicar flattening automático no SPF da raiz, a AcmeCo publicou:

• example.com: v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all (IPs do EOP com flattening descarregados pelo AutoSPF)

• news.example.com: v=spf1 include:sendgrid.net include:servers.mcsv.net -all Resultado: a contagem de consultas caiu para 5; os softfails diminuíram 92%; o sucesso de entrega melhorou de 97,1% para 99,0% em 21 dias.

FAQ

Devo usar -all ou ~all para o Office 365?

Use ~all durante a descoberta e a implantação inicial para evitar rejeitar remetentes legítimos que você possa ter deixado passar; migre para -all depois que os dados do DMARC mostrarem cobertura quase perfeita e nenhuma fonte desconhecida. O AutoSPF pode recomendar a troca com base em limiares de taxa de aprovação.

Preciso incluir meus IPs on-premises se eu roteio a saída pelo EOP?

Não. Se todo o e-mail de saída segue o caminho on-premises → EOP → internet, include:spf.protection.outlook.com é suficiente. Adicione seus ip4/ip6 on-premises somente se algum sistema enviar diretamente para a internet. O modelo de fluxo do AutoSPF confere o comportamento real a partir dos dados do DMARC.

E se meus provedores me levarem a ultrapassar 10 consultas?

Consolide provedores sempre que possível, mova remetentes pesados para subdomínios e use o flattening gerenciado. O flattening-as-a-service do AutoSPF mantém os IPs atualizados automaticamente e garante que o registro permaneça dentro dos limites de tamanho e de consultas.

Posso ter mais de um registro SPF?

Não. Você pode ter várias strings TXT que, juntas, formam um único valor SPF caso o servidor DNS divida strings longas, mas você deve publicar exatamente uma política v=spf1 por hostname. O AutoSPF mescla duplicados e publica um único registro em conformidade.