Autenticação de e-mail no Outlook: configuração de SPF, DKIM e DMARC

A maioria dos remetentes segue o guia de configuração da autenticação de e-mail do Outlook, adiciona os registos DNS necessários, vê as marcas de verificação verdes numa ferramenta de validação e parte do princípio de que a autenticação está concluída. Depois, a capacidade de entrega diminui, as mensagens começam a ir parar à pasta de Lixo Eletrónico ou a Microsoft assinala problemas de autenticação que parecem impossíveis, uma vez que tudo parece estar correto, pelo menos no papel.

A autenticação de e-mail no Outlook é mais complexa do que a simples publicação de registos SPF, DKIM e DMARC. O Microsoft 365 tem os seus próprios requisitos de configuração, erros comuns de configuração e verificações de autenticação que podem ser aprovadas no DNS, mas falhar quando o Outlook recebe efetivamente o seu e-mail.

Neste guia, irá aprender como funciona a autenticação de e-mail no Outlook, como configurar corretamente o SPF, o DKIM e o DMARC para o Microsoft 365, como os requisitos da Microsoft têm vindo a evoluir e como verificar se a sua autenticação está realmente a funcionar em condições reais de receção.

Por que razão a autenticação do Outlook é importante em 2026 

Se estiver a enviar e-mails através do Microsoft 365, o Outlook exige agora que o SPF, o DKIM e o DMARC estejam configurados corretamente para que as suas mensagens sejam consideradas fiáveis.

Eis uma breve cronologia da aplicação das regras de autenticação do Outlook:

• Fevereiro de 2024: O Google e o Yahoo começaram a aplicar requisitos de autenticação aos remetentes em massa, tornando o SPF, o DKIM e o DMARC obrigatórios para programas de e-mail de grande volume.
• Abril de 2025: A Microsoft anunciou requisitos semelhantes para remetentes em massa que enviam mensagens para as caixas de entrada do Outlook.com, Hotmail, Live e MSN.
• Maio de 2025: Iniciou-se a aplicação inicial das regras, com as mensagens que não cumpriam os requisitos a serem cada vez mais encaminhadas para a pasta de lixo eletrónico.
• Após maio de 2025: a Microsoft alertou que o correio de grande volume que não esteja em conformidade será posteriormente rejeitado até que os registos DNS sejam corrigidos.
• A Microsoft identifica essas rejeições de autenticação com o código 550 5.7.515 quando o domínio remetente não cumpre o nível de autenticação exigido.
• 2026: A autenticação é agora o padrão mínimo esperado. As falhas de autenticação podem levar à classificação como lixo eletrónico ou à rejeição, enquanto a reputação do remetente e o conteúdo continuam a determinar se o e-mail autenticado chega à caixa de entrada.

Os requisitos formais da Microsoft destinam-se a remetentes com volumes mais elevados, mas os fornecedores de caixas de correio utilizam cada vez mais a autenticação como um indicador de confiança para todos os e-mails.

Para as equipas de marketing de saída B2B, a realidade prática é simples: quer se enviem 200 e-mails por dia ou 20 000, o SPF, o DKIM e o DMARC já não são opcionais. São a base sobre a qual assenta qualquer outro indicador de capacidade de entrega.

A autenticação, por si só, não garante que o e-mail chegue à caixa de entrada, mas se a autenticação falhar, o seu e-mail pode nem sequer chegar à caixa de entrada.

Como configurar o SPF para o Outlook / Microsoft 365

O SPF indica ao Outlook quais os servidores autorizados a enviar e-mails em nome do seu domínio. No caso do Microsoft 365, isto significa publicar um registo SPF que autorize a infraestrutura de envio da Microsoft, bem como quaisquer outras plataformas que enviem e-mails utilizando o seu domínio.

Ao configurar o SPF:

• Publique um único registo TXT SPF para o domínio.
• Incluir o mecanismo SPF da Microsoft: include:spf.protection.outlook.com.
• Adicione todas as plataformas de envio válidas, tais como o seu CRM, plataforma de marketing, ferramenta de contacto, serviço de apoio ao cliente ou sistema de faturação.
• Sempre que possível, utilize os mecanismos de inclusão recomendados pelo fornecedor, em vez de adicionar manualmente endereços IP.
• Consulte o registo sempre que for adicionada uma nova plataforma de envio.

