Calendar Invite Phishing: Admin Controls for Microsoft 365 and Google Workspace

In Exchange Online, meeting invitations are written to user calendars during delivery, so delivering a scam invite to Junk doesn't keep it off the calendar, and user mailboxes can't turn that processing off. Stop these messages before they reach the mailbox: quarantine high-confidence spam, consider a mail flow rule for external calendar messages, and use Hard Delete when you need to remove what got through. In Google Workspace, require "Invitations from known senders" for everyone. Then make "verify invoices through a number you already have" a written policy, because the attack finishes on the phone.

This guide is for the people who run email at a small business or for an IT client. For the consumer version, see our guide to scam calendar invites. For the sample this guide draws on, see the fake Norton invite we took apart.

How the attack works

The attacker creates a Google Calendar event (some use iCloud or Microsoft 365) whose title and description are a fake subscription invoice: a security or payment brand, a few hundred dollars, "Paid" or "renewed", a 24-hour deadline, and a phone number to cancel. They invite the target. Google sends the invitation from its own infrastructure with a valid google.com DKIM signature. There's no URL or attachment payload for a gateway to detonate, just a phone number in the event text.

The organizer accounts come from three places in published reporting:

• Freshly registered domains attached to new Google Workspace tenants, sometimes used within about an hour of registration (IRONSCALES).
• Older domains that slip past newly-registered-domain heuristics (IRONSCALES).
• Compromised accounts, including Google Workspace for Education accounts (IRONSCALES; Spamhaus).

Phone numbers, organizer addresses and domains change with nearly every published sample, so blocklists lag. Structural signals last longer.

A real sample, header by header

Our sample reached a personal Outlook.com mailbox on September 25, 2026. Summarized from its headers:

Sender:                [email protected]
DKIM:                  pass, header.d=google.com
SPF:                   temperror
DMARC:                 temperror
Spam confidence level: 8, delivered to Junk
Calendar:              tentative event created anyway

DKIM passed for google.com: Google signed the notification. That establishes Google sent the message, not who wrote the event.

SPF and DMARC returned temperror. The organizer's account is on a Mexican school's Google Workspace domain. When we queried that domain on October 2, 2026, it was still registered, but its delegated nameservers returned REFUSED for every record type, so public resolvers returned SERVFAIL. RFC 7208 says that when a DNS lookup returns a server failure, SPF evaluation "terminates immediately with the result 'temperror'" (RFC 7208), and DMARC records a temporary error the same way (RFC 7489). Despite the name, this failure isn't temporary.

In other published Google Calendar samples, SPF was evaluated against the organizer's domain as the envelope sender, not against a google.com bounce address (IRONSCALES). And if the From address had been [email protected], DMARC would have aligned with the passing google.com signature and passed. Both point to the organizer's domain being the one checked, with Google's address in the Sender header. Check smtp.mailfrom and header.from in your own samples' Authentication-Results to confirm the pattern in your tenant.

That gives a useful fingerprint:

Spam confidence level. Microsoft scored the message SCL 8 and delivered it to Junk. Note that Microsoft now says SCL "no longer holds the same meaning in cloud organizations" and doesn't determine the spam verdict (Microsoft Learn), so read the verdict fields in the antispam report header alongside it.

The 10-minute fuse. The event was created at 16:20 UTC to start at 16:30 UTC, so any reminder of 10 minutes or more was already due on arrival. Details are in the teardown.

Microsoft 365 and Exchange Online

Why Junk delivery doesn't help

Microsoft's Defender team describes the gap directly: "Even after the email is removed, Outlook automatically creates a calendar entry during delivery, which remains accessible to users" (Microsoft). The Calendar Attendant runs on user mailboxes in AutoUpdate mode, and the Set-CalendarProcessing documentation states: "The default value for user mailboxes is AutoUpdate, but you can't change the value on a user mailbox." AddNewRequestsTentatively defaults to $true (Microsoft Learn). Parameters such as ProcessExternalMeetingMessages apply to resource mailboxes, not users, and Set-MailboxCalendarConfiguration has no setting for unknown senders or junked invitations (Microsoft Learn).

The practical consequence: any control that still delivers the message, including Move to Junk, leaves the calendar entry. Controls have to act before delivery, or remove the entry afterward.

Keep the message out of the mailbox

• Quarantine high-confidence spam. The Default anti-spam policy moves high-confidence spam to Junk. The Standard and Strict preset security policies quarantine it (Microsoft Learn). Adopting a preset, or setting the high-confidence spam action to Quarantine in your own policy, means those messages never reach the mailbox, so there should be nothing for the Calendar Attendant to process. Microsoft doesn't document calendar behavior for quarantined meeting requests, so confirm it with a test invite.
• Consider a mail flow rule for external calendar messages. Mail flow rules support the condition "The message type is: Calendaring" combined with "The sender is located: Outside the organization" (Microsoft Learn). Routing every external invitation to quarantine or moderation is a blunt instrument; it will catch legitimate partner and customer meetings. A narrower variant to test: match the Sender header [email protected] plus body patterns for a phone number and billing words such as "invoice", "renewal" or "payment", and add exceptions for domains you meet with regularly.
• Don't block [email protected]. Every legitimate Google Calendar invitation uses it. In the Tenant Allow/Block List, a block on that address would quarantine all of them.

