Configurar o SPF para identificar origens de e-mail válidas para os seus domínios de cloud personalizados

Dica

Sabia que pode experimentar as funcionalidades no Microsoft Defender para Office 365 Plano 2 gratuitamente? Utilize a versão de avaliação do Defender para Office 365 de 90 dias no hub de avaliações do portal do Microsoft Defender. Saiba mais sobre quem pode inscrever-se e os termos de avaliação em Experimentar Microsoft Defender para Office 365.

O Sender Policy Framework (SPF) é um método de autenticação de e-mail que ajuda a validar o e-mail enviado pela sua organização do Microsoft 365 para impedir remetentes falsificados utilizados em e-mails empresariais comprometidos (BEC), ransomware e outros ataques de phishing.

O principal objetivo do SPF é validar as origens de e-mail de um domínio. Especificamente, o SPF utiliza um registo TXT no DNS para identificar origens de correio válidas para o domínio. Os sistemas de receção de e-mail utilizam o registo TXT do SPF para verificar se o e-mail do endereço do remetente utilizado durante a transmissão SMTP da mensagem (conhecido como endereço MAIL FROM, 5321.MailFrom endereço, remetente P1 ou remetente de envelope) é de uma fonte de correio conhecida e designada para esse domínio.

Por exemplo, se o seu domínio de email no Microsoft 365 for contoso.com, você cria um registro TXT SPF no DNS para o domínio contoso.com para identificar o Microsoft 365 como uma fonte autorizada de emails de contoso.com. Os sistemas de email de destino verificam o registro TXT de SPF em contoso.com para determinar se a mensagem veio de uma origem autorizada para enviar emails do contoso.com.

Antes de começar, eis o que precisa de saber sobre o SPF no Microsoft 365 com base no seu domínio de e-mail:

  • Se você usar apenas o domínio de Endereço de Roteamento de Email Online da Microsoft (MOERA) para email (por exemplo, contoso.onmicrosoft.com): não precisa fazer nada. O registo TXT do SPF já está configurado para si. A Microsoft é proprietária do domínio onmicrosoft.com, pelo que somos responsáveis por criar e manter os registos DNS nesse domínio e subdomínios. Para obter mais informações sobre os domínios *.onmicrosoft.com, consulte Por que motivo tenho um domínio "onmicrosoft.com"?

  • Se utilizar um ou mais domínios personalizados para e-mail (por exemplo, contoso.com): o processo de inscrição do Microsoft 365 já exigiu que criasse ou modificasse o registo TXT SPF no DNS para o seu domínio personalizado para identificar o Microsoft 365 como uma origem de correio autorizada. No entanto, ainda tem mais trabalho a fazer para obter a máxima proteção por e-mail:

    • Considerações sobre subdomínios:

      • Para serviços de e-mail que não estejam sob o seu controlo direto (por exemplo, serviços de e-mail em massa), recomendamos que utilize um subdomínio (por exemplo, marketing.contoso.com) em vez do domínio de e-mail principal (por exemplo, contoso.com). Não quer que os problemas com o correio enviado a partir desses serviços de e-mail afetem a reputação do correio enviado pelos funcionários no seu domínio de e-mail principal. Para obter mais informações sobre como adicionar subdomínios, consulte Posso adicionar subdomínios personalizados ou múltiplos domínios ao Microsoft 365?.

      • Cada subdomínio que utiliza para enviar e-mails do Microsoft 365 requer o seu próprio registo TXT SPF. Por exemplo, o registo TXT SPF para contoso.com não abrange marketing.contoso.com; marketing.contoso.com precisa do seu próprio registo TXT SPF.

        Dica

        A proteção de autenticação de e-mail para subdomínios undefined é coberta pelo DMARC. Todos os subdomínios (definidos ou não) herdam as configurações de DMARC do domínio pai (que podem ser substituídas para cada subdomínio). Para obter mais informações, consulte Configurar o DMARC para validar o domínio do endereço do remetente para remetentes de nuvem.

    • 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 SPF para indicar que nenhum email deve vir desses domínios, conforme descrito em Cenário: domínios estacionados.

  • Só o SPF não é suficiente. Para obter o melhor nível de proteção de e-mail para os seus domínios personalizados, também tem de configurar o DKIM e o DMARC como parte da sua estratégia geral de autenticação de e-mail . Para obter mais informações, consulte a secção Passos seguintes no final deste artigo.

    Importante

    Em organizações complexas onde é difícil identificar todas as origens de correio válidas para o domínio, é importante que configure rapidamente a assinatura DKIM e o DMARC (no modo "não tomar nenhuma ação") para o domínio. Um serviço de relatórios DMARC é muito útil para identificar origens de e-mail e falhas de SPF para o domínio.

