Configurar o SPF para identificar fontes de email válidas para seu domínio do Microsoft 365

Dica

Você sabia que pode experimentar os recursos no Microsoft Defender XDR para Office 365 Plano 2 gratuitamente? Use a avaliação de Defender para Office 365 de 90 dias no hub de avaliações do portal Microsoft Defender. Saiba mais sobre quem pode inscrever e testar termos aqui.

O SPF (Sender Policy Framework) é um método de autenticação por email que ajuda a validar emails enviados de sua organização do Microsoft 365 para evitar remetentes falsificados que são usados no BEC (compromisso de email comercial), ransomware e outros ataques de phishing.

A principal finalidade do SPF é validar fontes de email para um domínio. Especificamente, o SPF usa um registro TXT no DNS para identificar fontes de email válidas para o domínio. O recebimento de sistemas de email usa o registro SPF TXT para verificar se o email do endereço do remetente usado durante a transmissão SMTP da mensagem (conhecida como endereço MAIL FROM, 5321.MailFrom endereço, remetente P1 ou remetente de envelope) é de uma fonte de email conhecida e designada para esse domínio.

Por exemplo, se o domínio de email no Microsoft 365 estiver contoso.com, você criará um registro TXT SPF no DNS para o domínio contoso.com para identificar o Microsoft 365 como uma fonte de email autorizada do contoso.com. Os sistemas de email de destino marcar o registro SPF TXT em contoso.com para determinar se a mensagem veio de uma fonte autorizada para contoso.com email.

