Ever since we launched the ability to hook your account up to an external SMTP provider and essentially “break” Gmail’s sending limits, one of the questions we get asked most is:

“If I have a gmail.com email address, won’t my emails go to Spam if my emails ‘from’ gmail.com are sent via SendGrid, Mailgun, Amazon SES, or any server that’s not Google’s?”

It’s a great question and a legitimate concern! Let’s address why it’s not an issue and even offer proof that Google says it’s okay — for now anyway.

Let’s check the SPF record

To understand why this is acceptable, we must understand how SPF, DKIM, and DMARC work. Gmail.com’s SPF record is this:

v=spf1 redirect=_spf.google.com

Since this record is asking us to look at another record, the SPF record for _spf.google.com is this:

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

What this means is that emails with a MAIL-FROM of gmail.com must have an IP that’s contained in one of the designators above. Remember, there’s a difference between the MAIL-FROM address and the actual From address seen by receivers of email. SPF only checks the MAIL-FROM address that’s seen by the server, not by the recipient.

Now let’s say you’re sending through SendGrid or Amazon SES. By default, when you send through either one of these services, even though your “from” address is [email protected], the MAIL-FROM is [email protected] or [email protected]. Because the MAIL-FROM isn’t gmail.com, you’re still in compliance.

So for SPF, you’re compliant.

Okay, what about DKIM?

When you send an email from your gmail.com account inside Gmail to a friend, the DKIM signature on your email looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:from:date:message-id:subject:to;
        bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=;
        b=f8vKOrTL8SFHtNe4G69kvXGs6xfx2D4whxS8vl0j6rslGIK9INVVCGEDRb4o6fFM6n
         BmpkNaAECGCvvf1imZfVjlqaFpM2abkVum+PwKkCugt8KpKEPDGmVuMst8B7gaMvBxvo
         BIygX7oIRTKRtraG/Esug0cxPTY8wDDvjXNa9Z/zLGcO7n57V7IzE2hzguYHL4xeLv7q
         WsI0NDFDGa23NVlSfX+AdnyCLbSa3tQfhDjafRFglhTL0dAX1x0Nou4QIjN2tD8IS8GQ
         YhIlHJzHT4h5bNEcxi2n/JxvjTmmeyw2eGWCy3qvjKey+QfNtxz8e2NFDxaH6RbUCxYB
         fDjw==

The email is signed by the domain gmail.com, which is the d=gmail.com part of this messy looking text. Technically, what’s happening here is that Gmail is taking the email you’ve typed, and hashing it using a private key for Gmail that only Google knows. This private key is proprietary, hidden, and kept under lock and key.

When you send an email from your gmail.com account using SendGrid or Amazon SES, each of those providers signs the email with their respective domain. SendGrid signs outbound emails with sendgrid.net, and Amazon SES signs outbound emails with amazonses.com. It’s worth mentioning that both SendGrid and Amazon SES allow you to brand the signing domain around your own domain if you wish; but out of the box, both providers will sign emails with their own domains so that emails are DKIM compliant right from the beginning.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sendgrid.net;
h=mime-version:subject:from:to:content-type;
s=smtpapi; bh=MLOxbqehWaMM2DEWhURrbRF13UbLZJkxWDLneKqUJVY=;
b=t5iyssLz1OFtFDZ0MRsju381iqwZi0j7vshv3SWscVhwmGw4GZP4o2+bzj6/gugGmkYq
huZ+af3+rqM0/i872nWmp2mOQsOrzwv49ZWb5Pg67x92sGghAHKXBLh7GfteN81qcX2K+3
O+B4Wl8G54VC53AP1YPoRhHDEduizjC+8=
Subject: Sending from gmail.com through SendGrid
From: Ajay Goel <[email protected]>
To: Ajay Goel <[email protected]>

