We’ve introduced a new enhancement to our popular auto follow-up feature which will send sequential follow-up emails in stages to people until they reply (or open, or click). Now you can set your auto follow-ups so that if you’re sending email to multiple people at a company or organization, if any one person at the organization replies, the follow-ups to everyone at that organization will stop. This option is useful if you’re cold emailing multiple people at an organization with the goal of getting just one of them to reply. If your goal is to get everyone at an organization to reply, you would not want to use this setting. This setting is OFF by default and needs to be turned ON if you wish.
This setting works by examining the domains of your recipients and stopping email to any domain that matches the domain of anyone that’s responded, with the exception of popular consumer domains.
For example, let’s say you’re cold emailing to pitch your corporate catering services, and your original email goes to 3 employees at Uber as well as 2 @yahoo.com addresses:
After your initial email, nobody responds. Your Stage 1 auto follow-up then goes out 3 days later, and jane@uber.com responds and ben@yahoo.com responds. Because jane@uber.com responded, the auto follow-ups to jack@uber.com and joe@uber.com will now also stop, if this setting is on. However, brian@yahoo.com will still continue to receive auto follow-ups because yahoo.com is a consumer domain, so the fact that ben@yahoo.com responded doesn’t affect brian@yahoo.com.
Because this setting works based on domain matching, if, for example, you had sam@uber.net on your list, sam@uber.net would continue receiving the auto follow-ups because uber.net is a different domain than uber.com. FYI, this is just an example, and it turns out that uber.net isn’t even owned by the real Uber.
When you activate this setting, it applies to your entire account, meaning it will apply to all campaigns with “no reply” auto follow-ups sent from your account. You can’t set this on a per-campaign basis. Also, it does not apply to auto follow-ups that are sent based on opens, clicks, or to ALL — it only applies to auto follow-ups that are based on replies.
To toggle this setting on and off:
Click Compose to launch a new window.
Set the To field to domainmatch@gmass.co.
Set the Subject to the word on or off.
Leave the Message blank.
Hit the GMass button. Do not hit the Send button.
I’ve modified our “recurring campaigns” feature so that you can have your spreadsheet checked hourly, in addition to daily, for new addresses, which would trigger a single email or a sequence of emails with auto follow-ups.
You’ve always had the option to set a daily recurring campaign, based on new addresses in your Google Sheets spreadsheet, but now you have the option to set an hourly recurring campaign.
Now in addition to “daily”, you set a campaign to repeat hourly.
What can you do with an hourly recurring campaign?
I’m using the new hourly recurring campaign feature to ask free GMass users to subscribe to a paid account. In GMass, if you’re a free user and you attempt to send more than 50 emails, you get a popup asking you to subscribe. Each time that happens, your account is logged to a table in our database. Every few minutes, the data from that table is copied over to a Google Sheet, via an internal tool we wrote. Then, every hour, GMass checks that spreadsheet for new addresses, and sends an email asking the user to subscribe.
What else can you use it for?
Continuous lead flow: If you update your spreadsheet throughout the day with new leads, and don’t want to wait for the next day before your next batch of emails are sent, you can set up an hourly recurring campaign which will send to any new addresses every hour.
After-purchase coupon offer: If you have everyone that has purchased from your website synced into a spreadsheet, you can send them a coupon for their next purchase. Sending these emails about an hour after the purchase can be advantageous, because if you send the coupon immediately after purchase, the shopper will wish they could have applied it to the current purchase. Delaying the email by an hour or so, however, will make the coupon more attractive.
Asking for reviews: Whether you’re a restaurant with a Yelp review page, a mobile app company, or even a Chrome extension developer, there’s likely a place online where users can post reviews. Setting up an hourly recurring email asking for a review after a user has taken some action (downloading your app, taking an important step in your software onboarding process), can greatly increase the chances of a user writing a positive review. Ask them when you’re product is top of mind and when they’ve just had a pleasant experience with it, but don’t ask them immediately after. An hour or so may be the perfect delay.
If you’ve noticed that in the last month you’re getting more clicks than you’re used to, it might be because of Yahoo!’s Slurp Search Bot. In the last month, we’ve noticed a substantial increase in the number of clicks for email campaigns that have click-tracking turned on, and most of those extra clicks are being generated by the Yahoo! Slurp bot. Specifically, you may have noticed the User Agent:
A sample click notification from GMass where the click came from the Yahoo! Slurp Bot.
Why is this happening?
Yahoo!’s Slurp search spider has been around for a while. We think that in the last few weeks, Yahoo! made a change such that the spider is now clicking the links in the email messages of all Yahoo! Mail users, where it previously did not auto click all the links within emails. So if you’re sending email campaigns to @yahoo.com users or any address hosted by Yahoo! Mail, or to an address that forwards to such an address, you may be getting false clicks from the Slurp spider.
What change did we make?
On August 14, 2017, we modified our click tracking handler to ignore clicks from the Slurp search spider, so you shouldn’t see any more clicks generated by the spider.
For a while, you’ve had the ability to transfer a GMass subscription from one account to another, but starting today, we’re enacting some rules around subscription transfers to prevent the abuse of a single subscription.
The process of transferring a subscription from one account to another was intended for the following scenarios:
You subscribed the wrong Gmail/G Suite account, and so instead of canceling the incorrect account and subscribing the correct account, which would cause you to incur an extra charge, you could simply transfer the subscription to the correct account.
If your Gmail or G Suite account became suspended or inaccessible, it was fair to let you transfer your subscription to another account without having to cancel and subscribe, since that would also incur an extra charge.
While the ability to transfer a subscription was intended to be a convenient way to recover from one of the mistakes described above, we’ve noticed some users using the transfer procedure to transfer a single subscription across many accounts, each time sending the maximum amount of emails possible from each account, in order to avoid having a subscription for each active account.
This is an unfair use of a single subscription, so starting today, we’re placing the following limits on subscription transfers:
Once a subscription has been transferred away from a particular Gmail or G Suite account, it cannot be transferred back to that same account.
A single subscription can only be transferred a maximum of five (5) times.
The GMass extension now works with both Gmail and Inbox.
How do you get it?
You don’t have to do anything to get GMass to work inside Inbox, if you already have the GMass Chrome extension installed in your browser. Just fire up Inbox and the GMass buttons should appear. If they do not appear, your Chrome browser may not have the latest GMass extension, version 4.0.0. If that’s the case, go to the URL chrome://extensions and click the button at the top to “Update extensions now”. Then confirm that your version of GMass is 4.0.0.
Newbie?
If you’re a Google Inbox newbie, these resources may help:
If your account is configured for it, go to Google Inbox now.
In Gmail you have the ability to send not only from your @gmail.com or G Suite email address, but also any “alias” From Addresses that you configure in your Gmail Settings as well under “Send mail as”. If you then send a mail merge campaign “from” one of these alias addresses, it could impact your email deliverability because your emails may not get sent through Gmail’s high deliverability email servers.
How to add a new “From” address to your Gmail account.
It used to be that you could configure any additional address that you own to use as a From Address in your Gmail account and have those emails send through Gmail’s servers. A few years ago, Gmail changed that policy and now forces you to enter the SMTP server credentials for any new From Address you want to set up that isn’t hosted on Gmail or G Suite.
For example, I own the domain silicomm.com and one of my old email address is ajay.goel@silicomm.com. silicomm.com is NOT a G Suite domain. I actually run my own mail server for silicomm.com. My personal email account is ajaygoel999@gmail.com, so if I want the ability to send “from” ajay.goel@silicomm.com inside my ajaygoel999@gmail.com account, then I’ll be forced to enter the SMTP server settings to send mail from ajay.goel@silicomm.com.
When and why did Gmail make this change?
Gmail made this change around August of 2014. With the increase in usage of SPF and DKIM, it no longer made sense for Gmail to allow you to send emails from a domain that Gmail itself has no control over, through Gmail servers. Gmail was opening itself up to abuse by allowing people to send any emails they wanted from any domain they wanted through their email system.
On the other hand, you might be lucky and grandfathered in if you set up your Alias From Addressbefore Google made this change. I have the Gmail account, ajay.silicomm@gmail.com, and I set up ajay.goel@silicomm.com as an Alias From Address way back in 2012, so I was able to do so and still use Gmail’s servers. I haven’t touched the settings since…if I want to make any changes, I’ll be forced to enter an SMTP server.
Adding a new From Address to your G Suite account
If you run into a “permissions” error when trying to add a From Address to your G Suite account, you need to have your G Suite Admin make a change to your permissions to allow you to do so. By default, this permission is OFF.
In order to set up additional non-G Suite From Addresses in a G Suite account, your G Suite admin must set permissions to do so.
When does Gmail ask for the SMTP server?
Whether or not Gmail asks you to input an SMTP server when you add a new “Send mail as” From Address depends on the type of Gmail account you’re logged into and the type of From Address you are adding.
Gmail
G Suite
External Address
SMTP Server Required
SMTP Server Required
Gmail Address
No
SMTP Server Required
G Suite Address of Same Domain
N/A
No
G Suite Address of Different Domain
SMTP Server Required
SMTP Server Required
Regular Gmail
If you are logged into a regular Gmail account, meaning your account ends in @gmail.com or @googlemail.com:
Adding a non G Suite address, like ajay.goel@silicomm.com will force you to enter SMTP server credentials.
Adding a G Suite address, like ajay@wordzen.com will force you to enter SMTP server credentials.
Adding another Gmail address, like briansmith8477@gmail.com (Brian Smith is my alter ego), does not require you to input SMTP server credentials.
G Suite
If you are logged into a G Suite account, meaning your account ends in your organization’s domain and uses Gmail:
Similar to when you’re logged into a G Suite account, if you add a non G Suite address, like ajay.goel@silicomm.com, you will be forced to enter SMTP server credentials.
If you add a G Suite address that belongs to the same G Suite domain as the account you’re logged into, you will NOT need to enter SMTP server credentials. For example, if I’m logged into ajay@wordzen.com, which is a G Suite account, and I add ag@wordzen.com as an alias From Address, I will not need to specify an SMTP server.
If you add a G Suite address that does NOT belong to the same G Suite domain, then you will be forced to enter SMTP server credentials. For example, if I’m logged into ajay@wordzen.com, which is a G Suite account, and I wish to add rich@beamboard.com, which is another G Suite account, I will be forced to enter SMTP server credentials.
If you add a regular Gmail account as a “Send mail as” address, you’ll be asked to enter SMTP server credentials. Be careful here though — if you specify a third party SMTP server, you’ll likely fail SPF checks since you can’t control the SPF record for gmail.com to allow your third party SMTP server to send on behalf of gmail.com.
The skinny on deliverability
Let’s say that I now have ajay.goel@silicomm.com set up to send via ajaygoel999@gmail.com. The SMTP server for silicomm.com is mail.silicomm.com, and I enter this as the credentials.
I’m setting up a From Address of ajay.goel@silicomm.com and entering the SMTP server info for the silicomm.com domain.
If I now send a Gmail mail merge campaign from ajay.goel@silicomm.com, those emails are routed through mail.silicomm.com and not Gmail’s high deliverability servers. My mail merge may work just fine, but I may lose some deliverability benefit. One of the advantages to using GMass over a traditional email marketing service like MailChimp or Constant Contact is the extremely high deliverability advantage that Gmail’s own servers provide over a traditional ESP’s servers, which are known to be bulk mailing servers.
The third party SMTP server may not be configured to handle rapid routing of many emails simultaneously. Some SMTP servers allow a single user to only send a couple hundred emails/day. In that case, you will be limited in the number of emails you can send not by Gmail’s own limits, but by the third party SMTP server’s limits. If you start to get bounces that are not generated by Google that indicate a rate-limit or delivery problem, then it’s the third party SMTP server is restricting you.
Here is an example of a bounce generated by a third party SMTP server: server173.web-hosting.com
An example of a bounce generated by a third party SMTP server, because of a quota issue.
A hack that allows you to still use smtp.gmail.com as your third party SMTP server
If you want to route your emails through Gmail’s servers even when sending “from” an external email address, you can use Gmail’s SMTP relay server, smtp.gmail.com. Whether you can use smtp.gmail.com and what credentials you use to authenticate into smtp.gmail.com depend on your setup.
G Suite
You can authenticate into smtp.gmail.com with any G Suite account just by using the G Suite email account and password as the credentials. You must turn on “Allow less secured apps” for this to work.
You must turn on “Allow less secure apps” for your G Suite account in order to authenticate into smtp.gmail.com with your G Suite email account and password.
If you don’t want to allow “less secure apps”, then you can turn on 2-step Verification and create a separate App password as described in the instructions below for Gmail. This will also work for a G Suite account.
Unlike with G Suite where the regular account email and password will authenticate into smtp.gmail.com if you turn on “allow less secure apps”, for regular Gmail accounts, you need to set up an app-specific password to authenticate into smtp.gmail.com. I consider this a loophole in Gmail’s policies, because I don’t believe this is what Google intended, but nevertheless it is possible to use smtp.gmail.com as the SMTP server for an external address inside a Gmail account. Someone else, far smarter than I, discovered this technique and wrote about it.
Example: Authenticating using a Gmail account from a G Suite account
Given that you can authenticate into smtp.gmail.com using a Gmail or a G Suite account, you can also now route your email in a complex manner via multiple accounts. For example, in my G Suite account ajay@wordzen.com, I can set up an Alias From Address of ajay.goel@silicomm.com (which is not a G Suite account) by authenticating into smtp.gmail.com with my regular Gmail account, ajaygoel999@gmail.com. Confused yet?
From my ajay@wordzen.com G Suite account, I want to add ajay.goel@silicomm.com as a From Address.
Note that I’m adding ajay.goel@silicomm.com as a From Address from my ajay@wordzen.com G Suite account. But instead of using my ajay@wordzen.com login for smtp.gmail.com, I’ll use my personal ajaygoel999@gmail.com account instead.
I’m authenticating into smtp.gmail.com with my ajaygoel999@gmail.com account. The password however is not the password for ajaygoel999, but a separate App password I created using this technique.
After Gmail tests the SMTP connection and sends me a verification code, I’m all set to send from ajay.goel@silicomm.com from my ajay@wordzen.com account.
I’m now composing a mail merge using the ajay.goel@silicomm.com From Address.
Given that ajay.goel@silicomm.com is set to authenticate into the SMTP server with ajaygoel999@gmail.com account, which of my Gmail accounts will the email be sent from? ajay@wordzen.com which is where I’ve set this up, or ajaygoel999@gmail.com, which is the account the SMTP server will use?
It turns out that the emails will show up in the Sent Mail for BOTH ajay@wordzen.com and ajaygoel999@gmail.com.
The sent emails show up in the Sent Mail folder for ajay@wordzen.com.The emails ALSO show up in the Sent Mail folder for ajaygoel999@gmail.com.
What account actually sent the 3 emails though? As expected, the ajaygoel999@gmail.com account actually sent the emails that are “From” ajay.goel@silicomm.com, since it was the ajaygoel999 account that authenticated into the SMTP server. How do we know? A look at the headers of one of the received emails clues us in.
These are the headers for the email received by briansmith8477@gmail.com, and they show that the email was sent “from” ajay.goel@silicomm.com via the ajaygoel999@gmail.com account.
If you are sending via a third party SMTP server, must you adhere to G Suite’s/Gmail’s sending limits?
If you have configured a third party SMTP server (not smtp.gmail.com) to handle email for your new From Address, you might think you can now send as much email as you want. After all, why would Google care how much email you’re sending if it’s not going through their servers? It turns out that some sending restrictions are in place. I plan to do some further testing in our lab in the near future to determine just what the sending limits are when sending through a third party SMTP server. This will be the subject of a future blog post.
If you are using smtp-relay.gmail.com or smtp.gmail.com as your SMTP server, then the limits get even more confusing. Remember, the two SMTP relays aren’t meant to be used from inside Gmail. They are meant to be used by outside devices like printers and scanners and external email systems that need to relay email through your Gmail accounts.
Can you use a transactional email provider like Sendgrid or Mandrill as your SMTP server?
Yes. If you have an account at a transactional email service provider like Sendgrid, Mandrill, Mailgun, JangoSMTP, or any other email service provider, you can use the SMTP server credentials they provide you and enter it in the Gmail settings. Your emails sent “from” the new address will now be sent via the transactional email service provider instead of Gmail’s servers. You will likely suffer at least a tiny deliverability disadvantage though, since now your emails are being sent via an external service rather than Google’s own servers.
I have specified Sendgrid’s SMTP server to route my emails “from” ajay.goel@silicomm.com
SPF/DKIM considerations
If you’re sending via any third party SMTP server, ensure that the SPF record for you sending domain gives permissions to the third party SMTP server to send on behalf of your domain.
How the “Treat as an alias” setting matters for your mail merges
When you set up any new From Address, whether you check the Treat as an alias has no impact on how your email will look to your recipient. As the official Google document on “Treat as an alias” explains, the differences between checking this box or not only apply when you send an email to, or receive an email from, the new “Send as” address that you’re setting up. If you’re sending a Gmail mail merge campaign to 100 people, to them your email will look the same regardless of whether you have set the From to be treated as an alias or not.
Best practices
If you’re going to send mail merge campaigns from your Gmail or G Suite account, I recommend that you do it in the most direct way possible. Meaning, if you have a G Suite account for your own domain, and you want to send your emails “from” this email address, then log in to that account to send the mail merge, as opposed to using an @gmail.com account with the G Suite address set up as an Alias From Address.
If you want to send “from” an external address that is neither a Gmail nor a G Suite address, then you’ll be forced to specify an SMTP server. Unless you have an SMTP server configured to handle your mailings and deliver them, you should use smtp.gmail.com, because that guarantees high deliverability because it’s a Gmail server.
The bottom line
If you’re sending from a “From” address that is NOT a Google-hosted address, you will be asked to specify a third party SMTP server to relay emails through. You can use smtp.gmail.com as that third party SMTP server if you wish, or you can use an external SMTP server that you manage or one from a commercial service like Sendgrid or Mandrill.
Make sure that third party SMTP server can handle mass email campaigns, and make sure you configure the SPF record of your domain to grant permission to that server to send on behalf of your domain.
There are a lot of outdated articles on the web saying you can still send via Gmail, but many of them no longer apply.
