When DMARC Passes and the Email Is Still a Scam: The Gmail API Spoof

In late 2025, we examined the headers of a phishing email that bypassed several internal email security controls at a client. The From address was a @google.com address. The subject line was urgent, requesting a review of Q1 ad performance, tailored to the victim's industry. There were no links, no payloads, no attachments — the message was structured as a conversational hook, expecting a reply.

The headers told the story. The message had been sent through the Gmail API — specifically, gmailapi.google.com with HTTPREST — by what appeared to be a Google Cloud project identified by its numeric project ID. DMARC for google.com was pass. DKIM was signed by Google. SPF resolved against Google's infrastructure. The message was, in the technical sense, fully authenticated. It was also, in every other sense, a scam.

This post is about what email authentication actually validates, what it doesn't, and why the next layer of email security has to live above the protocol level.

What Authentication Actually Validates

The three pillars of email authentication answer specific, narrow questions:

SPF validates that the SMTP envelope sender's domain has authorized the sending IP. It says nothing about who actually controls the account that sent the message, or whether the message content is fraudulent.

DKIM validates that the message was signed by a key associated with a domain, and that the message body hasn't been modified since signing. It says nothing about whether the entity that controls the signing key is the entity the recipient thinks is sending.

DMARC validates that the visible From address aligns with either the SPF or DKIM authenticated domain. It says nothing about whether the visible From address belongs to a person or entity the recipient should trust.

For a normal corporate email — say, an invoice from your vendor — these checks combine to provide meaningful guarantees. The vendor controls their domain's DNS, their DKIM keys, and their sending infrastructure. If the message passes DMARC, the recipient can be reasonably confident it came from the vendor.

But the Gmail API scam works because Google's infrastructure operates differently. Google controls the google.com domain. Google controls the DKIM keys for google.com. Google's SPF authorizes all of Google's sending infrastructure. And the Gmail API, as a feature, allows any authenticated Google Cloud user to send mail through Google's infrastructure with @google.com From addresses — under specific configurations. The authentication layer correctly validated that the message came from Google's infrastructure. The fact that "Google's infrastructure" includes mail sent by a Google Cloud customer who is not Google was not in scope for the authentication layer to evaluate.

The Access Control Problem

Trevor Hatfield, CEO at SendX and SendPost, summarized this on our LinkedIn post:

"When authentication protocols pass and the email is still fraudulent, it undermines the trust model the entire industry relies on. SPF, DKIM, DMARC are supposed to be the verification layer. If they can be satisfied by a bad actor with API access, the gap isn't in the protocol. It's in access controls upstream."

The framing is exactly right. The protocols did what they were designed to do. The vulnerability is in the platform's access control: who, with what authentication, can send mail under whose domain.

For most mail platforms, this is well-controlled. A Mailchimp customer cannot send mail under mailchimp.com — they can only send mail under domains they've individually verified. An ESP-issued API key gives you sending privileges only for the domains your account has authorized. The infrastructure layer (authentication) and the authorization layer (which sender can send under which domain) are designed to converge on the same answer.

The Gmail API scam exploited a gap in this convergence. Google authenticated the message correctly at the protocol level. Google also, at the platform level, permitted a Cloud user to construct From addresses that the user did not legitimately represent. The two layers disagreed about who the user was authorized to claim to be. The receiver — and DMARC — saw only the protocol layer.

Why This Pattern Is Spreading

The Gmail API case is one instance of a broader pattern: as ESPs, infrastructure providers, and platform vendors expose programmatic interfaces to send mail, the gap between "the protocol authenticated this sender" and "the platform authorized this sender to claim this identity" widens.

A few related patterns we've documented:

ESP IP range spoofing. When a customer's SPF authorizes an ESP's entire IP range (e.g., include:servers.mcsv.net for Mailchimp), a compromise of any IP in that range gives the attacker the ability to send SPF-passing mail under the customer's domain. We covered this in our writeup of the Mailchimp SPF include pattern.

API-driven mail platforms with weak domain verification. Some platforms allow customers to send mail with From addresses they haven't fully verified. The platform's DKIM signature is valid; the platform's SPF authorizes its own sending IPs; the From address is whatever the customer typed into the API call. DMARC passes because the customer's apparent domain happens to be aligned with the platform's signing domain — or, more often, because the platform sends from its own domain (e.g., via mandrillapp.com) and the customer's From address rides along in the visible header.

