How to detect Google Suite hosted email address

Email profiling and detection of email hosting provider is useful for understanding customers. When email address uses Google Suite, it can mean it is either a premium paid service or hosted for an academic institution.

There is a potential that an email address is hosted at Google services since times when “Google Apps for your domain” were offered free. In such case it is not a premium-paid email service. However, it cannot be detected using publicly available information.

Every domain that has ability to receive e-mails, has MX records in its DNS records. In case of a domain Google Suite, the records point to Google email servers. If email address is [email protected] and example.com uses GSuite, an MX record could look something like this:

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

There we can specifically see the target server address aspmx.l.google.com. This server physically receives all the emails sent to addresses ***@example.com.

To access data about MX records, we need service that can query DNS records. For this purpose, we can use our sample api:

http://sampleapis.Decisimo.net/dns/[email protected] 

Now, let us put it all together in Decisimo decision engine

1. Create sample Data object

We want to create sample data object, so that we can test our rules simply and quickly. There we will add attribute $.email with dummy value [email protected] (they run on GSuite).

2. Create a data source

We can create data source by filling in configuration, or just use the template available and create it from template.

3. Create decision flow

In new decision flow, we add three steps – start, external data, rule set and connect them in this sequence.

Start is indication for the engine, where it shall start executing. External data is a step holder that calls in parallel defined data sources in options part of step. Rule set is a holder for selected rule set.

4. Defining external data step

Next, we add option for external data – the DNS check we have just added. We know the check expects parameter email to contain email address. We define that parameter will be filled with value from the data object attribute $.email.

5. Intermediate release & test

Now we can release and test the decision flow. Release will create snapshot of current decision flow and all parts of it. This way we can test how the current flow behaves during execution.

On release page on the left, we can select from drop down list our testing data object, click load and a JSON object with our email attributes shall appear below.

Once data object is loaded, we can hit Test release button, wait a while, and see result of the mock run. When test is finished, we see on the right initial JSON enriched with data collected by the engine along the way.

In the result, we can see what the external data loaded related to DNS check. In path output – check – dns-check – mx, there is an array of records that were found related to MX of the email address.

If there are no records in mx, the domain does not receive emails. Sometimes there is only one, sometimes there are 10.

We will need to write JSONPath to get those MX details for our rule. I recommend you to copy the JSON response/result. If you are not proficient in writing JSONPath, you can use websites like: jsonpath.com.

6. Create rule

Now that we know, what data we can expect, we create rule set to find out whether an email is Google hosted or not.

In our rule, we will evaluate content of $.output.check.dns-check.mx[0].target. Since gmail users usually have several records, we will not be matching exactly. We will consider that if the target end with aspmx.l.google.com, it is google hosted.

We will create two rules – one for detecting it is google and one for negating – not Google GSuite.

Once we have that, we shall update decision flow step for rule set. Set our rule set in the step, save and test&release.

7. Testing, Endpoint creation and deployment

Now we can see whether it detects properly. Ideally wsj.com should be detected as “is google”, anything else will be no.

If our testing works, we can set up endpoint. You should create your endpoint on instance physically as close your servers as possible. If you are in Europe, use European, if in Asia, use Asian. Different region can add several hundred milliseconds to response.

Once you have the endpoint ready, go back to releases. Select last release that was working for you. Test it out again (just to make sure). If everything works, at the bottom of the page, select your endpoint and click deploy. Once info message appears that it was deployed, you can start sending requests to the api endpoint and it will contain the decision flow you have just tested.

8. Test out your endpoint using postman

Copy the JSON from testing, copy the url for endpoint, fire up Postman and get running.

In postman, select that you want to send using method POST. Paste url of the endpoint into request url. Click on body, select Raw and then further right click on text and select JSON. Paste the JSON with email below and hit SEND.

 

If everything goes right, you should be receiving the same response as when testing in the portal.

9. Integrate into your system

If you have everything running right, integrate the endpoint into your system and enjoy being able to update rules and deploy quickly changes to endpoint. Endpoint stays, the rules in the decision flow can change as quickly as you want them to.

Happy decisioning!