Meeting invites kept landing in spam — it was “via google.com”

Building Google meeting notifications — straight into spam

I built a feature: after a user creates a Google meeting in the system, they receive a meeting notification from Google Calendar’s servers. Once it was done, the notifications did arrive — but they all sat in spam.

I tried a few workarounds: moving the notification from spam to the inbox, adding the sender as a contact. Nothing helped. When I created another meeting, the notification still went straight to spam.

The clue: “via google.com”

The subject looked like this:

“Updated invitation: Some Meeting - Wednesday, X Month 2026, 1:00 PM – 2:00 PM (GMT+8)”

And the sender line said:

[email protected] via google.com

The key was that “via google.com.” When the system creates a Google Calendar event and invites attendees as [email protected], the message is actually sent by Google Calendar’s servers (the path goes through google.com).

To the receiving Gmail account, the UI is basically saying: this message claims to be from yuwen-c.com, but Google sent it on its behalf — and the DNS for yuwen-c.com had never authorized Google to send mail for that domain.

Identity: [email protected]
        │ create meeting invite
        ▼
Google Calendar servers actually send it
        │ From looks like yuwen-c.com
        │ real path: google.com
        ▼
Receiving Gmail: check yuwen-c.com SPF
        │
        ├─ Google not authorized → looks forged → spam
        └─ Google included → matches → more likely inbox

Setting SPF: declaring who may send for your domain

I asked Gemini. The most effective fix was to set up SPF, DKIM, and DMARC. SPF, in short, is a list you publish in your domain’s DNS that says: “Only servers A, B, and C in the world are allowed to send mail on my behalf.”

Gemini also explained: without SPF, this “name doesn’t match the actual sender” pattern looks exactly like how scammers forge email, so Gmail’s filters treat it as spam. Once Gmail can see that the message really came from a Google server on your authorized list, it lets it through.

Sure enough — as soon as the record was in place, the next notification landed in the inbox.

So can scammers just set SPF and pass the check?

In Gemini’s answer, it pointed out that scammers cannot claim to own someone else’s domain and then set SPF for that domain.

That was the missing context for me: scammers usually impersonate a well-known domain when they send mail. The mechanism is there to check that “the identity they claim really is theirs.” They can buy their own domain and set SPF on it — but they cannot pretend to be some other famous domain.

Even if they do buy their own domain, Gemini mentioned another signal: Google’s Domain Reputation, which also factors in Domain Age. A domain only a few days old that suddenly sends a huge volume of mail looks like a high phishing risk.

That answer left me oddly satisfied. Trust works the same way with people: it takes time to build. Even in a machine world — trust and value are still best judged over time.