Um registo SPF típico do Microsoft 365 tem um aspeto semelhante a este:

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

A maioria das organizações precisará de incluir declarações adicionais relativas a outras ferramentas de envio.

Um dos problemas mais comuns relacionados com o SPF é a ultrapassagem do limite de 10 consultas DNS. Cada mecanismo «include:» consome consultas e, à medida que mais ferramentas são adicionadas ao longo do tempo, o registo pode tornar-se demasiado complexo para que os fornecedores de receção o avaliem corretamente.

Antes de guardar a sua configuração do SPF:

• Confirme se existe apenas um registo SPF para o domínio.
• Verifique se todas as plataformas de envio legítimas estão incluídas.
• Verifique se o registo se mantém dentro dos limites de pesquisa do SPF.
• Teste o SPF após efetuar alterações para garantir que é aprovado com sucesso.

Depois de configurar corretamente o SPF, o próximo passo é ativar o DKIM para que o Outlook possa verificar se as suas mensagens não foram alteradas durante a entrega.

Uma pesquisa de DNS apenas confirma que o registo é válido, mas não indica se a verificação SPF é bem-sucedida quando o Outlook recebe efetivamente a mensagem. O Verificador SPF gratuito da MailReach testa a autenticação de ponta a ponta em condições reais de receção e ajuda a identificar problemas de configuração que as ferramentas que se limitam ao DNS podem não detetar. 

Como configurar o DKIM para o Outlook / Microsoft 365

O DKIM ajuda o Outlook a verificar se um e-mail foi efetivamente enviado pelo seu domínio e se não foi alterado depois de sair do servidor de envio. No caso do Microsoft 365, a configuração do DKIM requer alguns passos adicionais, uma vez que o seu domínio personalizado não é autenticado automaticamente por predefinição.

Muitos remetentes partem do princípio de que o DKIM já está configurado, uma vez que a Microsoft assina os e-mails enviados utilizando a sua própria infraestrutura. No entanto, essa assinatura predefinida autentica o domínio da Microsoft, e não o seu. Para autenticar o seu próprio domínio, é necessário configurar o DKIM separadamente.

Ao configurar o DKIM:

• Publique os dois registos CNAME DKIM gerados pelo Microsoft 365 (selector1 e selector2).
• Ative a assinatura DKIM para o seu domínio personalizado no portal do Microsoft Defender.
• Utilize chaves de 2048 bits sempre que a Microsoft as suportar.
• Verifique se a assinatura DKIM está ativa após a propagação dos registos.
• Configure um registo DKIM distinto para cada plataforma de envio adicional que utilize o seu domínio.

Se o seu domínio enviar e-mails através de várias plataformas, cada uma delas terá o seu próprio seletor DKIM e a sua própria chave de assinatura. Um registo DKIM criado para o Microsoft 365 não autentica automaticamente as mensagens enviadas através do seu CRM, plataforma de contacto, serviço de apoio ao cliente ou ferramenta de marketing.

Um dos problemas de configuração mais comuns é a mensagem «DKIM não configurado» aparecer mesmo depois de adicionar os registos necessários. Isto deve-se frequentemente a atrasos na propagação do DNS ou a seletores configurados incorretamente.

Após a configuração:

• Confirme se ambos os registos CNAME estão publicados corretamente.
• Verifique se a assinatura DKIM está ativada no Microsoft 365.
• Verifique se o DKIM está a funcionar nas mensagens entregues, e não apenas no DNS.
• Repita o teste sempre que adicionar uma nova plataforma de envio.
• Verifique se o domínio de assinatura DKIM corresponde ao seu domínio «De:» para o DMARC.

A existência de um registo DKIM no DNS não garante que a autenticação DKIM seja bem-sucedida quando o Outlook recebe a mensagem. Verifique sempre o resultado da autenticação nos e-mails entregues, e não apenas a configuração do DNS.

O verificador DKIM gratuito da MailReach faz esta verificação de ponta a ponta, identificando as incompatibilidades entre o seletor e a chave, incluindo um domínio que continua a assinar como onmicrosoft.com, que as ferramentas baseadas apenas no DNS consideram válido. 

Como configurar o DMARC

