Google SMTP Relay Abused to Deliver Phishing Emails


Phishing actors abuse Google’s SMTP relay service to bypass email security products and successfully deliver malicious emails to targeted users. According to a report from email security firm Avanan, there has been a sudden uptick in threat actors abusing Google’s SMTP relay service starting in April 2022. The company has detected at least 30,000 emails in the first two weeks of April being distributed through this method.

You can also check AccuWebHosting’s anti-spam-email-protection for all of your requirements.

AccuWebHosting’s anti-spam-email-protection

Attack Details

Google offers an SMTP (Simple Mail Transfer Protocol) relay service that can be used by Gmail and Google Workspace users to route outgoing emails.

Businesses use this service for various reasons, ranging from not having to manage an external mail server to use it for marketing emails, so their mail server does not get added to a block list.

Avanan states that threat actors can utilize Google’s SMTP relay service to spoof other Gmail tenants without being detected, as long as those domains do not have a DMARC policy configured with the ‘reject’ directive.

Also Read: How DKIM SPF & DMARC Work to Prevent Email Spoofing and Phishing

Domain-based Message Authentication, Reporting & Conformance, or DMARC, is an email authentication protocol that allows domain owners to specify what should happen if an email is spoofing their domain. To do this, domain owners create a special DMARC DNS record that includes a directive telling a mail server what to do. These directives are ‘none’ (do nothing with the spoofed email), ‘quarantine’ (place email in the spam folder), or ‘reject’ (do not accept email at all).

The new phishing campaigns use the ‘’ SMTP server, which is a trusted server and is thus commonly placed on allow lists by email gateways and spam filtering services.

For example, the following email, spotted by Avanan, appears as if it comes from, but it’s in reality from and passed through Google’s relay service.

Malicious email impersonating Trello (Avanan)

As previously stated, these attacks only work if the impersonated entity has set its DMARC policy to “none,” which is not as uncommon as you may think. For example,,,,,, and have DMARC policies set to ‘none.’

Setting strict DMARC policies is a recommended security practice as it helps prevent threat actors from spoofing domains.

In Trello’s case, DMARC policy has been disabled due to using other security tools, making the impersonation possible.

Email Example #1

The key is using as the SMTP service. This email is sent through one domain, but is delivered into the inbox from

Here are the details:

Received: from ([]) by


From: [email protected] <[email protected]>

Email Example #2

This email is sent from, but the text has nothing to do with Trello, instead inviting the user to click on a link that’s malicious. The actual domain was


Hackers are using the SMTP Relay Service of Gmail to spoof domains and send phishing emails into the [email protected] wouldn’t want to send their email from that domain. They would want the legitimacy of a major brand. So, using this service, they instead send their email from, say, (assuming uses Gmail). Email scanners see that it’s coming from Gmail’s trusted relay service–and for good measure, often a trusted brand–and it sails right through to the inbox. One bad domain is able to send emails from another good domain. 

Also Read: Cooking Malicious Phishing Email Headers with CyberChef

Think about it this way: Company x sets up a Gmail Relay. They can use it to send emails from any other Gmail tenant. This ensures an SPF pass when the recipient runs a check. This ensures that the phishing email will reach the inbox, assuming DMARC=reject is not enabled. 

Companies–and individuals–use the SMTP Relay Service precisely because it’s trusted and its purpose is to ensure an email doesn’t end up in the junk folder. And depending on the Google plan, they can send a maximum of 4,600,000 million emails in a 24-hour span (although that would only truly apply to large companies). 

This works only if the impersonated brand has its DMARC policy set to none. That’s because Google, along with other systems, will point out an explicit mismatch on the email from headers when there is one. (For example, if sends out a message from, there will be an indicator of such discrepancy for downstream email systems to see.) Most companies will have a DMARC=reject policy, as Netflix does:

(MX Records, shown above, are public knowledge and can be accessed via sites like MXToolbox.) Following strong DMARC policies like the one seen above is essential and will help protect from these attacks. For example, we haven’t seen any spoofs of Netflix while researching this attack, in large part due to their DMARC=reject setup.

Trello, spoofed above, does not have its DMARC reject policy enabled. 

One of the reasons they may have disabled DMARC is because they have Proofpoint, a Secure Email Gateway, installed.

All the attacker had to do was send emails from Gmail’s IP address, and SPF would be passed. 

It’s important to note that any SMTP relay could be vulnerable to this attack. There are a number of SMTP relay services out there. 

Avanan has seen a massive increase in these attacks. Through two weeks of April, we’ve seen over 27,000 of these emails. 

Avanan notified Google of how hackers were using this relay on April 23rd, 2022. 

Also Read: Email Header Analysis – Use Cases Including SPF, DKIM & DMARC

Best Practices: Guidance and Recommendations

To guard against these attacks, security professionals can do the following:

  • Check sender address before interacting with any email 
  • Set DMARC policy to reject
  • Always hover over any link to see the destination URL before clicking on it
  • Ensure your email authentication standards are up to par, utilizing best practices from the Messaging, Malware and Mobile Anti-Abuse Working Group, found here


Previous articleMicrosoft Cloud App Security Anomaly Detection Policies
Next articleTime to re-evaluate your 2FA setup on Microsoft networks
Balaganesh is a Incident Responder. Certified Ethical Hacker, Penetration Tester, Security blogger, Founder & Author of Soc Investigation.


Please enter your comment!
Please enter your name here