Remove what got through

• Hard Delete removes the calendar entry. Since September 2025, Defender for Office 365's Hard Delete action also removes the calendar entry that a malicious meeting invitation created (Microsoft). It's available from Threat Explorer, Advanced Hunting and the API, and requires Defender for Office 365 Plan 2 and the Search and Purge role (Microsoft Learn). Move to Junk, Delete and Soft Delete leave the entry in place. Events users added themselves from an .ics file aren't covered.
• Don't count on ZAP. Microsoft's zero-hour auto purge documentation doesn't mention calendar items.
• Remove-CalendarEvents won't help. It cancels meetings the mailbox itself organized, not invitations from outside.
• Without Plan 2, users need to delete the events themselves. Our removal guide covers Outlook's response prompts, so they don't send declines to the scammer.

Hunt for them

Advanced Hunting has no message-body or calendar fields, so you can't search event text directly. EmailEvents gives you DeliveryLocation, IsFirstContact, EmailLanguage and ThreatClassification (Microsoft Learn), and .ics files appear in EmailAttachmentInfo (Microsoft Learn). A starting point, which we haven't validated in a production tenant:

// Inbound messages carrying .ics files, grouped by sender and where they landed.
let ics = EmailAttachmentInfo
    | where Timestamp > ago(30d)
    | where FileName endswith ".ics"
    | project NetworkMessageId, RecipientEmailAddress;
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| join kind=inner ics on NetworkMessageId, RecipientEmailAddress
| summarize Messages = count(), Recipients = dcount(RecipientEmailAddress)
    by SenderFromAddress, SenderMailFromDomain, DeliveryLocation
| order by Recipients desc

Senders with many recipients and a Junk delivery location are the ones whose calendar entries are still sitting on calendars.

Google Workspace

Since August 14, 2026, admins can enforce how invitations are added. In the Admin console, go to Menu > Apps > Google Workspace > Calendar > Advanced settings > Add invitations to Calendar. Set the least restrictive level users may choose, and the default, to Invitations from known senders. The setting now applies to existing users as well as new ones, and can be scoped by organizational unit or group (Google Workspace Admin Help; Google). Google ships the control set to "From everyone", so this is a change you have to make.

Before that control existed, several universities changed their own Workspace defaults for the same reason (Mount Holyoke; NC State). Tell users about Report as spam and Block [name] in Google Calendar, and that deleting an invitation on the web sends the organizer a decline (Google).

Detection signals

Public detection for calendar-delivered callback phishing mostly looks at the event text. Sublime Security's open rules include "Callback phishing via calendar invite", which parses the .ics and runs a callback-scam language classifier on the event's summary and description, and a separate rule for Google Calendar notifications that contain callback language (sublime-rules). SpamAssassin's development branch gained an iCalendar handler in July 2026 that feeds event summaries and descriptions to body rules, but it isn't in a release yet (Apache SpamAssassin).

In the public rule sets we reviewed on October 2, 2026, we found nothing using these signals, all present in our sample:

None of these is a verdict on its own. They work as scoring signals alongside callback language, an external first-time organizer, and brand names that don't match the organizer's domain.

People and process

The call is where the damage happens, and businesses are targets too. The FBI has warned that the Silent Ransom Group sends fake subscription notices, has callers install remote-access tools such as Zoho Assist, AnyDesk or Splashtop, and exfiltrates data for extortion, and that it has consistently targeted US law firms since spring 2023 (FBI). Microsoft described the same call-in step delivering malware and ransomware in its BazaCall research (Microsoft).

• Write the policy down: invoices and renewals are verified through a number or portal you already have, never one in the message.
• Include calendars in phishing training. Tell staff that Junk doesn't remove calendar events and that a bill on a calendar is never a bill.
• Give people a reporting path that covers calendar events, and a rule to report even if they already called.
• Add a monthly check. Review delivered and junked messages with .ics files alongside the other items in our small business security checklist.

If someone already called, our guide on what to do after calling the number on a fake invoice covers containment and reporting.

Where Blue Lantern fits

A URL scanner has nothing to analyze in a phone-only lure. For a reported invitation, our Email Analyzer shows the sender and authentication results, and the email analysis API lets you run reported messages through it in bulk. How to read a suspicious email report explains why a passing DKIM signature doesn't settle trust. We're working on checks for the calendar-specific signals above; until they ship, the tenant settings in this guide are what stop these invitations.

Analyze an email with Blue Lantern Security