Antes de começarmos, aqui está o que você precisa saber sobre o SPF no Microsoft 365 com base em seu domínio de email:

  • Se você usar apenas o domínio moera (endereço de roteamento) do Microsoft Online Email para email (por exemplo, contoso.onmicrosoft.com): você não precisa fazer nada. O registro TXT do SPF já está configurado para você. A Microsoft é dona do domínio onmicrosoft.com, portanto, somos responsáveis por criar e manter os registros DNS nesse domínio e subdomínios. Para obter mais informações sobre domínios *.onmicrosoft.com, consulte Por que tenho um domínio "onmicrosoft.com"?.

  • Se você usar um ou mais domínios personalizados para email (por exemplo, contoso.com): o processo de registro do Microsoft 365 já exigiu que você criasse ou modificasse o registro SPF TXT no DNS para seu domínio personalizado para identificar o Microsoft 365 como uma fonte de email autorizada. Mas, você ainda tem mais trabalho a fazer para a proteção máxima de email:

    • Considerações de subdomínio:

      • Para serviços de email que não estão sob seu controle direto (por exemplo, serviços de email em massa), recomendamos usar um subdomínio (por exemplo, marketing.contoso.com) em vez do domínio de email main (por exemplo, contoso.com). Você não quer que problemas com emails enviados desses serviços de email afetem a reputação dos emails enviados pelos funcionários em seu domínio de email main. Para obter mais informações sobre como adicionar subdomínios, confira Posso adicionar subdomínios personalizados ou vários domínios ao Microsoft 365?.

      • Cada subdomínio que você usa para enviar email do Microsoft 365 requer seu próprio registro SPF TXT. Por exemplo, o registro TXT do SPF para contoso.com não abrange marketing.contoso.com; marketing.contoso.com precisa de seu próprio registro SPF TXT.

        Dica

        Email proteção de autenticação para subdomínios indefinidos é coberta por DMARC. Qualquer subdomínio (definido ou não) herda as configurações DMARC do domínio pai (que pode ser substituído por subdomínio). Para obter mais informações, consulte Configurar o DMARC para validar o domínio De endereço para remetentes no Microsoft 365.

    • Se você possui domínios registrados, mas não utilizados: se você possui domínios registrados que não são usados para email ou qualquer coisa (também conhecidos como domínios estacionados), configure registros TXT do SPF para indicar que nenhum email deve vir desses domínios, conforme descrito posteriormente neste artigo.

  • O SPF por si só não é suficiente. Para o melhor nível de proteção por email para seus domínios personalizados, você também precisa configurar DKIM e DMARC como parte da estratégia geral de autenticação por email . Para obter mais informações, confira a seção Próximas Etapas no final deste artigo.

    Importante

    Em organizações complexas em que é difícil identificar todas as fontes de email válidas para o domínio, é importante configurar rapidamente a assinatura de DKIM e o DMARC (no modo "não tomar nenhuma ação" para o domínio. Um serviço de relatório DMARC é muito útil para identificar fontes de email e falhas de SPF para o domínio.

O restante deste artigo descreve os registros TXT do SPF que você precisa criar para domínios personalizados no Microsoft 365.

Dica

Não há portais de administrador ou cmdlets do PowerShell no Microsoft 365 para você gerenciar registros SPF em seu domínio. Em vez disso, você cria o registro SPF TXT em seu registrador de domínio ou serviço de hospedagem DNS (geralmente a mesma empresa).

Fornecemos instruções para criar a prova do registro TXT de propriedade de domínio para o Microsoft 365 em muitos registradores de domínio. Você pode usar essas instruções como ponto de partida para criar o valor de registro TXT do SPF. Para obter mais informações, consulte Adicionar registros DNS para conectar seu domínio.

Se você não estiver familiarizado com a configuração DNS, entre em contato com o registrador de domínio e peça ajuda.

Sintaxe para registros TXT do SPF

Os registros TXT do SPF são descritos exaustivamente no RFC 7208.

A sintaxe básica do registro TX do SPF para um domínio personalizado no Microsoft 365 é:

v=spf1 <valid mail sources> <enforcement rule>

Ou:

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

Por exemplo:

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

  • v=spf1 identifica o registro TXT como um registro TXT SPF.

  • Fontes de email válidas: fontes de email válidas especificadas para o domínio. Usa domínios, endereços IP ou ambos:

    • Domínios: include: os valores especificam outros serviços ou domínios como fontes de email válidas do domínio original. Esses valores, em última análise, levam a um endereço IP usando pesquisas DNS.

      A maioria das organizações do Microsoft 365 exige include:spf.protection.outlook.com no registro TXT do SPF para o domínio. Outros serviços de email de terceiros geralmente exigem um valor adicional include: para identificar o serviço como uma fonte válida de email do domínio original.

    • Endereços IP: um valor de endereço IP inclui ambos os seguintes elementos:

      • O valor ip4: ou ip6: para identificar o tipo de endereço IP.
      • O endereço IP resolvível publicamente do sistema de email de origem. Por exemplo:
        • Um endereço IP individual (por exemplo, 192.168.0.10).
        • Um intervalo de endereços IP usando a notação CIDR (roteamento de Inter-Domain sem classe) (por exemplo, 192.168.0.1/26). Certifique-se de que o intervalo não é muito grande ou muito pequeno.

      No Microsoft 365, normalmente você usa endereços IP no registro SPF TXT somente se tiver servidores de email locais que enviam emails do domínio do Microsoft 365 (por exemplo, Exchange Server implantações híbridas). Alguns serviços de email de terceiros também podem usar um intervalo de endereços IP em vez de um include: valor no registro TXT do SPF.

  • Regra de execução: informa aos sistemas de email de destino o que fazer com mensagens de fontes que não são especificadas no registro TXT do SPF para o domínio. Os valores válidos são:

    • -all (falha dura): as fontes não especificadas no registro TXT do SPF não estão autorizadas a enviar emails para o domínio, portanto, as mensagens devem ser rejeitadas. O que realmente acontece com a mensagem depende do sistema de email de destino, mas as mensagens normalmente são descartadas.

      Para domínios do Microsoft 365, recomendamos -all (falha dura) porque também recomendamos DKIM e DMARC para o domínio. A política DMARC especifica o que fazer com mensagens que falham em relatórios SPF ou DKIM e DMARC permitem validar os resultados.

      Dica

      Conforme indicado anteriormente, o DMARC configurado com um serviço de relatório DMARC ajuda muito na identificação de fontes de email e falhas de SPF para o domínio.

    • ~all (falha suave): as fontes não especificadas no registro SPF TXT provavelmente não estão autorizadas a enviar emails para o domínio, portanto, as mensagens devem ser aceitas, mas marcadas. O que realmente acontece com a mensagem depende do sistema de email de destino. Por exemplo, a mensagem pode ser colocada em quarentena como spam, entregue na pasta Junk Email ou entregue na caixa de entrada com um identificador adicionado ao Corpo da Mensagem ou assunto.

      Como também recomendamos DKIM e DMARC para domínios do Microsoft 365, as diferenças entre -all (falha dura) e ~all (falha suave) são efetivamente eliminadas (O DMARC trata o resultado como uma falha do SPF). O DMARC usa o SPF para confirmar que os domínios nos endereços MAIL FROM e From se alinham e a mensagem veio de uma fonte válida para o domínio From.

    Dica

    ?all (neutro) também está disponível para sugerir nenhuma ação específica em mensagens de fontes não identificadas. Esse valor é usado para testes e não recomendamos esse valor em ambientes de produção.

Pontos importantes a serem lembrados:

  • Cada domínio ou subdomínio definido no DNS requer um registro TXT SPF e apenas um registro SPF é permitido por domínio ou subdomínio. Email proteção de autenticação para subdomínios indefinidos é melhor tratada pelo DMARC.
  • Você não pode modificar o registro TXT SPF existente para o domínio *.onmicrosoft.com.
  • Quando o sistema de email de destino verifica as fontes de email válidas no registro SPF, a validação do SPF falhará se o marcar exigir muitas pesquisas DNS. Para obter mais informações, confira a seção SPF TXT de solução de problemas mais adiante neste artigo.

Registros TXT do SPF para domínios personalizados no Microsoft 365

Dica

Conforme mencionado anteriormente neste artigo, você cria o registro SPF TXT para um domínio ou subdomínio no registrador de domínio do domínio. Nenhuma configuração de registro TXT do SPF está disponível no Microsoft 365.

  • Cenário: você usa contoso.com para email no Microsoft 365 e o Microsoft 365 é a única fonte de email do contoso.com.

    Registro do SPF TXT para contoso.com no Microsoft 365 e no Microsoft 365 Government Community Cloud (GCC):

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

    Registro do SPF TXT para contoso.com no Microsoft 365 Government Community Cloud High (GCC High) e no Microsoft 365 Department of Defense (DoD):

    v=spf1 include:spf.protection.office365.us -all

    Registro SPF TXT para contoso.com no Microsoft 365 operado pela 21Vianet

    v=spf1 include:spf.protection.partner.outlook.cn -all

  • Cenário: você usa contoso.com para email no Microsoft 365 e já configurou o registro SPF TXT em contoso.com com todas as fontes de email do domínio. Você também possui os domínios contoso.net e contoso.org, mas não os usa para email. Você deseja especificar que ninguém está autorizado a enviar email de contoso.net ou contoso.org.

    Registro TXT do SPF para contoso.net:

    v=spf1 -all

    Registro SPF TXT para contoso.org:

    v=spf1 -all

  • Cenário: você usa contoso.com para email no Microsoft 365. Você planeja enviar emails das seguintes fontes:

    • Um servidor de email local com o endereço de email externo de 192.168.0.10. Como você tem controle direto sobre essa fonte de email, consideramos ok usar o servidor para remetentes no domínio contoso.com.
    • O serviço de email em massa do Adatum. Como você não tem controle direto sobre essa fonte de email, recomendamos usar um subdomínio para criar marketing.contoso.com para essa finalidade. De acordo com a documentação do serviço do Adatum, você precisa adicionar include:servers.adatum.com ao registro SPF TXT para seu domínio.

    Registro SPF TXT para contoso.com:

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

    Registro TXT do SPF para marketing.contoso.com:

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

Solução de problemas de registros TXT do SPF

  • Um registro SPF por domínio ou subdomínio: vários registros SPF TXT para o mesmo domínio ou subdomínio causam um loop de pesquisa DNS que faz o SPF falhar, portanto, use apenas um registro SPF por domínio ou subdomínio.

  • Menos de 10 pesquisas DNS: quando os sistemas de email de destino consultam o registro TXT do SPF em busca de fontes válidas para o domínio de endereço MAIL FROM, a consulta examina os endereços IP e include: as instruções no registro até que a fonte da mensagem (em última análise, um endereço IP) corresponda a uma das fontes especificadas. Se o número de pesquisas DNS (que podem ser diferentes do número de consultas DNS) for maior que 10, a mensagem falhará no SPF com um erro permanente (também conhecido como ).permerror O sistema de email de destino rejeita a mensagem em um relatório de não entrega (também conhecido como NDR ou mensagem de retorno) com um dos seguintes erros:

    • A mensagem excedeu a contagem de saltos.
    • A mensagem exigiu muitas pesquisas.

    No registro SPF TXT, endereços IP individuais ou intervalos de endereços IP não causam pesquisas de DNS. Cada include: instrução requer pelo menos uma pesquisa DNS e mais pesquisas podem ser necessárias se o include: valor apontar para recursos aninhados. Em outras palavras, ter menos de 10 include: instruções não garante menos de 10 pesquisas DNS.

    Lembre-se também: os sistemas de email de destino avaliam as fontes no registro SPF TXT da esquerda para a direita. A avaliação é interrompida quando a origem da mensagem é validada e não há mais fontes marcadas. Portanto, um registro SPF TXT pode conter informações suficientes para causar mais de 10 pesquisas DNS, mas a validação de algumas fontes de email por alguns destinos não é profunda o suficiente no registro para resultar em um erro.

    Além de preservar a reputação de seu domínio de email main, não exceder o número de pesquisas DNS é outro motivo para usar subdomínios para outros serviços de email que você não controla.

Você pode usar ferramentas online gratuitas para exibir seu registro SPF TXT e outros registros DNS para seu domínio. Algumas ferramentas até calculam o número de pesquisas de registro DNS que o registro TXT do SPF requer.

Próximas etapas

Conforme descrito em Como SPF, DKIM e DMARC trabalham juntos para autenticar remetentes de mensagens de email, o SPF sozinho não é suficiente para impedir a falsificação do domínio do Microsoft 365. Você também precisa configurar dKIM e DMARC para a melhor proteção possível. Para obter instruções, veja:

Para o email que chega ao Microsoft 365, talvez você também precise configurar selos ARC confiáveis se você usar serviços que modificam mensagens em trânsito antes da entrega à sua organização. Para obter mais informações, consulte Configurar selos ARC confiáveis.