Two links, two very different lifetimes
Setting up an account involves two emails that contain a link you have to click, and they behave differently on purpose. Knowing which is which saves a certain amount of confusion at exactly the moment you are least in the mood for it.
The link that verifies your email address after signing up is valid for seven days. The link that lets you set a new password after asking to recover one is valid for thirty minutes. That is a difference of more than three hundred times, between two things that look identical in your inbox.
The reason is what each link is worth to somebody who is not you. A verification link proves that whoever holds the mailbox asked for the account, and on its own it does not grant access to anything. A recovery link sets a password, which is complete control of the account. The second is the more valuable object by a wide margin, so it is alive for the shortest time that still lets a real person read an email and click it.
Long-lived recovery links are a genuine and well-understood weakness. They sit in mailboxes, in backups, in forwarded threads and in the search history of anyone who later gains access to that mailbox. Half an hour is not an inconvenience someone forgot to tune; it is the point.
Why your first email still works
If you request the verification email more than once, you may notice that the older message in your inbox still works. That is deliberate, and it is a more interesting decision than it looks.
The straightforward implementation would issue a fresh token on every request and invalidate the previous one. It has a serious flaw: anybody who knows your email address can submit it, which regenerates the token and breaks the link already sitting in your inbox. Repeat that and the account can never be activated, because every message you receive is invalidated by the next request. A stranger who knows only your address can deny you your own account indefinitely.
So an outstanding token is reused rather than rotated while it is still within its lifetime. A new one is generated only when there is no valid token to reuse. Verification clears the token entirely, so the case that needs a fresh one is unambiguous.
The everyday consequence is convenient: any verification email you have received recently will work, and you do not need to hunt for the newest one. The security consequence is that the window is bounded by the seven day lifetime rather than by how many times somebody poked the form.
The five minute wait between resends
Both flows limit how often mail can be sent for one account. After a verification email is sent, another cannot be sent for that account for five minutes, and password recovery mail has the same five minute limit.
This is not about server load. Both forms can be submitted by anyone who knows an email address, without signing in. Without a limit, that turns our mail service into a way to deliver mail to somebody repeatedly, which is a nuisance for them and a reputation problem for us. The limit means a stranger who submits your address in a loop achieves one email rather than hundreds.
The two limits are kept in separate buckets rather than sharing one. If they shared, requesting a password reset would silently suppress the verification email you needed next, and the resulting behaviour would be maddening to diagnose: an email that does not arrive, no error message, and no obvious relationship to the thing you did a minute earlier. Two unrelated flows should not be able to starve one another.
The limit also holds only the numeric account identifier, not your email address, so waiting for a resend does not put your address into a server-side cache.
Why the page does not say who you are
After submitting your address you land on a page that is deliberately vague, and does not carry your email address in the web address.
Query strings are among the leakiest places to put anything. They persist in browser history, in analytics, in proxy and server logs, and in the referrer header sent to any third party whose content the page loads. An email address placed there is copied into several systems that were never meant to hold it, by nobody's decision in particular.
The page is also written to read the same whether the address belongs to a new signup or an existing account. That is a small anti-enumeration measure: a page that says something different for a known address is a way to test whether an address has an account here. The generic wording costs a little clarity and removes that signal.
The same instinct runs through the surrounding code, which is why the resend limit is keyed on an account number rather than an address. Keeping personal data out of places it does not need to be is easier than removing it later, a theme covered more broadly in handling sensitive data in live chat.
What is checked when you sign up
Two rules govern the password, and both are enforced on the server rather than only in the browser.
A password must be at least eight characters, must not contain whitespace, and must not exceed one hundred and twenty-eight characters. The strength meter you see while typing is a helpful nudge above that floor and nothing more; these three rules are the ones that actually decide. They are checked on the server because the endpoint behind the form can be reached directly, and a scripted request bypasses every check that lives only in the page.
The upper bound is worth a word, since long limits sometimes suggest a password is being stored in a way that cares about length. It is a sanity bound on input size, and one hundred and twenty-eight characters is far above any passphrase a person will type.
The email address is validated more strictly than a single pattern match. It must parse as a real address, and must match exactly what you typed once parsed, which rejects the case where a display name or stray bracket is silently absorbed into something different from what you meant. It has a length limit, must not contain angle brackets, ampersands or quotes, and must have a domain that does not begin or end with a dot or contain two in a row.
One rule surprises people, so it is worth naming. An address at a well-known free mail provider with four or more dots in the part before the at sign, three or more of which separate single characters, is rejected. Those providers ignore dots entirely, so that pattern generates unlimited distinct-looking addresses that all deliver to one mailbox, and it is the signature of automated signups rather than of a person. If you have such an address legitimately, the same mailbox without the extra dots will be accepted and will receive exactly the same mail.
When a link does not work
Most reports of a broken link resolve to one of a few causes, and the lifetimes above identify which.
A recovery link that fails almost always failed on time. Thirty minutes is short enough that a message caught in a scanning gateway, or read an hour later on a phone, will be past it. The fix is to request another one and use it promptly; there is nothing to repair.
A verification link that fails after several days is likelier to be genuinely expired, since seven days is long enough that most other explanations have run out. If it is well inside the week, suspect the email itself: some clients and security products rewrite links, and a rewritten link may not carry the token intact.
A link that has already been used will not work twice. Verification clears the stored token, which is what makes reuse impossible, so a second click on a link that already succeeded looks like a failure and is not one. Try signing in before assuming anything is broken.
If mail is not arriving at all, that is a different problem from an expiring link and has a different diagnosis. When your chat notification emails stop arriving covers addresses that have been suppressed or that fail permanently, which is the usual cause of an email that never shows up rather than one that shows up too late.
How MyLiveChat fits
The numbers are worth remembering because they explain almost every question about these emails. Seven days to verify an address, thirty minutes to set a new password, five minutes between resends of either, tracked separately. An outstanding verification token is reused rather than rotated, so an earlier email keeps working and nobody can lock you out of activation by submitting your address. Passwords need eight characters and no spaces, and that is enforced where it counts rather than only in the browser.
These sit alongside the other account-level protections. What ten failed sign-ins actually locks covers the rate limit on the sign-in door itself, which is the control most often confused with these, and when a customer's account is locked covers helping somebody on the other side of the same wall.
If you are setting up a team rather than a single account, the more consequential decisions are about who gets an agent account and what it can reach. Account and agent administration covers those controls, and chat security basics for admins is the short list worth doing in the first week.