Block calendar invites for meetings you never agreed to attend
Searching for a way to block calendar invites usually starts with one of two events on screen. Either a meeting appeared on a calendar that nobody agreed to, sent by an address nobody recognises, sometimes with a link in it that looks like bait. Or a colleague keeps putting recurring meetings into a week that no longer has room for them. The two look identical on the calendar grid and need opposite treatments, and neither of them is solved by a button called block, because no calendar service offers one. What they offer is an admission rule and a reporting action, and knowing which does what is the difference between a quiet calendar and a calendar that gets worse after every attempt to fix it.
There is no block button, and that changes the plan
Neither Google Calendar nor Apple's Calendar has a per sender block list for invitations. The mechanisms that exist fall into two groups.
The first group decides whether an invitation is allowed onto the calendar at all. In Google Calendar this is a single setting with three positions, found under Settings, then General, then Event settings. It can accept invitations from everyone, accept them only when the sender qualifies as known, or hold everything in email until it has been answered.
The second group deals with an invitation that is already on the calendar. In Google Calendar that action is Report as spam, reached by opening the event, then More actions. Reporting removes the event from the calendar, and if the event repeats, every occurrence in the series is removed with it.
Reporting has one hard boundary worth knowing before relying on it. To report an event as spam, it has to have been sent from Google Calendar. Events created by another provider, app or service cannot be reported this way, and the only route left for those is deletion. A calendar that is full of junk arriving from somewhere other than Google Calendar therefore needs the admission setting rather than the reporting action, because the reporting action will simply not be available.
The distinction also explains a common frustration. An unwanted event that keeps reappearing on a phone after being deleted on a laptop is almost never a syncing fault. It is usually the same event being removed on one device while the account still holds it, or a repeating series where only one occurrence was deleted. Actions that work at the account level settle it in one pass, which is why reporting is preferable to deleting whenever it is offered: reporting takes the whole series out, and there is nothing left to come back.
Why declining a junk invitation is the wrong move
The instinct with an unwanted invitation is to press decline and be done with it. For a stranger that is the one action worth avoiding.
The reason is documented plainly in how invitations work: when a response is sent to an invitation, the organizer gets a notification. That is exactly the behaviour a person wants with a colleague, and exactly the behaviour to avoid with an address that is mass mailing invitations. A decline is a delivery receipt. It confirms that the address is live, that a human read the invitation, and that the invitation got through whatever filtering was in place. The reward for declining is more invitations.
Reporting as spam does not work that way. It removes the event, and the whole series if the event repeats, without sending a response back. For an event that cannot be reported, because it came from another provider, plain deletion is the closest equivalent, and it is worth doing without opening any link inside the event first.
The same logic applies to the links and the phone numbers inside these events. A junk invitation is a delivery mechanism, and the event body is the payload. Removing the event without interacting with its contents is the whole point of the exercise.
Closing the door rather than sweeping the floor
Cleaning up is reactive. The setting that actually reduces the volume is the admission rule, and the middle position is the one that fits most people: an event is added to the calendar only if the sender is in the contacts, is part of the same organization, or is someone there has been previous interaction with.
Three things about that rule matter in practice.
It is broad. Previous interaction counts, so a single email exchange years ago is enough to qualify a sender as known. That makes it an effective filter against complete strangers and a weak one against anything that was ever half signed up for.
It is not retroactive. An updated setting applies to new invitations only, so nothing already on the calendar disappears when the setting changes. The cleanup pass is separate, and doing it in the wrong order creates the impression that the setting did nothing.
It can be visible. The documentation notes that choosing the known sender option may reveal to a sender that they are not in the contacts, since what they see differs. In most work situations this is irrelevant. Where a first contact from a stranger is a normal part of the job, it is a real cost to weigh.
There is also a chance the choice is not available at all. On an account managed through work or school, an administrator can restrict which invitation options a person can pick, so a missing option is policy rather than a fault.
One more path deserves attention, because the admission rule does not cover it the way people assume. An invitation sent to a Google Group is not added to a calendar automatically even on the most permissive setting, and it waits for a response in email instead. That is good news for anyone whose address sits on a public mailing list, since the mass invitation route through a group is closed by default. It is less good news for internal announcements sent to a team group, which will keep sitting in email rather than appearing on the calendar, and which therefore get missed by exactly the people who assume everything reaches the calendar on its own.
The same problem on an Apple account
An iCloud calendar has its own version of both mechanisms, with different names.
Invitations can be set to arrive as notifications inside Calendar rather than as email, and when that is how they arrive, they collect behind the Calendar inbox button in the sidebar on iCloud.com. For a junk invitation, the action is to open the event and select Report Junk, after which the event is automatically deleted from the calendar on every device signed into the account. That last part is the useful bit: one action on one device settles it everywhere, rather than leaving the same event to be deleted again on an iPhone an hour later.
On the Mac, the Calendar app surfaces incoming invitations behind the Notifications button in the toolbar, with New showing the ones that have not been handled, and Accept, Decline and Maybe available on each. What the Calendar app does not have is its own admission rule. Its settings are organised into General, Accounts, Alerts and Advanced, covering views, accounts, default alerts and departure reminders, and time zone handling. Nothing there decides which invitations are allowed in.
That is the single most useful thing to understand when the unwanted events are appearing in a Mac calendar. The app is showing what the account admitted. A Google account keeps obeying whatever its Event settings say, whether it is being read in a browser or in a desktop calendar, so the fix belongs in the account rather than in the app.
What each action actually does
| Action | Sender learns something | Effect on the series | Available for |
|---|---|---|---|
| Decline | Yes, the organizer is notified | Depends on which occurrence is declined | Any invitation |
| Report as spam in Google Calendar | No response is sent | The whole series is removed | Events sent from Google Calendar only |
| Report Junk on iCloud.com | No response is sent | The event is deleted on all devices | iCloud calendar events |
| Delete the event | No response is sent | Only what is deleted | Anything on the calendar |
| Known sender setting | Nothing, no event is created | Prevents future ones | Google Calendar, unless restricted by an admin |
The first row is the one to read twice. Declining is the only action in the table that sends information back, which is why it belongs with colleagues and nowhere near strangers.
When the sender is a colleague and not a spammer
A meeting nobody wants is not the same problem as a meeting nobody sent for a legitimate reason, and none of the tools above help with the second case. Everyone inside the same organization counts as a known sender, so no admission rule will keep a colleague's invitations out, and reporting a colleague as spam is not a plausible move.
What exists instead is the reply, and it has more range than a straight refusal. The three responses are Yes, No and Maybe, and the dropdown beside Maybe holds Propose a new time, which sends a different slot back to the organizer with an optional message attached. It is unavailable for all-day events and for events with more than 200 guests, which is a fair description of the meetings where negotiating a time was never going to work anyway. Invitations can also be answered from the Gmail message itself, at the top of the email, without opening the calendar.
Before reaching for any of that, the cheaper move is an audit. A recurring meeting that was set up for a reason that no longer applies keeps consuming the same slot every week, and nobody cancels it because cancelling looks like a decision about other people. Listing the repeating meetings on a calendar, with the question of what each one produces written beside it, usually removes more time from a week than any invitation setting will. The ones that survive the question are worth attending, and the ones that do not can be handed back to the organizer with a proposed alternative rather than a flat refusal.
The structural fix is different again. Recurring meetings accumulate because the calendar shows empty space and empty space reads as availability. Time that is already committed to work, blocked on the calendar rather than held in a person's head, is the only thing that makes a week look as full as it actually is. How that gets entered without becoming a chore is covered in entering events, and the space that gets eaten by travel between commitments is handled in travel time.
What to change first
Read the current Event settings value before touching anything, then clear what has already landed, then set the admission rule. For junk, report rather than decline, so the address learns nothing. If the invitations that hurt are the ones from colleagues, the calendar needs to show committed work rather than open space, which is the case Caltimate is built for on the Mac.
Frequently asked questions
Can a specific person be blocked from sending calendar invitations?
Not with a per sender block list, because neither Google Calendar nor Apple's Calendar offers one. The closest control in Google Calendar is the setting that admits events only when the sender is known, meaning a contact, someone in the same organization, or someone there has been previous interaction with. Anyone who qualifies as known cannot be filtered out individually.
Does declining a spam invitation stop the sender?
It is more likely to encourage them. When a response is sent to an invitation, the organizer gets a notification, so a decline confirms that the address is live and that the invitation was read. For an event sent from Google Calendar, reporting it as spam removes it and every occurrence of the series without sending any response back.
Why is "Report as spam" missing on an event that clearly is spam?
Because the option only applies to events that were sent from Google Calendar. An event created by another provider, app or service cannot be reported this way, and the remaining option is to delete it. Where junk keeps arriving from outside Google Calendar, the admission setting is the control that actually reduces the volume.
Will changing the invitation setting clear the events already on the calendar?
No. An updated setting applies to new invitations only, and everything already added stays in place. Doing the cleanup after the change, rather than before it, is what makes the change look ineffective. On an iCloud calendar, reporting an event as junk on iCloud.com deletes it from the calendar on all devices at once.