Why Google Calendar Invite Responses Get Blocked After You Set DMARC to p=reject

You set DMARC to p=reject. Your domain's email authentication is now enforced. Then a user reports: "I declined a calendar invite and the organizer never got my response."

This is a known conflict between Google Calendar's response mechanism and DMARC strict enforcement. The policy is correct. The problem is how Google Calendar sends responses by default.

How Google Calendar sends responses

When you accept or decline a Google Calendar invite, Google sends the response on your behalf, from your email address, not from calendar.google.com.

The From header reads: attendee@yourcompany.com. The sending server is a Google IP.

From the receiving server's perspective: an email claiming to be from attendee@yourcompany.com left Google's own infrastructure. For DMARC to pass, SPF or DKIM must not just pass, but pass as your domain — this is called alignment. SPF is checked against the message's Return-Path, which on calendar responses is a Google-owned domain, so SPF authenticates Google's domain, not yours — even though _spf.google.com is in your SPF record, the result is not aligned to yourcompany.com. DKIM is signed by Google under a Google domain (such as calendar.google.com), not yourcompany.com, so the signature is valid but also not aligned. Whether SPF, DKIM, or both fail to align depends on your setup and how Google handles the specific response path.

DMARC sees that neither identifier aligned. p=reject means: reject. The response never arrives.

This is DMARC working correctly. The conflict is that Google Calendar's default sending behavior is not compatible with strict DMARC enforcement.

The fix: Google Workspace Admin setting

This is a Google Workspace configuration problem, not a DNS problem. DNS changes do not fix it — the message is authenticated under Google's domain, and no DNS change controls which domain Google signs that path with.

Google Workspace Admin provides a setting to change how calendar responses are sent, routing them through a calendar resource address instead of as the end user.

In Google Workspace Admin Console:

Go to Apps → Google Workspace → Gmail → Advanced settings

Search for Calendar responses

Enable sending responses as the calendar resource

If the setting is not in that location, check under Apps → Google Workspace → Calendar → Advanced settings. Google has relocated this setting across Admin console versions; if you cannot find it, check Google's current admin documentation for your edition.

If your edition does not support the setting, the practical workarounds are: set DMARC to p=quarantine until resolved, or route calendar responses through an external SMTP service.

Verifying the fix

After changing the setting, have a user send a test response. The verification is in your DMARC aggregate reports, you are looking for failures where the Source IP belongs to calendar.google.com. If the setting took effect, those failures stop appearing.

Reading aggregate reports for a specific IP pattern in raw XML is slow, and this is exactly the kind of failure that tends to surface through user complaints rather than monitoring, someone tells you their response never arrived days after the fact. DMARCFlow processes your aggregate reports and shows failures alongside their source IPs and authentication results in a readable format, so the calendar.google.com failure pattern is visible the moment it appears in your reports, before anyone has to report a missing response. That is when the fix is a five-minute Admin Console change rather than a support ticket investigation.

What to check before setting p=reject

Calendar response blocking is one of the most common early failures when moving to p=reject. Audit these before you enforce:

1. Calendar response delivery setting in Google Workspace Admin

2. Google Groups sending behavior (if you use Groups for mailing lists)

3. Any third-party Google integrations that send as your users

4. Review your aggregate reports for existing failures from Google IPs before going to p=reject

This checklist catches more than calendar. Any Google service that sends as your users needs to be verified before strict enforcement.

The short version

Google Calendar sends response emails as the attendee, not as calendar.google.com. This fails DMARC p=reject because the response is authenticated under Google's domain, not yours — SPF and DKIM can pass, but neither aligns to yourcompany.com.

The fix is in Google Workspace Admin Console: change the calendar response delivery setting. DNS changes do not fix this.

Before setting p=reject, check this setting. Calendar response blocking is one of the most predictable early failures in DMARC enforcement and one of the easiest to fix if you know where to look.