Como identificar e-mails hospedados no Google Suite

Publicado em: 2026-10-30

O perfil de e-mail e a identificação do provedor de hospedagem ajudam você a conhecer melhor seus clientes. Quando um endereço de e-mail usa o Google Suite, isso pode indicar um serviço pago ou a hospedagem de uma instituição acadêmica.

Também é possível que o endereço use serviços do Google desde a época em que o “Google Apps for your domain” era oferecido gratuitamente. Nesse caso, não se trata de um serviço premium de e-mail pago. Não é possível identificar essa diferença com segurança usando informações públicas.

Todo domínio que recebe e-mails tem registros MX nos registros DNS. Em um domínio do Google Suite, esses registros apontam para servidores de e-mail do Google. Se o endereço for john@example.com e o domínio example.com usar GSuite, um registro MX poderia ser assim:

{
          "host": "wsj.com",
          "class": "IN",
          "ttl": 1800,
          "type": "MX",
          "pri": 1,
          "target": "aspmx.l.google.com"
    }

O endereço do servidor de destino, aspmx.l.google.com, aparece claramente aqui. Esse servidor recebe fisicamente todos os e-mails enviados a endereços ***@example.com.

Para consultar os dados do registro MX, precisamos de um serviço que faça consultas aos registros DNS. Neste exemplo, podemos usar nossa API de exemplo:

http://sampleapis.Decisimo.net/dns/?email=john@example.com

Como reunir tudo isso no mecanismo de decisão da Decisimo

1. Criar um objeto de dados de exemplo

Vamos criar um objeto de dados de exemplo para testar as regras rapidamente. Adicione o atributo $.email com o valor fictício journalist@wsj.com (a WSJ usa GSuite).

A página Data objects exibe a janela Add data object, com os campos Title e arquivo JSON de exemplo opcional, além dos controles Close e Create

A janela Add data object attribute mostra $.email como caminho de mapeamento e journalist@wsj.com como valor fictício

2. Criar uma fonte de dados

Em Data sources, clique em New para abrir o formulário ao lado do AI Assistant. Descreva o provedor e a chamada, revise as configurações HTTP e aplique-as.

3. Criar um fluxo de decisão

No novo fluxo de decisão, adicione três etapas: start, external data e rule set. Depois, conecte-as nessa ordem.

Fluxo de decisão com as etapas de execução

Fluxo de decisão com todas as etapas

Start indica ao mecanismo onde a execução começa. External data é uma etapa que, pelas opções da etapa, chama em paralelo as fontes de dados configuradas. Rule set contém o conjunto de regras selecionado.

4. Configurar a etapa External data

Agora, adicione uma opção para external data, que corresponde à consulta DNS que acabamos de criar. Sabemos que a consulta espera o endereço de e-mail no parâmetro email. Configure esse parâmetro para usar o valor do atributo $.email do objeto de dados.

Formulário da etapa do fluxo de decisão com o título External Data, o ID external-data-call e a opção DNS Check

Opções da etapa External data do fluxo de decisão

Configuração de uma etapa External data em um fluxo de decisão

Configuração do parâmetro da chamada de dados externos, uma opção da etapa

5. Release intermediário e teste

Agora podemos fazer o release e testar o fluxo de decisão. O release cria uma cópia do fluxo atual e de todas as suas partes. Assim, você pode testar o comportamento do fluxo durante a execução.

Janela de confirmação do release, com os botões “Close” e “Go & test it out” sobre o fluxo de decisão

Mensagem de confirmação de que o release foi concluído

Na página de release, à esquerda, selecione na lista o objeto de dados de teste e clique em load. Um objeto JSON com os atributos do e-mail aparecerá abaixo.

Com o objeto de dados carregado, clique no botão Test release, aguarde um instante e confira o resultado da execução de teste. Quando o teste terminar, o painel à direita mostrará o JSON inicial enriquecido com os dados coletados pelo mecanismo durante a execução.

No resultado, você pode conferir os dados trazidos pela consulta DNS em external data. No caminho output - check - dns-check - mx, há uma matriz com os registros MX encontrados para o endereço de e-mail.

Tela de teste do release com a entrada de e-mail, o painel de saída vazio e “Call data sources?” definido como No

Resultado da execução de teste do JSON de exemplo no release

Se não houver registros em mx, o domínio não recebe e-mails. Às vezes há um registro, e às vezes há 10.

Precisamos escrever um JSONPath para obter os dados MX usados pela regra. Recomendo copiar a resposta ou o resultado JSON. Se você não se sentir à vontade para escrever JSONPath, pode usar sites como o jsonpath.com.

6. Criar uma regra

Agora que sabemos quais dados esperar, vamos criar um conjunto de regras para identificar se o e-mail é hospedado pelo Google.