O DMARC baseia-se no SPF e no DKIM. Verifica se pelo menos um desses métodos de autenticação é bem-sucedido e se corresponde ao domínio indicado no endereço «De:» visível. Além disso, indica aos fornecedores de caixas de correio o que fazer quando a autenticação falha.

Muitos guias de configuração do DMARC recomendam passar diretamente para p=reject, para obter a máxima proteção. Para a maioria das organizações, especialmente aquelas que utilizam várias plataformas de envio, isso é arriscado. Se os remetentes legítimos não tiverem sido devidamente autenticados, uma política DMARC rigorosa pode bloquear e-mails empresariais válidos.

Ao configurar o DMARC:

• Publique um registo TXT DMARC em _dmarc.yourdomain.com.
• Comece com uma política de monitorização definida como p=nenhuma.
• Adicione um endereço de notificação agregada utilizando a etiqueta «rua=».
• Verifique se o SPF ou o DKIM são válidos e se correspondem ao seu domínio «De:».
• Analise os relatórios antes de introduzir alterações nas políticas.

Assim que os relatórios DMARC estiverem ativos:

• Analise os relatórios para identificar todas as plataformas que enviam e-mails em nome do seu domínio.
• Verifique se existem falhas de autenticação e de alinhamento.
• Resolver os problemas relacionados com o SPF, o DKIM e o alinhamento de domínios.
• Confirme se todos os remetentes legítimos cumprem as regras do DMARC.
• Continue a monitorizar até que os resultados sejam consistentemente limpos.

Após a conclusão da monitorização:

• Mudar para p=quarantine para enviar os e-mails com falha para a pasta de spam.
• Continue a analisar os relatórios e a estar atento a eventuais problemas.
• Mude para «p=reject» apenas quando tiver a certeza de que todos os e-mails legítimos passam na autenticação.

Iniciar no modo de monitorização permite-lhe ter uma visão clara da forma como os e-mails são enviados a partir do seu domínio e ajuda a evitar que mensagens legítimas sejam bloqueadas por uma política excessivamente agressiva.

Como verificar se a autenticação do Outlook funciona realmente

Muitos remetentes param depois de verificar o DNS e partem do princípio de que tudo está a funcionar. O problema é que pode existir um registo DNS, mas a autenticação continua a falhar devido a problemas de alinhamento, erros de configuração, incompatibilidades de seletores ou uma configuração incompleta.

Siga o procedimento abaixo para verificar a autenticação em condições reais de receção.

Passo 1: Confirmar se os registos existem no DNS

Comece por verificar se os seus registos SPF, DKIM e DMARC estão publicados corretamente.

Verifique se:

• Existe um registo SPF TXT para o seu domínio.
• Os seus seletores DKIM estão publicados e acessíveis.
• Existe um registo DMARC em _dmarc.yourdomain.com.
• Os registos contêm os valores esperados do seu fornecedor de e-mail.

Isto confirma que a configuração está visível publicamente, mas não confirma que a autenticação seja bem-sucedida.

Passo 2: Enviar um e-mail verdadeiro para o Outlook

A autenticação é verificada quando o Outlook recebe uma mensagem.

Envie um e-mail de teste a partir da mesma plataforma que utiliza normalmente para contacto, marketing ou correspondência empresarial para:

• Uma caixa de correio do Outlook.com
• Uma caixa de correio do Hotmail.com
• Uma caixa de correio empresarial do Microsoft 365, se possível

A utilização de caixas de entrada reais ajuda-o a verificar como a Microsoft processa as suas mensagens na prática.

Passo 3: Verificar os resultados do SPF

Abra a mensagem entregue e verifique os resultados da autenticação.

Verifique se:

• O SPF aparece como «Aprovado».
• O servidor remetente está autorizado pelo seu registo SPF.
• O domínio autenticado corresponde ao domínio que esperava.

Se o SPF falhar, o Outlook não consegue verificar se o servidor de envio está autorizado a enviar em nome do seu domínio.

Passo 4: Verificar os resultados do DKIM

Em seguida, verifique a assinatura DKIM.

Confirme que:

• O DKIM aparece como «Aprovado».
• A assinatura foi validada com sucesso.
• O domínio de assinatura pertence à sua organização.
• Está a ser utilizado o seletor correto.

Um registo DKIM pode existir no DNS, mesmo que a assinatura propriamente dita falhe durante a verificação, razão pela qual é importante testar o correio entregue.

