Calendly SPF and DKIM setup

What you are setting up

Calendly is a scheduling tool, and the email around a booking leaves by one of three paths. Email confirmations are sent by Calendly from notifications@calendly.com, with the reply-to set to your Calendly login email or, if you choose it, a no-reply address. Calendar invitations are created by your connected calendar, which adds the invitee as a guest, so the message comes from your Google or Microsoft account and carries your domain. Automation emails (reminders, follow-ups, the old Workflows) default to notifications@calendly.com too, unless you connect a Gmail or Outlook account and send through it. None of the three gives you a Calendly DNS record to publish. There is no include: for Calendly and no calendly._domainkey selector; when customers asked for DKIM and SPF records on Calendly's community forum, its own team answered that this is not something Calendly facilitates. Your mail authenticates because your mailbox provider authenticates it, on the paths that go through your mailbox provider.

Publish SPF and DKIM

First, put your bookings on a path that actually leaves as your domain. Go to Scheduling, open the three dots on an event type, choose Edit, then More options, and open Notifications and automations. Pick Calendar invitations so the event is created by your connected calendar and the invitee hears from your address. For Automation emails, go to Automations > Integrations & apps and connect Gmail or Outlook, then in each Automation's email action set What email address should this email be sent from? to that account. Calendly documents this for personal event types on the Professional, Standard, Standard Plus, Teams, Teams Plus, and Enterprise plans, and only one connected account can send.

Then publish the records for whichever provider hosts those mailboxes. If you already did this for your day-to-day mail, Calendly is covered. For Google Workspace:

Type:  TXT     (SPF)
Host:  @
Value: v=spf1 include:_spf.google.com ~all

Type:  TXT     (DKIM)
Host:  google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA... (from the Admin console)

For Microsoft 365:

Type:  TXT     (SPF)
Host:  @
Value: v=spf1 include:spf.protection.outlook.com -all

Type:  CNAME   (DKIM)
Host:  selector1._domainkey
Value: (the target shown in the Defender portal)

Type:  CNAME   (DKIM)
Host:  selector2._domainkey
Value: (the target shown in the Defender portal)

The step-by-step for each, including the Google “Start authentication” click that people miss and the Microsoft DKIM enable toggle, is in our Google Workspace and Microsoft 365 guides. Keep a single SPF record and merge the include into it. Do not add an include “for Calendly”; there is none, and it would only spend lookups.

Add DMARC

Standard _dmarc TXT record, nothing Calendly-specific. Start in monitor-only mode and ramp up:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Build it with our DMARC builder and progress past p=none once your reports are clean.

The Calendly gotcha

Email confirmations are not your domain. Every confirmation Calendly sends itself carries calendly.com in the From address. Switching the reply-to to a no-reply address changes only where replies go; the From stays notifications@calendly.com. That mail never touches your SPF or DKIM and will not appear in your DMARC reports at all, so a clean report tells you nothing about whether invitees are hearing from you or from Calendly. Check the notification setting on each event type, because it is chosen per event type, not per account.

Domain control is not email authentication. Calendly's Enterprise plan has a feature called domain control that asks you to publish a TXT or CNAME record to prove you own a domain. It exists so admins can manage who signs up for Calendly with an address on that domain. It has nothing to do with SPF, DKIM, or DMARC, and publishing it does not authenticate a single message. The last trap is in Automations: the Gmail or Outlook sender is documented for personal event types only, and Calendly says that if you connect both Gmail and Outlook it falls back to sending from notifications@calendly.com. Connect one account, and confirm the From field in each Automation after you do.

Confirm it worked

• Book a test and read the headers. Schedule a meeting with yourself from an outside address, open the invitation, and confirm the DKIM signature shows d=yourdomain.com with dmarc=pass. Our header analyzer reads it back plainly. If the signing domain is calendly.com, that event type is still on Email confirmations.
• Check the mailbox provider, not Calendly. Calendly has no verification screen for DNS. The Google Admin console or the Microsoft Defender portal is where SPF and DKIM status shows.
• Watch the reports. Calendly-originated invitations and Automation emails will show up as Google or Microsoft in your DMARC aggregate reports, aligned and passing, because that is the server that delivered them. Calendly itself will never be a line in those reports; trustyourinbox labels the provider it actually sees.