O resto deste artigo descreve os registos TXT SPF que precisa de criar para domínios personalizados no Microsoft 365.

Dica

Não existem portais de administração ou cmdlets do PowerShell no Microsoft 365 para gerir registos SPF no seu domínio. Em vez disso, crie o registo TXT SPF na sua entidade de registo de domínios ou no serviço de alojamento DNS (muitas vezes a mesma empresa).

Fornecemos instruções para criar o registo TXT de prova de propriedade do domínio para o Microsoft 365 em muitas entidades de registo de domínios. Pode utilizar estas instruções como ponto de partida para criar o valor de registo TXT do SPF. Para obter mais informações, veja Adicionar registos DNS para ligar o seu domínio.

Se não estiver familiarizado com a configuração de DNS, contacte a entidade de registo de domínios e peça ajuda.

Sintaxe para registros TXT de SPF

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

A sintaxe básica do registo TXT 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:<DomainName2>... 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 SPF do tipo TXT.

  • Origens de correio válidas: origens de correio válidas para o domínio. Utiliza Domínios, endereços IP ou ambos:

    • Domínios: include: os valores especificam outros serviços ou domínios como origens de correio válidas do domínio original. Estes valores acabam por levar a um endereço IP através de pesquisas DNS.

      A maioria das organizações do Microsoft 365 exige include:spf.protection.outlook.com no registro TXT de SPF do domínio. Outros serviços de e-mail que não sejam da Microsoft exigem frequentemente um valor adicional include: para identificar o serviço como uma origem de e-mail válida 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 do sistema de e-mail de origem que pode ser resolvido publicamente. Por exemplo:
        • Um endereço IP individual (por exemplo, 192.168.0.10).
        • Um intervalo de endereços IP usando a notação CIDR (Classless Inter-Domain Routing) (por exemplo, 192.168.0.1/26). Certifique-se de que o intervalo não é demasiado grande ou muito pequeno.

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

  • Regra de imposição: indica aos sistemas de e-mail de destino o que fazer com mensagens de origens que não estão especificadas no registo TXT do SPF para o domínio. Os valores válidos são:

    • -all (falha grave): as origens não especificadas no registo TXT SPF não estão autorizadas a enviar correio para o domínio, pelo que as mensagens devem ser rejeitadas. O que realmente acontece à mensagem depende do sistema de e-mail de destino, mas as mensagens são normalmente eliminadas.

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

      Dica

      Como indicado anteriormente, o DMARC configurado com um serviço de relatórios DMARC ajuda bastante a identificar origens de e-mail e falhas de SPF para o domínio.

    • ~all (falha recuperável): as origens não especificadas no registo TXT SPF provavelmente não estão autorizadas a enviar correio para o domínio, pelo que as mensagens devem ser aceites, mas marcadas. O que realmente acontece à mensagem depende do sistema de e-mail de destino. Por exemplo, a mensagem pode ser colocada em quarentena como spam, entregue na pasta Email de Lixo ou entregue na Caixa de Entrada com um identificador adicionado ao assunto ou corpo da mensagem.

      Observação

      O DMARC trata -all (falha forte) e ~all (falha recuperável) como falhas de SPF. No entanto, a política DMARC é efetivamente ignorada para falhas de SPF ~all se as mensagens também não contiverem assinaturas DKIM. Recomendamos -all para que o DMARC se aplique a mensagens que falhem na SPF, caso as mensagens também não tenham assinaturas DKIM.

    • ?all (neutro): não sugere nenhuma ação específica em mensagens de origens não identificadas. Este valor é utilizado para testes e não recomendamos este valor em ambientes de produção.

Pontos importantes a memorizar:

  • Cada domínio ou subdomínio definido no DNS requer um registo TXT SPF e só é permitido um registo SPF por domínio ou subdomínio. A proteção de autenticação de e-mail para subdomínios não especificados é melhor feita com DMARC.
  • Não pode modificar o registo TXT SPF existente para o domínio *.onmicrosoft.com.
  • Quando o sistema de e-mail de destino verifica as fontes de e-mail válidas no registro SPF, a validação de SPF falha se a verificação exigir consultas DNS em excesso. Para obter mais informações, consulte Solução de problemas de registros TXT SPF.

Registos TXT SPF para domínios personalizados no Microsoft 365

Dica

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

Cenário: apenas e-mail do Microsoft 365