Passo 5: Verificar os resultados do DMARC

O DMARC também deve transmitir a mensagem recebida.

Verifique se:

• O DMARC apresenta o resultado «Aprovado».
• O SPF ou o DKIM foram validados com sucesso.
• O domínio autenticado corresponde ao domínio visível no campo «De:».
• Não foram comunicadas falhas de alinhamento.

Este passo confirma que o Outlook interpreta a sua autenticação exatamente como pretendido.

Passo 6: Verificar a localização na Caixa de Entrada

A autenticação e a colocação na caixa de entrada não são a mesma coisa.

Mesmo que o SPF, o DKIM e o DMARC sejam todos aprovados:

• O e-mail pode ainda assim acabar na pasta de Lixo Eletrónico.
• Problemas de reputação podem afetar a classificação.
• Os sinais relativos ao conteúdo e ao envolvimento podem influenciar as decisões de filtragem.

Verifique se a mensagem chega a:

• Caixa de entrada
• Lixo
• Outras pastas filtradas

Isto ajuda a determinar se se trata de um problema de autenticação ou de reputação.

Fazer isto manualmente em várias caixas de entrada é tedioso. O Teste de Entregabilidade de E-mail gratuito do MailReach envia mensagens através de uma rede de caixas de entrada reais do Google Workspace e do Microsoft 365 e mostra se as mensagens vão parar à caixa de entrada, à pasta de spam ou às pastas filtradas, juntamente com os resultados de SPF, DKIM e DMARC e uma lista de correções por ordem de prioridade, para que possa distinguir um problema de autenticação de um problema de reputação num único teste. 

Passo 7: Voltar a testar após cada alteração

A autenticação deve ser verificada sempre que:

• Adicionar uma nova plataforma de envio.
• Mudar de fornecedor de e-mail.
• Atualizar os registos DNS.
• Ativar um novo seletor DKIM.
• Altere a sua política DMARC.

Pequenas alterações na configuração podem afetar os resultados da autenticação sem que se verifiquem erros evidentes.

Uma pesquisa de DNS indica que os registos existem. Um teste de autenticação na prática permite saber se o Outlook confia realmente neles. É este último que importa.

Erros comuns na autenticação do Outlook (e como resolvê-los)

A maioria dos problemas de autenticação do Outlook é causada por erros de configuração que, à primeira vista, parecem corretos, mas que dão errado quando a Microsoft analisa efetivamente o e-mail. A boa notícia é que a maioria destes problemas segue padrões previsíveis. Assim que se souber o que procurar, geralmente são fáceis de identificar e resolver.

O SPF excede o limite de 10 consultas

Os registos SPF podem conter, no máximo, 10 consultas DNS. Cada instrução «include:» consome parte desse limite, uma vez que o Outlook tem de seguir essas referências para determinar se um servidor de envio está autorizado.

Este problema surge frequentemente de forma gradual. Um domínio começa com o Microsoft 365 e, posteriormente, adiciona um CRM, uma plataforma de marketing, um serviço de assistência, uma ferramenta de divulgação e alguns outros serviços. O registo SPF continua a existir no DNS, mas assim que o limite de consultas é excedido, o Outlook deixa de o poder avaliar na íntegra. O SPF pode falhar, mesmo que nada pareça estar avariado.

Como resolver o problema:

• Audite todas as plataformas atualmente autorizadas a enviar e-mails em nome do seu domínio.
• Remova as instruções «include:» obsoletas ou que não sejam utilizadas.
• Consolidar as ferramentas de envio sempre que possível.
• Monitorizar o número de consultas sempre que for adicionada uma nova plataforma.
• Volte a testar o SPF após cada alteração para garantir que continua a ser aprovado.

Recorrendo ao DKIM predefinido da Microsoft

O Microsoft 365 assina automaticamente os e-mails utilizando uma assinatura DKIM do onmicrosoft.com. Muitos remetentes partem do princípio de que isto significa que o DKIM está totalmente configurado.

A assinatura predefinida da Microsoft autentica o domínio da Microsoft, e não o seu domínio personalizado. O seu e-mail pode aparecer como assinado por DKIM, embora o seu próprio domínio permaneça não autenticado para efeitos de alinhamento DMARC.

Como resolver o problema:

• Publique os dois registos CNAME DKIM que a Microsoft gera para o seu domínio.
• Ative a assinatura DKIM para o domínio personalizado no Microsoft Defender.
• Verifique se o DKIM está a assinar com o seu domínio e não com o onmicrosoft.com.
• Configure registos DKIM separados para cada plataforma de envio adicional.
• Teste o DKIM utilizando mensagens reais que tenham sido entregues, e não apenas o DNS.

O DMARC é aprovado no papel, mas falha no alinhamento

A publicação de um registo DMARC não significa automaticamente que o DMARC seja aprovado.

O DMARC exige que o SPF ou o DKIM correspondam ao domínio indicado no endereço «De:» visível. Uma mensagem pode passar na verificação do SPF e, mesmo assim, falhar na verificação do DMARC se a autenticação for efetuada num domínio diferente.

Esta é uma causa comum de falhas de autenticação no Outlook, uma vez que o registo existe, as verificações parecem estar configuradas e, mesmo assim, o DMARC continua a falhar durante a entrega.

Como resolver o problema:

• Verifique se o domínio autenticado por SPF corresponde ao domínio visível no campo «De:».
• Verifique se o domínio de assinatura DKIM corresponde ao domínio visível no campo «De:».
• Analise os relatórios DMARC para detetar falhas de alinhamento.
• Teste e-mails reais, em vez de se basear em consultas de DNS.
• Resolva os problemas de alinhamento antes de avançar para além de p=none.

Passar para p=rejeitar demasiado cedo

Muitos guias de configuração do DMARC recomendam passar diretamente para p=reject, para obter a máxima proteção. Para as organizações que utilizam várias ferramentas, isto pode criar problemas muito rapidamente.

Os CRMs, sistemas de faturação, serviços de assistência e aplicações internas esquecidos continuam, muitas vezes, a enviar e-mails após a ativação da aplicação do DMARC. Se esses sistemas não forem devidamente autenticados, os e-mails legítimos da empresa podem ser bloqueados.

Como resolver o problema:

• Comece com p=none e recolha os relatórios DMARC.
• Identifique todos os sistemas que enviam e-mails a partir do seu domínio.
• Corrija primeiro os erros de autenticação e de alinhamento.
• Passe para p=quarentena antes de considerar p=rejeitar.
• Só se deve avançar para a aplicação total da política depois de um acompanhamento contínuo ter confirmado que o correio legítimo está a passar.

Partindo do princípio de que «Registo publicado» significa «a funcionar»

Uma pesquisa de DNS apenas confirma que existe um registo. Não confirma que o Outlook valide com sucesso o SPF, o DKIM e o DMARC quando é recebido um e-mail.

Isto cria uma falsa sensação de segurança. Tudo parece estar corretamente configurado no DNS, enquanto os e-mails continuam a ir parar à pasta de lixo eletrónico ou a falhar nas verificações de autenticação durante a entrega.

Como resolver o problema:

• Envie e-mails de teste para as caixas de entrada do Outlook e do Gmail.
• Verifique os resultados do SPF, DKIM e DMARC nos cabeçalhos da mensagem recebida.
• Faça um teste após cada alteração no DNS ou na plataforma de envio.
• Acompanhe regularmente os resultados da autenticação.
• Recorra a testes de autenticação de ponta a ponta, em vez de uma validação baseada apenas no DNS.

Utilizar um subdomínio para abordagens não solicitadas

Muitos remetentes partem do princípio de que a utilização de um subdomínio isola completamente as abordagens não solicitadas do seu e-mail profissional principal.

Embora os subdomínios criem alguma separação, os fornecedores de caixas de correio eletrónico podem, ainda assim, associá-los ao domínio principal. Se as campanhas de divulgação gerarem reclamações ou um baixo nível de interação, os sinais de reputação podem continuar a afetar a marca em geral.

Como resolver o problema:

• Utilize um domínio secundário distinto para a abordagem não solicitada.
• Autentique o domínio secundário de forma independente.
• Aqueça o domínio de divulgação antes de aumentar o volume.
• Separar o tráfego de divulgação, de marketing e transacional.
• Proteja o domínio principal da sua empresa contra riscos desnecessários para a sua reputação.

Perseguir listas negras em vez de recuperar a reputação

Um alerta de lista negra parece frequentemente urgente, razão pela qual muitos remetentes se concentram, em primeiro lugar, na verificação da lista negra quando a taxa de entrega diminui.