This can be confusing, but providers signing with their own domains rather than gmail.com is allowed, because with pure DKIM alone, an email can be signed with any domain you want. Of course, it has to be a domain you control, but it doesn’t have to be a domain that the email is “from.” It’s counterintuitive, but it doesn’t have to be the domain in the MAIL-FROM line or the display From address. You can see that Gmail adds a header to the received email to indicate that DKIM has passed based on the signing using the sendgrid.net domain:

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=smtpapi header.b=t5iyssLz;
spf=pass (google.com: domain of [email protected] designates 167.89.100.13 as permitted sender) smtp.mailfrom="[email protected]";
dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com

So DKIM passes.

Now you might be thinking, “Well, if an email can be signed with any old domain, how does that make the email ‘authentic?'” The original point of DKIM wasn’t to prevent spam or even to determine what networks can send for what domain. The point of DKIM was to ensure that the contents of the email weren’t altered while in transit from the sender to the recipient. All it needed was access to the private signing key for some domain — any domain used in the d= part to sign the email.

Later, DMARC came along and provided enforcement of the domain in the DKIM signature by having to MATCH the domain in the Display From Address. But pure DKIM alone doesn’t require this.

If you have a sharp eye, you might notice that in the above example, it says dmarc=fail. Uh oh, that’s a problem, right? Actually, no! Read on …

Last but not least, let’s examine DMARC

The tricky part is passing DMARC. You know how I just said that with DKIM, you can sign your email with any domain you want … it doesn’t have to be any of the two “from” domains. A domain’s DMARC policy specifies whether those domains have to match up … it’s called “alignment.” A domain’s DMARC policy can specify whether the SPF domain has to match the display From domain, and whether the DKIM domain has to match the From domain. With DMARC, alignment can be “relaxed” or “strict,” and if not specified, “relaxed” is assumed. Now, “relaxed” still means that the domains have to match, but it allows a subdomain to match the root domain.

Without further ado, here is gmail.com’s DMARC record:

v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]

The relevant portion to examine here is the part that says: p=none.

What this means is, because there’s a DMARC record present, relaxed domain alignment is expected for either SPF or DKIM to pass DMARC. Now when you send through SendGrid or Amazon SES with their default non-branded-domain setups, the domain alignment will not pass for EITHER SPF or DKIM, DMARC will fail. BUT, because the record contains p=none, Google is instructing servers NOT to punish the email because of it.

So there you have it. You can send “from” your gmail.com account through a third-party provider like SendGrid and Amazon SES. SPF and DKIM will pass. DMARC will fail, but it won’t matter because gmail.com’s DMARC record says not to take any action for DMARC failures.

Okay, so then which SMTP services will let you send “from” your gmail.com account? We did an exhaustive technical review recently, and here are the SMTP services that will allow you to send from your Gmail account: SendGrid, Mailgun, Mailjet, Sendinblue, SMTP.com, SMTP2Go, and Amazon SES. Two providers, SocketLabs and Mandrill (part of MailChimp), will NOT let you do this.

But will you hit the Inbox?

If you’re an email marketer or cold emailer, that’s all that really matters. My tests show that generally, you will. Google controls about half the world’s email Inboxes, and it’s the platform on which I’ve tested deliverability the most. In a couple of tests I’ve just run, emails sent from my gmail.com account hit the Inbox of my G Suite account.

Note that the email is sent “via sendgrid.net.” That’s to be expected. There are conditions that result in the “via” tag next to the sender’s name, but that designation is harmless.

Whether Gmail places emails in the Inbox vs. Promotions vs. Spam folder is not a matter of passing a few simple checks, and it’s certainly not only a matter of whether the email originates from Gmail itself or an external server. Google uses a complex AI-based machine learning algorithm that analyzes millions of factors to make that decision.

Occasionally the recipient might also see this designation at the top of the message, but in our experience, even this designation doesn’t alter Inbox vs. Spam placement:

So what’s the conclusion, then?

Senders are often hampered by Gmail’s daily sending limits. However, in our experience, senders who are deploying wanted email to recipients can send from their gmail.com accounts through external SMTP servers, allowing them to send more email than they would otherwise be able to send through their Gmail account.

Ajay Goel

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