Cómo detectar correos alojados en Google Suite
La perfilación de correos electrónicos y la identificación del proveedor de alojamiento le permiten conocer mejor a sus clientes. Una dirección alojada en Google Suite puede corresponder a un servicio pago o al alojamiento de una institución académica.
También puede tratarse de una dirección alojada en los servicios de Google desde la época en que se ofrecía gratis “Google Apps for your domain”. En ese caso, no es un servicio prémium de correo pago. La información pública no permite distinguir ambos casos con certeza.
Todo dominio que puede recibir correos tiene registros MX en sus registros DNS. En un dominio de Google Suite, estos registros apuntan a los servidores de correo de Google. Si la dirección es john@example.com y example.com usa GSuite, un registro MX podría verse así:
{
"host": "wsj.com",
"class": "IN",
"ttl": 1800,
"type": "MX",
"pri": 1,
"target": "aspmx.l.google.com"
}
El servidor de destino es aspmx.l.google.com. Este servidor recibe físicamente todos los correos enviados a direcciones ***@example.com.
Para consultar los datos de los registros MX, necesita un servicio que pueda consultar registros DNS. En este ejemplo, puede usar nuestra API de muestra:
http://sampleapis.Decisimo.net/dns/?email=john@example.com
Integre todo en el motor de decisiones de Decisimo
1. Cree un objeto de datos de ejemplo
Cree un objeto de datos de ejemplo para probar las reglas rápidamente. Agregue el atributo $.email con el valor de prueba journalist@wsj.com (usan GSuite).
2. Cree una fuente de datos
En Data sources, seleccione New para abrir el formulario junto a AI Assistant. Describa el proveedor y la llamada, revise la configuración HTTP y aplíquela.
3. Cree un flujo de decisiones
En el nuevo flujo de decisiones, agregue tres componentes: inicio, datos externos y conjunto de reglas. Luego conéctelos en ese orden.
Start indica al motor dónde comienza la ejecución. External data llama en paralelo a las fuentes de datos definidas mediante las opciones de ese componente. Rule set contiene el conjunto de reglas seleccionado.
4. Configure los datos externos
Agregue una opción de datos externos para la verificación DNS que acaba de crear. La verificación espera que el parámetro email contenga la dirección de correo. Configure ese parámetro para que use el valor del atributo $.email del objeto de datos.
5. Cree un release intermedio y pruebe
Ahora puede crear un release y probar el flujo de decisiones. El release genera una instantánea del flujo actual y de todos sus componentes. Así puede probar su comportamiento durante la ejecución.
En la página del release, a la izquierda, seleccione en la lista desplegable el objeto de datos de prueba y haga clic en load. Debajo aparecerá un objeto JSON con los atributos del correo.
Cuando se cargue el objeto de datos, haga clic en Test release, espere un momento y revise el resultado de la ejecución de prueba. Al terminar, a la derecha verá el JSON inicial con los datos que el motor recopiló durante la ejecución.
El resultado muestra los datos que cargó la verificación DNS en la ruta output - check - dns-check - mx. Allí aparece una matriz con los registros MX encontrados para la dirección de correo.
Si mx no contiene registros, el dominio no recibe correos. Puede haber un registro o 10.
Para obtener esos datos MX en la regla, debe escribir una expresión JSONPath. Le recomendamos copiar la respuesta o el resultado JSON. Si no sabe escribir expresiones JSONPath, puede usar sitios como jsonpath.com.
6. Cree una regla
Con los datos que espera recibir, cree un conjunto de reglas para determinar si un correo está alojado en Google.
La regla evaluará el contenido de $.output.check.dns-check.mx[0].target. Como los usuarios de Gmail suelen tener varios registros, no compararemos el valor exacto. Consideraremos que el correo está alojado en Google si el destino termina en aspmx.l.google.com.
Cree dos reglas: una para detectar el alojamiento en Google y otra para identificar que no es Google GSuite.
Después, actualice el componente del conjunto de reglas en el flujo de decisiones. Seleccione el conjunto de reglas, guarde los cambios y vuelva a probar y crear un release.
7. Pruebe, cree el endpoint y haga el despliegue
Ahora puede comprobar si la detección funciona. En principio, wsj.com debería dar como resultado “is google”. Para cualquier otro dominio, el resultado debería ser no.
Si las pruebas funcionan, configure un endpoint. Créelo en una instancia lo más cerca posible de sus servidores. Si está en Europa, use una instancia europea. Si está en Asia, use una asiática. Elegir otra región puede sumar varios cientos de milisegundos al tiempo de respuesta.
Cuando el endpoint esté listo, vuelva a Releases y seleccione el último release que funcionó. Pruébelo otra vez para confirmarlo. Si todo funciona, seleccione su endpoint al final de la página y haga clic en deploy. Cuando aparezca el mensaje que confirma el despliegue, podrá enviar solicitudes al endpoint de la API, que ejecutará el flujo de decisiones que acaba de probar.
8. Pruebe el endpoint con Postman
Copie el JSON de la prueba y la URL del endpoint, abra Postman y comience a probar.
En Postman, seleccione el método POST. Pegue la URL del endpoint en el campo de URL de la solicitud. Haga clic en Body y seleccione Raw. Luego, a la derecha, cambie text a JSON. Pegue debajo el JSON con el correo y haga clic en SEND.
Si todo funciona, recibirá la misma respuesta que en la prueba del portal.
9. Integre el endpoint en su sistema
Si todo funciona correctamente, integre el endpoint en su sistema para actualizar las reglas y desplegar cambios rápidamente. El endpoint no cambia. Puede modificar las reglas del flujo de decisiones cuando lo necesite.
¡Le deseamos éxito con sus decisiones!
Preguntas frecuentes
¿La regla debe revisar el primer registro MX o todos?
Revise todos los destinos MX, no solo el primero. DNS puede devolver varios registros y el orden puede variar. Normalice los nombres de host y compárelos con una lista actualizada de los servidores de correo publicados por Google, incluidos los alternativos. Si solo busca destinos terminados en “aspmx.l.google.com”, puede pasar por alto configuraciones válidas de Google.
¿Una consulta MX permite saber si Google Workspace es pago?
No. Una consulta MX identifica el servicio de correo que gestiona un dominio, pero no permite distinguir con certeza entre Google Workspace pago y el alojamiento gratuito heredado de Google Apps. Interprete el resultado como “correo alojado en Google”, no como prueba de que la cuenta es paga. Si esa diferencia afecta una decisión, pregúntele al cliente o verifíquela mediante otra fuente autorizada por él.
¿Cómo debe tratar la regla un dominio sin registros MX o una consulta DNS fallida?
Mantenga separados los resultados “sin registros MX” y “falló la consulta DNS”. Un dominio sin registros MX aún podría recibir correo mediante un registro de dirección alternativo. En cambio, un tiempo de espera agotado o un error del resolver significa que no se conoce el proveedor. Ante un fallo, devuelva un resultado distinto de proveedor desconocido o error de consulta y defina explícitamente cómo debe tratarlo la decisión posterior.
¿Qué debe probar antes de desplegar la verificación de correo?
Pruebe dominios con destinos MX principales y alternativos de Google, un proveedor que no sea Google, varios registros MX, ningún registro MX y un tiempo de espera agotado de DNS. Confirme que un fallo temporal de consulta no se convierta en un resultado concluyente de “no es Google”. Después, pruebe el endpoint desplegado con las mismas entradas y compare sus respuestas con las de la prueba del release.
¿Con qué frecuencia debe actualizar el servicio los resultados MX?
Use el tiempo de vida del registro DNS como referencia inicial para la caché y evite conservar los resultados del proveedor más allá de ese período. Una caché fija de larga duración puede dejar desactualizada la clasificación si un dominio cambia de proveedor de correo. Si recibe solicitudes frecuentes, almacene en caché las respuestas DNS según su TTL y trate los fallos de consulta por separado de los resultados almacenados.
