Recently, two email industry colleagues independently reported something odd to me. Each composed an email in Gmail, sent it, and it landed in the recipient’s Inbox. Each then sent the exact same email using the Gmail API, only to find that the email was going to the recipient’s Spam folder. They swore up and down that everything from the Subject to the individual MIME parts were equivalent in both scenarios. How then, would sending directly from Gmail cause one deliverability outcome while sending from the Gmail API cause another?

First, let me explain what the Gmail API is. It’s a programmatic way of sending an email via your Gmail account. My tool, GMass, and any of our competitors like Mailshake, Lemlist, SalesHandy, Woodpecker.io, and others, all send email via the Gmail API.

Additionally, even we have had users report that sometimes, sending an email via GMass lands in the Spam folder, but sending it directly in Gmail (using Gmail’s normal blue “Send” button) results in Inbox placement.

Could it be that Gmail treats emails sent via its API differently, or with a lower priority, than emails sent directly inside the Gmail interface?

I’ll do a deep dive and compare the various attributes of emails sent by Gmail directly versus a third party app that sends via the Gmail API. We’ll examine:

• The sending IP address
• Differences in headers
• Differences in the formatting of the MIME parts
• The Inbox vs. Spam placement of the emails

It’s worth noting that we’ve previously recommended that our users test this themselves when trying to determine why an email is going to Spam. Here, we’ll do a deeper drive into what we’ve already recommended, which is isolating the differences in the sent email based on the method of sending it.

How I’ll test this

I’ll use our own Email Analyzer tool, which is a free tool that shows the sending IP of an email, along with all headers and raw MIME parts, for examination. I’ll also use just Gmail to test what folder emails land in, simply because a large portion of the world’s email is sent and received by Gmail. Gmail is the #1 platform used by cold emailers as well, and cold emailers are sending primarily to other Gmail/G Suite addresses. That shows just how powerful Gmail is in the email ecosystem.

Sending directly from Gmail

I’m sending this email with the Gmail blue Send button.

Here’s the result:

The email is sent from IP address 209.85.210.179. It’s

Sending the same email from the API via GMass

This time I’ll send the exact same email using the GMass button. Also, I’ll turn open and click tracking OFF. That will make it so that GMass doesn’t alter any of the content in the email. Theoretically, the email should now be sent in the exact same manner as using the normal Gmail Send button.

Here’s the result:

The email is sent from IP address 209.85.215.169. Just like with the Gmail Send button, it’s DKIM-signed, it passes SPF, it includes a plain text and an HTML MIME part. Just like before, the HTML MIME part is encoded with quoted-printable.

So far there are two observable differences:

1. The sending IP is different.
2. The emails sent with the API have an additional “Received” header line:
   

The header clearly identifies the Gmail API as the sender of the email, versus the Gmail interface. Could that be the trigger that results in different deliverability?

Analyzing the significance of gmailapi.google.com

The presence of this domain only in emails sent via the API could make a deliverability difference. It would be odd, however, if a Google-owned domain made a difference in email deliverability with emails sent FROM and TO Google email addresses, but stranger things have happened. Still, it’s worth running this domain through a reputation check. My favorite domain analyzer is VirusTotal, and they report no issues with gmailapi.google.com.

Of course, VirusTotal scan only searches publicly available domain blacklists, and as I’ve pointed out in my guide to domain blacklists, a number of companies use their own internal domain blacklists as well. Could Google have added gmailapi.google.com to its own internal domain blacklist?

Statistical significance of IP addresses

Is the sending IP always different when using the API, or is an IP address being chosen at random any time I send an email, regardless of whether it’s from the interface or the API? To find out, I’ll send a few more test emails with each method, and see if the sending IP address is consistent by the method of sending.

A second email sent directly from Gmail uses the IP 209.85.210.180, which is still part of the same 209.85.210.0/32 block. A third email uses IP 209.85.210.181.

A second email sent via the Gmail API uses the IP 209.85.210.172. A third email uses IP 209.85.210.169.

A fourth email sent directly from the UI, using Firefox, and a different Google account, sent the email from IP 209.85.218.53. Using that same Google account, sending via the API, had the email sent from IP 209.85.208.42.

Summary of IP addresses used:

Google owns a big bank of IP addresses and the 209.85 block is just one of these blocks. Given the sample data above, it’s difficult to identify any patterns in the sending IP addresses based on direct sending vs API sending. In both columns, the IPs are from similar CIDR blocks, with the only a few outliers. Of course, this is only based on a total of eight sent emails. A larger sample of data is available to me via our Inbox, Spam, Promotions email tester, but I haven’t yet analyzed that data.

Let’s test our competitors

Any third party app that sends email through the Gmail API goes through a verification process with Google to ensure the app meets certain standards. Could it be that that Gmail treats emails sent by various third party apps differently based on their adherence to the OAuth verification requirements? I think that’s unlikely, but in the interest of thoroughness, I’ll send a few test emails through some of our competitors, like Mailshake, Lemlist, SalesHandy, and Woodpecker.io. This is also a good exercise to make sure I’m not missing out on any secrets of email sending in order to optimize deliverability for my users. I want to look in detail at the emails sent by my competitors to see if they’re doing anything differently than we are.

Well, never mind. While I’m not shy about promoting my competitors when they’re doing something well, I spent five minutes with each of Lemlist, SalesHandy, and Woodpecker, and that wasn’t enough to figure out how to send a simple test email to one email address, so I gave up. If you’re curious, here’s what happened with each:

Mailshake: I tried to sign up and realized they require payment to do anything on the platform, which I wasn’t willing to do.

Lemlist: I got to the final review stage of my test campaign, and I can’t figure out why I’m getting a “cannot review” error. I don’t see a function to send a test email.

SalesHandy: I composed a campaign, tried to send a test email, and was told I had to upload a CSV first. Boo.

Woodpecker: I managed to create a campaign and run it with one prospect, then sent it to my test address @emailtest.io, but…

… it never arrived:

I’m sure all of these competitors are run by very nice folks and that these platforms are plenty capable of sending an actual test email, but I now appreciate my product even more — I find these tools complex. With GMass, you can install the extension and send a test email in about three seconds. I spent five minutes with each competitor and couldn’t figure it out. I’ll assume, for now, it’s because of my own product bias and not any fault of these likely good email tools.

I’ll come back another day and run these tests through our competitors, but I suspect that I’ll find the same patterns as when sending with GMass. The IP ranges will likely be similar, and any emails sent via these tools with Gmail will have that line referencing gmailapi.google.com.

So what can we conclude?

It’s difficult to draw any conclusions around deliverability with this limited sample set and limited testing. The clear difference in emails sent with the Gmail API versus sent directly with Gmail is that one header line referencing the domain gmailapi.google.com. Is that enough to lower email deliverability? Possibly.

Ajay Goel

Ajay is the founder of GMass and has been developing email sending software for 20 years.