Configurar o SPF para identificar origens de e-mail válidas para o seu domínio do Microsoft 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 e-mail no Microsoft 365 for contoso.com, crie um registo TXT SPF no DNS para o domínio contoso.com para identificar o Microsoft 365 como uma origem de correio autorizada de contoso.com. Os sistemas de e-mail de destino marcar o registo TXT SPF no contoso.com para determinar se a mensagem veio de uma origem autorizada para contoso.com e-mail.

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

• Se utilizar apenas o domínio do Endereço de Encaminhamento do Microsoft Online Email (MOERA) para e-mail (por exemplo, contoso.onmicrosoft.com): não precisa de 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 de 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 seu domínio de e-mail main (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 dos e-mails enviados pelos funcionários no seu domínio de e-mail main. 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

      Email proteção de autenticação para subdomínios não definidos é abrangida pela DMARC. Quaisquer subdomínios (definidos ou não) herdam as definições DMARC do domínio principal (que podem ser substituídas por subdomínio). Para obter mais informações, consulte Configurar o DMARC para validar o domínio de endereço De para remetentes no Microsoft 365.

  • Se tiver domínios registados, mas não utilizados: se tiver domínios registados que não são utilizados para e-mail ou qualquer outra coisa (também conhecidos como domínios estacionados), configure os registos TXT do SPF para indicar que nenhum e-mail deve vir desses domínios, conforme descrito mais adiante neste artigo.

• 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.

Sintaxe para registos TXT SPF

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

A sintaxe básica do registo TX 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 registo TXT como um registo TXT SPF.

• Origens de correio válidas: foram especificadas 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 necessita include:spf.protection.outlook.com no registo TXT SPF para o domínio. Outros serviços de e-mail de terceiros 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 resolvível publicamente do sistema de e-mail de origem. Por exemplo:
      • Um endereço IP individual (por exemplo, 192.168.0.10).
      • Um intervalo de endereços IP com 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, utiliza endereços IP no registo TXT SPF apenas se tiver servidores de e-mail no local que enviam correio a partir do domínio do Microsoft 365 (por exemplo, Exchange Server implementações híbridas). Alguns serviços de e-mail de terceiros também podem utilizar um intervalo de endereços IP em vez de um include: valor no registo TXT do 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 dura) 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.

    Uma vez que também recomendamos o DKIM e o DMARC para domínios do Microsoft 365, as diferenças entre -all (falha forte) e ~all (falha recuperável) são efetivamente eliminadas (o DMARC trata ambos os resultados como uma falha de SPF). O DMARC utiliza o SPF para confirmar que os domínios nos endereços MAIL FROM e From se alinham e a mensagem veio de uma origem válida para o domínio De.

  Dica

  ?all (neutro) também está disponível para sugerir 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. Email proteção de autenticação para subdomínios não definidos é melhor processada pela 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 origens de e-mail válidas no registo SPF, a validação do SPF falha se o marcar exigir demasiadas pesquisas de DNS. Para obter mais informações, veja a secção Troubleshooting SPF TXT records (Resolução de problemas de registos TXT SPF ) mais à frente neste artigo.

Registos TXT SPF para domínios personalizados no Microsoft 365

• Cenário: utiliza contoso.com para e-mail no Microsoft 365 e o Microsoft 365 é a única origem de e-mail de contoso.com.

  SPF TXT record for contoso.com in Microsoft 365 and Microsoft 365 Government Community Cloud (GCC):

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

  SPF TXT record for contoso.com in Microsoft 365 Government Community Cloud High (GCC High) and Microsoft 365 Department of Defense (DoD):

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

  SPF TXT record for contoso.com in Microsoft 365 operated by 21Vianet

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

• Cenário: utiliza contoso.com para e-mail no Microsoft 365 e já configurou o registo TXT SPF no contoso.com com todas as origens de e-mail do domínio. Também é proprietário dos domínios contoso.net e contoso.org, mas não os utiliza para e-mail. Quer 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
  

  Registo TXT SPF para contoso.org:

  v=spf1 -all
  

• Cenário: 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.

  Registo TXT SPF para contoso.com:

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

  Registo TXT SPF para marketing.contoso.com:

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

Resolução de problemas de registos TXT SPF

• Um registo SPF por domínio ou subdomínio: vários registos TXT SPF para o mesmo domínio ou subdomínio causam um ciclo de pesquisa de DNS que faz com que o SPF falhe, pelo que utilize apenas um registo SPF por domínio ou subdomínio.

• Menos de 10 pesquisas DNS: quando os sistemas de e-mail de destino consultam o registo TXT do SPF para obter origens válidas para o domínio de endereço MAIL FROM, a consulta analisa os endereços IP e include: instruções no registo até que a origem da mensagem (em última análise, um endereço IP) corresponda a uma das origens 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 a contagem 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 include: instrução requer, pelo menos, uma pesquisa DNS e poderão ser necessárias mais pesquisas se o include: valor apontar para recursos aninhados. Por outras palavras, ter menos de 10 include: instruções não garante menos de 10 pesquisas 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 para quando a origem da mensagem é validada e não são verificadas mais origens. 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 main domínio de e-mail, 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 pesquisas de registos DNS necessárias para o registo TXT do SPF.

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:

• Usar o DKIM para validar emails enviados de seu domínio personalizado
• Usar DMARC para validar emails

Para e-mails recebidos no Microsoft 365, também poderá ter de configurar setores ARC fidedignos se utilizar serviços que modificam mensagens em trânsito antes da entrega na sua organização. Para obter mais informações, veja Configurar sealers ARC fidedignos.