Watch send limits protect your own inbox

Setup

1. Press Start on this page.

2. In Authentication, turn on Self-service registration and save.

Restore: turn self-service registration off again in Cleanup. An open sign-up form is exactly the surface this lesson is about.

3. Pick a second plus-address of your own for a new account, for example [email protected]. Every email in this lab goes to your own inbox; never type someone else's address.

Note: your tenant sends email only, never text messages, so the lesson's SMS pumping has no counterpart here. The same per-destination limits are what would protect a text-message budget.

Walkthrough

1. At $ISSUER/register, register with the new plus-address. The page says to check your email, and a verification message arrives.

Why it matters: verifying an address shows only that someone can read that mailbox. The lesson's fake sign-ups pass this step with throwaway mailboxes, which is why a benefit worth abusing should depend on more than an account existing.

2. Register again, this time with $MIA_EMAIL, which already belongs to Mia. The page says exactly the same thing. Mia's inbox receives a notice that her address was used to register again, with links to sign in or reset.

Why it matters: a registration form that says "this email is already registered" answers the enumeration question. Here the reply is identical, and only the real owner learns what happened.

3. At $ISSUER/reset-password, request a reset for $MIA_EMAIL. Then request more, one after another, until the page answers "Too many requests. Try again later." Count how many emails reached Mia's inbox.

Why it matters: the lesson's message flood types a victim's address into a form thousands of times. A per-destination limit caps how many messages one address receives however many people ask, which ends a flood directly.

4. Go back to $ISSUER/register and register with further new plus-addresses until the page answers "Too many registration attempts. Try again later."

Why it matters: sign-up limits per address and per browser stop one source creating accounts in bulk while a real person, who registers once, never meets them.

5. In the portal, open Overview > Usage and limits. Find the password resets per address, registrations per address and per browser, and tenant account emails. Each shows its count, its limit and when it resets, soonest first, without naming any address.

Why it matters: the lesson ends with a few numbers worth watching. Your tenant already counts them, and the view shows them without exposing who was involved.

6. In Audit, source Protocol activity, filter succeeded and find account.register with registration_started and registration_notice_sent, and account.reset_password with reset_requested. Then open Logs, source Protocol summaries, and find the requests the limits refused, each summary naming the limit that refused it.

Why it matters: floods are plain in the records once someone looks: many requests for one destination, then refusals by the same limit.

Break it

1. Sign in as Mia with her current password. It works, even after all those reset requests.

Why it matters: the lesson's "locking people out on purpose." A reset request changes nothing until someone who controls the mailbox completes it, so a stranger's requests cannot sign the owner out or disable her password.

Check your work

• Check my progress confirms the new registration, the notice to Mia, the reset request and Mia's sign-in afterwards.

• Your notes record how many emails reached each address before the limit, and the reset time shown in Usage and limits.

• The refused requests appear in Logs, not as individual Audit events, because the limit stopped them before any account was involved.

Cleanup

1. In Authentication, turn Self-service registration off again.

2. If you completed any test registration, delete that account in Users.

3. Let the send windows lapse before the next lab that emails Mia.