email_verified_at, a timestamp. Laravel 5.7 came out this month with email verification built in, and this column is the first thing I noticed. A boolean would cost the same and answer less. A timestamp answers not only whether, but when, and when a support ticket arrives half a year later, “when” is the question.
The tutorials say: implement MustVerifyEmail, put the verified middleware on routes, done. True, and boring. The interesting part is how the feature is put together. It is a small example of a cross-cutting feature done right.
The link is a signed URL. Route parameters signed with the application key, expiration inside the URL itself. So there is no tokens table, nothing to store, nothing to clean up. The server checks its own past promise by signature alone. Signed URLs are the most underused tool in this framework, and this feature shows why they exist.
Then the middleware. Verification is enforced at the routing layer. No if checks sprinkled through controllers. That is what makes it cross-cutting instead of a pile of conditions.
Two places where you still think for yourself. Double clicks: the user clicks the link twice and two requests race. Nothing breaks, because setting a timestamp that is already set is harmless. The operation is idempotent, so the race is boring. That is the general recipe. Make the action idempotent and the race goes away.
Email change. A verified user changes the address, and verified status must reset, and this part is on you. Forget it and “verified” quietly means “verified some other address, once”. I forgot it on the first project where I wired verification by hand. The column was set. It was true about an address nobody used anymore.