Utiliza contoso.com para e-mail no Microsoft 365 e o Microsoft 365 é a única origem de e-mail de contoso.com.

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

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

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

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

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

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

Cenário: Domínios estacionados

Você é proprietário dos domínios contoso.net e contoso.org, mas não os usa para e-mail. Pretende especificar que ninguém está autorizado a enviar e-mails a partir de contoso.net ou contoso.org.

  • Registo TXT do SPF para contoso.net:

    v=spf1 -all

  • Registro TXT de SPF para contoso.org:

    v=spf1 -all

Observação

Conforme mencionado anteriormente neste artigo, cada subdomínio requer o seu próprio registo TXT SPF. Para domínios estacionados, é praticamente impossível adivinhar que subdomínios podem ser necessários. Se o registrador de domínios oferecer suporte a registros curinga, você poderá usar a seguinte sintaxe para especificar que ninguém está autorizado a enviar e-mails de quaisquer subdomínios do domínio estacionado:

Nome do anfitrião: _*.contoso.net ou _*.contoso.org
Valor TXT: v=spf1 -all

Cenário: e-mail do Microsoft 365 com e-mail no local e um serviço de e-mail não Microsoft

Utiliza contoso.com para e-mail no Microsoft 365. Planeia enviar correio a partir das seguintes origens:

  • Um servidor de e-mail no local com o endereço de e-mail externo 192.168.0.10. Uma vez que tem controlo direto sobre esta origem de e-mail, consideramos ok utilizar o servidor para remetentes no domínio contoso.com.

  • O serviço de correio em massa do Adatum. Uma vez que não tem controlo direto sobre esta origem de e-mail, recomendamos que utilize um subdomínio, pelo que pode criar marketing.contoso.com para esse fim. De acordo com a documentação do serviço Adatum, tem de adicionar include:servers.adatum.com ao registo TXT do SPF do seu domínio.

    Registro SPF do tipo TXT para contoso.com:

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

    Registro TXT SPF para marketing.contoso.com:

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

Solução de problemas de registros TXT de SPF

Para obter uma tabela de referência rápida de erros, causas e correções de SPF, consulte Resolver problemas de autenticação de e-mail no Microsoft 365.

  • Um registo SPF por domínio ou subdomínio: vários registos TXT SPF para o mesmo domínio ou subdomínio fazem com que o SPF regresse permerror (o sistema de receção não consegue determinar qual o registo a avaliar), pelo que utilize apenas um registo SPF por domínio ou subdomínio.

  • TTL (Time to Live): recomendamos um valor mínimo de TTL de 3600 segundos (uma hora) nos registos TXT SPF para evitar tempos limite de pesquisa de DNS.

  • Menos de 10 consultas DNS: quando os sistemas de e-mail de destino consultam o registro TXT do SPF para obter fontes válidas para o domínio do endereço MAIL FROM, a consulta examina os endereços IP e as include: declarações no registro até que a origem da mensagem (em última instância, um endereço IP) corresponda a uma das fontes especificadas. Se o número de pesquisas de DNS (que podem ser diferentes do número de consultas DNS) for superior a 10, a mensagem falha no SPF com um erro permanente (também conhecido como permerror). O sistema de e-mail de destino rejeita a mensagem num relatório de entrega sem êxito (também conhecido como NDR ou mensagem de devolução) com um dos seguintes erros:

    • A mensagem excedeu o número de saltos.
    • A mensagem exigiu muitas pesquisas.

    No registo TXT do SPF, os endereços IP individuais ou os intervalos de endereços IP não causam pesquisas de DNS. Cada instrução include: requer pelo menos uma consulta DNS, e talvez sejam necessárias mais consultas se o valor de include: apontar para recursos aninhados. Em outras palavras, ter menos de 10 include: declarações não garante que haja menos de 10 consultas de DNS.

    Tenha também em atenção: os sistemas de e-mail de destino avaliam as origens no registo TXT do SPF da esquerda para a direita. A avaliação é interrompida depois que a origem da mensagem é validada, e nenhuma outra origem é verificada. Por conseguinte, um registo TXT SPF pode conter informações suficientes para causar mais de 10 pesquisas DNS, mas a validação de algumas origens de correio por alguns destinos não é suficientemente profunda no registo para resultar num erro.

    Além de preservar a reputação do seu domínio de e-mail principal, não exceder o número de pesquisas DNS é outra razão para utilizar subdomínios para outros serviços de e-mail que não controla.

Pode utilizar ferramentas online gratuitas para ver o seu registo TXT SPF e outros registos DNS para o seu domínio. Algumas ferramentas até calculam o número de consultas a registros DNS que o seu registro TXT de SPF exige.