Compromised legitimate accounts. A vendor's email account is taken over by phishing. The attacker sends spoofed invoices from the vendor's actual mail account. Every authentication check passes. The compromise is at the human layer, not the protocol layer.

Internal API misuse. A SaaS company exposes a "send notification" API to its customers, configured to use the SaaS company's verified sending domain. A customer abuses the API to send mail that recipients believe came from the SaaS company itself. The authentication is correct. The platform's access control didn't anticipate the abuse pattern.

The common thread: authentication tells you which infrastructure sent the message. It does not tell you whether the sender had legitimate authorization to claim the identity in the From address. That layer of validation has to come from somewhere else.

What Receivers Are Starting to Do

The practical response from major mailbox providers has been to layer additional signals on top of DMARC, using behavioral and machine learning models that don't depend solely on protocol authentication. The signals include:

• Sender reputation at the sending address level, not just the domain level
• Behavioral patterns: does this sender typically send to this recipient? Is the timing consistent with prior contact?
• Content patterns: does the message structure match legitimate mail from the same domain?
• Cross-correlation with reported phishing across the receiver's entire user base
• Anomaly detection for new From addresses on previously-trusted domains

These are the systems that catch authenticated-but-fraudulent mail when DMARC alone doesn't. They're proprietary to each receiver, opaque to senders, and increasingly important — but they're not protocol-level defenses, and senders can't directly configure them.

The implication for senders is that "I'm at p=reject, DMARC is passing, I'm done" was always an incomplete posture. Authentication is necessary but not sufficient. The composition of identity (who can send under what address from your infrastructure) and the content of mail (does it look like legitimate communication) are the additional layers.

What Senders Should Do

If you operate a mail platform that lets customers send under their own domains, the access control discipline is straightforward:

1. Verify domain ownership before allowing sending. Require DNS-based verification (TXT record proving control) before the platform accepts the customer's domain for sending. Don't accept "I claim to own this domain" as the verification step.

2. Per-customer DKIM keys. Each customer gets their own DKIM signing key, scoped to their verified domain. A compromise of one customer's account cannot be used to sign mail for another customer.

3. Per-customer SPF scope. Where possible, use SPF macros to scope each customer's authorized IPs to only the IPs the platform uses for that customer's mail. Avoid the pattern where a customer authorizes the platform's entire IP range.

4. Reject mismatched From addresses. If a customer sends through your API with a From address that doesn't match their verified domain, reject the message. Don't sign and forward it.

5. Monitor for abuse patterns. A customer suddenly sending high volume to addresses they've never sent to before, especially with content patterns that match known phishing templates, is a signal worth catching at the platform level. Don't rely on receivers to be the only line of defense.

If you operate a domain that is at high impersonation risk — the brand impersonation case — the additional layers are:

1. BIMI to give recipients a visual signal that mail genuinely came from your domain (where the supporting clients display it).
2. Monitor for lookalike domains. The attacker who can't pass DMARC for your real domain will register your-cumpany.com and run a campaign from there. Lookalike domain monitoring catches this category.
3. Customer education. What your legitimate mail looks like, what it doesn't ask for, where to verify if uncertain. The user is the last layer of defense and should be equipped accordingly.

The Trust Question

DKIM, SPF, and DMARC were designed for an email ecosystem where the protocol authentication and the platform authorization were operationally aligned — where a domain owner's sending infrastructure was operated by the domain owner or by tightly-controlled vendors. That assumption holds for most corporate email today, which is why DMARC works as well as it does. It does not hold for highly-multitenant API-driven mail infrastructure, where the platform owner's authentication is technically correct and the platform's authorization decisions are the actual security boundary.

This isn't a flaw in the protocols. The protocols are doing what they were built to do. The flaw is in treating them as the complete answer. They're not. They're a strong foundation, on top of which platforms, receivers, and senders all have additional work to do.

For the foreseeable future, that work has to be done by humans paying attention to the gap between "this message authenticates" and "this message represents what it claims to represent." The Gmail API scam worked because the gap was wide enough for an attacker to walk through. Closing similar gaps across the rest of the email ecosystem is the next decade of email security work.

---

Written by the team at SH Consulting. If you operate a mail platform where customers send under their own domains, and you want to audit whether your authentication and authorization layers actually converge, book a call.