How to stop spam or bot bookings in Microsoft Bookings

• restrict the page to your organization, if it's internal
• hide it from search engines
• require a one-time email code
• shorten the booking window
• clean up fake bookings quickly

Why the usual fixes aren't available#

The public page is hosted by Microsoft (outlook.office.com, and more recently bookings.cloud.microsoft), so you can't add your own scripts, reCAPTCHA or firewall rules to it. Tenant admins get eight Bookings controls under Settings → Org settings → Bookings, and none of them handles abuse beyond restricting access.

Settings that reduce spam#

About the one-time password option#

Shared pages can make every booker confirm their email address with a code. The shared Bookings documentation lists "enabling or disabling one-time passwords (OTP)" as a business setting that can take up to 10 minutes to apply, and a Microsoft moderator on Q&A gives its location: the page's Booking page settings, under access control, Require a one time password to create bookings. Microsoft Graph (beta) exposes the same thing as enforceOneTimePassword, false by default.

When we tested the code flow (September 2026), the first submit created no booking: Microsoft emails a 6-digit code to the address typed in at that moment, and the booking is created only when the form is sent again with that code. A wrong code was rejected. Our shared test page, on default settings, never asked for a code, so check the box is actually ticked. The cost is friction for real customers, especially on mobile; the Bookings with me verification answer describes the complaints.

For internal pages, requiring sign-in is the strongest option. See why a booking page makes people sign in for how the page-level and tenant-level settings interact.

Keep the link out of reach#

• Share service-specific links in emails and on gated pages instead of posting the main page URL everywhere.
• If you embed the page on your website, you can put it behind your own form (with your own CAPTCHA) that reveals the booking step. Once the Bookings URL is known, though, it can be reached directly, and the URL can't be changed without renaming the booking mailbox.

Cleaning up fake bookings#

• In the app: open the page's Calendar, then open and cancel each fake appointment. The FAQ notes that Bookings only lets one person book a given slot, so fakes block real customers until you remove them.
• In bulk: Bookings has no bulk-delete in the interface. A script using the Microsoft Graph Bookings API can list appointments and cancel them. The same applies to the fake customer records that bots leave behind; see bulk deleting customers.
• Stop repeats: tighten lead times (minimum notice and booking window). There's still no native per-customer or per-day cap; see limiting bookings per day.

Spam email arriving in the booking mailbox#

The second forum thread is a different problem. Each shared page has its own mailbox with an email address, and it can receive ordinary junk mail that then reaches the page owner. A Microsoft moderator called this normal. Treat it like any other Exchange Online mailbox: block the senders and tune your anti-spam policies for that address.

If your own confirmation emails are landing in customers' junk folders, that's a sender-domain problem. See Bookings emails going to spam.

Doing this with BookingsXP#

If you put the BookingsXP widget on your site, bookings made through it pass per-IP rate limits on the booking step, the allowed-domains setting stops other sites from embedding your saved widget, and an optional "Max bookings per day" cap stops the widget offering a day once it has that many widget bookings. These protect only the widget path: the public Bookings page Microsoft hosts stays reachable at its own URL, so the Microsoft settings above still matter. BookingsXP is independent and not affiliated with or endorsed by Microsoft.