O que é considerado uma consulta DNS

Os seguintes mecanismos e modificadores de SPF contam, cada um, como uma consulta DNS:

  • include:
  • a
  • mx
  • exists
  • redirect

Os seguintes elementos não contam para o limite de 10 pesquisas:

  • ip4: valores (endereços individuais ou intervalos CIDR)
  • ip6: valores (endereços individuais ou intervalos CIDR)
  • O mecanismo all

Lembre-se de que instruções include: aninhadas adicionam pesquisas além das pesquisas diretas no seu registro SPF. Por exemplo, um include: que aponta para outro registro SPF que contém mais três instruções include: adiciona quatro consultas no total (uma pela consulta inicial mais três pelas consultas aninhadas).

Reduzir pesquisas de DNS

Se o seu registo SPF exceder o limite de 10 pesquisas, utilize estas estratégias para reduzir o número de pesquisas:

  • Substitua os valores de include por endereços IP: Se um fornecedor que não seja da Microsoft tiver um conjunto estável e documentado de endereços IP de envio, substitua a instrução include: pelos valores ip4: ou ip6:. Esta abordagem requer que monitorize o fornecedor relativamente a alterações de endereços IP.
  • Utilizar subdomínios: mova os serviços de e-mail não Microsoft para subdomínios. Por exemplo, use marketing.contoso.com para emails de marketing com seu próprio registro SPF. Cada subdomínio tem seu próprio limite de 10 consultas.
  • Consolidar serviços de e-mail: se possível, reduza o número de serviços que não são da Microsoft que enviam e-mails a partir do seu domínio.

Erros de sintaxe comuns nos registos SPF

A validação do SPF falha se o registo TXT contiver erros de formatação. Os exemplos seguintes mostram erros comuns:

Entrada incorreta Problema Entrada correta
v=spf1 include:spf.protection.outlook.com. -all Ponto final após o nome de domínio. v=spf1 include:spf.protection.outlook.com -all
v=spf1 include=spf.protection.outlook.com -all Sinal de igual em vez de dois pontos após include. v=spf1 include:spf.protection.outlook.com -all
v=spf1 include: spf.protection.outlook.com -all Espaço entre os dois pontos e o nome de domínio. v=spf1 include:spf.protection.outlook.com -all

Se um include: domínio não resolve ou não tiver nenhum registo SPF, a validação SPF é devolvida permerror e as mensagens poderão ser rejeitadas. Verifique as include: entradas ao consultar o registo TXT do DNS para o domínio referenciado.

Aplanamento de SPF

O achatamento de SPF é a prática de substituir os mecanismos include: pelos endereços IP resolvidos para reduzir as consultas de DNS.

Quando o aplanamento é adequado:

  • Fornecedores não Microsoft com intervalos de endereços IP estáveis e documentados.
  • Serviços que raramente alteram os endereços IP enviados.
  • Quando você estiver se aproximando ou excedendo o limite de 10 consultas e outras estratégias (subdomínios, consolidação) não forem viáveis.

Quando você não deve achatar:

  • Microsoft 365 (include:spf.protection.outlook.com). A infraestrutura de envio da Microsoft utiliza endereços IP dinâmicos que mudam frequentemente.
  • Qualquer serviço cloud com endereços IP dinâmicos ou frequentemente alterados.

Se você achatar seu registro SPF:

  • Documente quais entradas include: você substituiu e quando.
  • Monitorize a documentação do fornecedor relativamente a alterações de endereços IP.
  • Reveja e atualize as entradas aplanadas, pelo menos, trimestralmente.
  • Teste a validação do SPF após cada alteração.

Dica

Os serviços de nivelamento de SPF que não são da Microsoft podem automatizar o processo de acompanhamento das alterações nos IPs dos fornecedores e de atualização do seu registro SPF. Avalie estes serviços se a manutenção manual for impraticável para a sua organização.

Próximas etapas

Conforme descrito em Como o SPF, o DKIM e o DMARC trabalham em conjunto para autenticar remetentes de mensagens de e-mail, o SPF por si só não é suficiente para impedir o spoofing do seu domínio do Microsoft 365. Também tem de configurar o DKIM e o DMARC para obter a melhor proteção possível. Para obter instruções, veja:

Para emails que chegam ao Microsoft 365, talvez também seja necessário configurar seladores 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 emissores de selos ARC confiáveis.

Para diagnosticar e corrigir falhas de autenticação de e-mail, consulte Resolver problemas de autenticação de e-mail no Microsoft 365.

  • Last updated on