Na regra, vamos avaliar o conteúdo de $.output.check.dns-check.mx[0].target. Como usuários do Gmail costumam ter vários registros, não vamos comparar o valor exato. Vamos considerar o e-mail hospedado pelo Google quando o destino terminar em aspmx.l.google.com.

Editor de regras que identifica destinos MX terminados em aspmx.l.google.com e define $.is_gsuite como true

Regra para identificar GSuite, usando a operação "ends with (case insensitive)"

Vamos criar duas regras: uma para identificar a hospedagem do Google e outra para indicar que ela não é do Google GSuite.

Depois, atualize a etapa do conjunto de regras no fluxo de decisão. Selecione o conjunto de regras, salve e faça o teste e o release novamente.

7. Testar, criar o endpoint e implantar

Agora podemos verificar se o endereço é identificado corretamente. O resultado esperado para wsj.com é “is google”. Para qualquer outro domínio, o resultado deve ser não.

Se o teste funcionar, podemos configurar um endpoint. Crie o endpoint em uma instância fisicamente próxima dos seus servidores. Se você estiver na Europa, use uma instância europeia. Se estiver na Ásia, use uma asiática. Uma região diferente pode acrescentar várias centenas de milissegundos ao tempo de resposta.

Formulário do API Endpoint para simple-email-check, com chave de API, instância EUR–Belgium–2, URI POST e solicitação curl

API Endpoint para implantar regras de decisão

Quando o endpoint estiver pronto, volte à página de releases e selecione o último release que funcionou. Teste novamente para confirmar. Se tudo estiver funcionando, selecione seu endpoint na parte inferior da página e clique em deploy. Quando a mensagem confirmar que a implantação foi concluída, você poderá enviar solicitações ao endpoint da API, que executará o fluxo de decisão testado.

8. Testar o endpoint no Postman

Copie o JSON do teste e a URL do endpoint, abra o Postman e comece a testar.

No Postman, selecione o método POST. Cole a URL do endpoint no campo de URL da solicitação. Clique em Body, selecione Raw e, à direita, mude o formato de texto para JSON. Cole abaixo o JSON com o e-mail e clique em SEND.

Se tudo funcionar, você deverá receber a mesma resposta do teste no portal.

O Postman mostra uma solicitação POST com um corpo JSON de e-mail e uma resposta 200 OK com registros MX do Google

Resultado do teste da API REST do endpoint no Postman

9. Integrar ao seu sistema

Se tudo estiver funcionando corretamente, integre o endpoint ao seu sistema para atualizar as regras e implantar mudanças rapidamente. O endpoint continua o mesmo. Você pode alterar as regras do fluxo de decisão sempre que precisar.

Boas decisões!

Perguntas frequentes

A regra deve verificar o primeiro registro MX ou todos eles?

Verifique todos os destinos MX, não apenas o primeiro. O DNS pode retornar vários registros, e a ordem pode mudar. Normalize os nomes dos hosts e compare-os com uma lista atualizada dos servidores de e-mail publicados pelo Google, incluindo os servidores alternativos. Comparar apenas destinos terminados em “aspmx.l.google.com” pode deixar passar configurações válidas do Google.

Uma consulta MX informa se o Google Workspace é pago?

Não. Uma consulta MX identifica o serviço de e-mail que atende um domínio, mas não permite diferenciar com segurança uma assinatura paga do Google Workspace da hospedagem gratuita antiga do Google Apps. Considere o resultado como “e-mail hospedado pelo Google”, não como prova de uma conta paga. Se essa diferença afetar uma decisão, pergunte ao cliente ou confirme por outra fonte que ele autorize.

Como a regra deve tratar um domínio sem registros MX ou uma consulta DNS com falha?

Trate “sem registros MX” separadamente de “falha na consulta DNS”. Um domínio sem registros MX ainda pode receber e-mails por meio de um registro de endereço alternativo. Já um tempo limite excedido ou um erro do resolvedor significa que o provedor é desconhecido. Em caso de falha, retorne um resultado separado, como desconhecido ou erro na consulta, e defina explicitamente como a decisão seguinte deve tratá-lo.

O que devo testar antes de implantar a verificação de e-mail?

Teste domínios com destinos MX principais e alternativos do Google, um provedor que não seja do Google, vários registros MX, nenhum registro MX e um tempo limite na consulta DNS. Confirme que uma falha temporária na consulta não resulta em uma identificação categórica de “não é Google”. Depois, teste no endpoint implantado as mesmas entradas e compare as respostas com o teste do release.

Com que frequência o serviço deve atualizar os resultados MX?

Use o tempo de vida do registro DNS como referência inicial para o cache e evite manter os resultados do provedor por mais tempo que esse período. Um cache fixo e longo pode deixar a classificação desatualizada quando o domínio muda de provedor de e-mail. Se as solicitações forem frequentes, armazene as respostas DNS em cache de acordo com o TTL e trate as falhas de consulta separadamente dos resultados em cache.