Why M365 Doesn't Receive Google Calendar Invites (When Other Email Works Fine)

The Specific Problem Pattern

A M365 admin gets a ticket: one user is not receiving calendar invites from a Google Workspace sender. Regular emails from the same person arrive fine. Forwarding the invite as an .eml file works. Message trace shows nothing.

The details here are diagnostic. Regular email working rules out basic connectivity. The .eml forward working rules out the calendar application itself being blocked. Message trace showing nothing means either the message never reached Exchange Online, or it was silently dropped before logging.

How Google Calendar Sends Invites

Google Calendar sends invites as standard email with an iCalendar attachment, but the sending path can differ from regular Gmail:

• Calendar invites may be routed through Google's calendar-specific sending infrastructure, which uses different IPs than regular Gmail
• The envelope sender for calendar invites can differ from the sender's Gmail address
• Recurring invites and updates often take a different delivery path

This matters for authentication. If the IPs used for calendar sending are not in the sender's SPF record, and the receiving M365 tenant has DMARC p=reject, the invite fails DMARC alignment silently, before message trace logs it.

The SPF Gap Is the Most Common Cause

This is the leading cause of the pattern described above. Google Workspace calendar sends sometimes use IP ranges not covered by the standard include:_spf.google.com directive.

Regular Gmail from the same sender works because Gmail sending IPs are in Google's published SPF record. Calendar invites use a different sending path, which may not be covered. If the receiving M365 tenant enforces strict DMARC, those invites fail alignment and get dropped silently.

The diagnostic tell: DMARC aggregate reports show alignment failures specifically for iCal messages from the sender's domain, even though regular email from the same sender passes DMARC. DMARCFlow's aggregate reporting surfaces this pattern directly.

M365 Mailbox Rules

If the message is reaching Exchange Online, check the recipient's mailbox rules.

Rules can move, delete, or forward calendar invites based on:

• Message class (IPM.SchedulePlus.Meeting.Request)
• Subject line patterns
• Sender domain

Even rules the user did not consciously create can apply, including shared mailbox rules, tenant-level transport rules, or rules migrated from a previous email system.

Defender for M365 ATP and Invite Scanning

Defender for M365 handles calendar invites differently from regular email:

• Safe Links may wrap URLs inside calendar invites in ways that some mail clients cannot process correctly
• Safe Attachments scanning can quarantine invites it flags as risky
• ATP anti-phishing policies may apply stricter checks to calendar invite message types

If Defender catches the invite, it may end up in quarantine without notifying the end user, especially with silent quarantine policies configured.

Diagnostic Steps

When one M365 user is not receiving Google Calendar invites while others in the same tenant do:

1. Check DMARC aggregate reports. Look for alignment failures on iCal messages from the sender's domain. If regular email passes but calendar invites fail, the calendar sending infrastructure is not covered by the sender's SPF. DMARCFlow's aggregate reports surface this pattern specifically.
2. Ask the sender to verify their SPF covers all Google sending ranges. The standard include:_spf.google.com may not cover calendar-specific sending IPs.
3. Check the recipient's mailbox rules. Include rules based on message class and subject, not just sender.
4. Check Defender quarantine. If the message reached Exchange Online but not the mailbox, Defender may have quarantined it silently.
5. Have the sender test with an .eml forward. If the .eml forward works but the original invite does not, the original delivery path is where the problem lies.

Prevention

If you manage the M365 receiving side:

• Review DMARC reports for calendar invite authentication patterns across all sending domains
• Verify M365 ATP Safe Links policies do not break calendar invite processing
• Configure quarantine policies so that blocked invites generate notifications, not silent drops

If you are the Google Workspace sender:

• Confirm your SPF record covers all Google calendar sending infrastructure, not just standard Gmail
• Consider using a dedicated sending domain for calendar invites with its own SPF record

FAQ

Why does regular email work but calendar invites fail? Google Calendar may send from IPs not covered by the sender's SPF record. Regular Gmail uses IPs in Google's published SPF. Calendar invites may use Google's calendar-specific sending infrastructure, which has a different IP range. With strict DMARC enforcement, the invite fails alignment and is dropped.

Can SPF issues affect calendar invite delivery but not regular email? Yes. If the calendar sending infrastructure uses IPs outside the sender's SPF record, invites fail DMARC alignment while regular email passes because it uses standard Gmail sending IPs that are in Google's SPF.

Does M365 Defender strip calendar invite attachments? Defender Safe Links and Safe Attachments policies can alter or quarantine calendar invites. If a message reaches Exchange Online but not the mailbox, check Defender quarantine. Silent quarantine policies may not notify the end user.