Na realidade, o Outlook baseia-se principalmente nos sistemas de reputação da própria Microsoft, nos dados relativos a reclamações, nos sinais de interação e nos resultados de autenticação. A maioria das listas negras públicas tem pouco impacto na colocação das mensagens na caixa de entrada do Outlook.

Se os e-mails autenticados estiverem constantemente a ser encaminhados para a pasta de lixo eletrónico, o problema subjacente prende-se normalmente com a reputação, o envolvimento ou o comportamento de envio, e não com a inclusão numa lista negra.

Como resolver o problema:

• Verifique se a lista negra é efetivamente utilizada pela Microsoft.
• Concentre-se, em primeiro lugar, nas taxas de reclamação e na reputação do remetente.
• Melhorar a autenticação e a qualidade das listas.
• Acompanhe a colocação na caixa de entrada, em vez de se limitar a verificar apenas o estado na lista negra.
• Encare as verificações da lista negra como um sinal de diagnóstico, e não como uma estratégia de entregabilidade.

Manutenção da autenticação de e-mail do Outlook ao longo do tempo

Os fornecedores de serviços de e-mail continuam a tornar os seus requisitos de confiança cada vez mais rigorosos. A autenticação está a deixar de ser uma vantagem competitiva para se tornar, cada vez mais, uma expectativa básica. Os domínios com melhor desempenho são aqueles que analisam regularmente as suas fontes de envio, verificam a autenticação após alterações, monitorizam os relatórios DMARC e detetam problemas antes que estes afetem a entrega.

O próximo passo não consiste simplesmente em publicar registos e seguir em frente. Trata-se de verificar se o Outlook visualiza o seu e-mail da forma que pretende. Isso significa testar em condições reais de receção, monitorizar a autenticação ao longo do tempo e garantir que as novas ferramentas não introduzem falhas de forma imperceptível.

O Teste de Entregabilidade de E-mail da MailReach verifica a autenticação de ponta a ponta, em vez de apenas no DNS, e os testes automatizados com alertas no Slack ou através de webhooks assinalam qualquer desvio assim que uma nova ferramenta, sem dar por isso, quebra um recorde. 

Perguntas frequentes

O Microsoft 365 configura o DKIM automaticamente? 

Não se aplica ao seu domínio personalizado. O Microsoft 365 assina com uma chave «onmicrosoft.com» predefinida por predefinição, o que não é o mesmo que autenticar o seu próprio domínio. Tem de publicar dois registos CNAME e ativar a assinatura DKIM para o seu domínio no portal do Defender.

Por que é que os meus e-mails autenticados continuam a ir para a pasta «Lixo» do Outlook? 

Porque a autenticação é apenas um dos três pilares da capacidade de entrega. A Microsoft também tem em conta a reputação do remetente (envolvimento) e o conteúdo. Pode cumprir os requisitos de SPF, DKIM e DMARC e, mesmo assim, ser classificado como lixo eletrónico se a sua reputação for fraca ou se o seu conteúdo for bloqueado pelos filtros. 

Quais são os requisitos da Microsoft para remetentes em massa? 

De acordo com as regras do Google e do Yahoo de fevereiro de 2024, a Microsoft exige que os remetentes de grande volume (cerca de 5 000 ou mais mensagens por dia para o Outlook.com, Hotmail e Live) se autentiquem através de SPF, DKIM e DMARC, sob pena de as mensagens serem classificadas como lixo eletrónico e bloqueadas. No caso de e-mails de saída B2B, é necessário autenticar-se independentemente do volume.

O DMARC é obrigatório para o Outlook? 

Para remetentes que enviam grandes volumes, sim. Para todos os outros, é altamente recomendado e cada vez mais esperado. Comece com p=none para monitorizar e, depois, passe à aplicação da regra à medida que os seus relatórios confirmarem que todos os remetentes legítimos cumprem os requisitos.

O « email warmup » corrige o problema de autenticação do Outlook? 

Não. O «warmup» reforça a reputação do remetente, o que constitui um pilar distinto da autenticação. A autenticação consiste na configuração do DNS; o «warmup» gera interação. Ambos são importantes, e o «warmup» destina-se exclusivamente à abordagem a frio no âmbito B2B.

‍