Email Verification Authentication: Laravel Implementation

Email Verification Authentication: Implementation on Laravel

We often encounter tasks where standard password authentication creates more problems than it solves. Spam registrations (up to 70% of all attempts) clog the database, forgotten passwords generate a stream of support tickets, and database leaks discredit the service. Email verification authentication eliminates these risks. Significant support cost savings can be achieved by reducing support workload and decreasing fake accounts.

Why Is Email Verification Critical for Security?

Without verification, an attacker can register with any address and send spam or gain access to features that require confirmation. Verification guarantees that the user owns the mailbox. Additionally, it is the first step to account recovery and protection against account takeover. According to our project data, implementing verification reduces fake registrations by 95%.

Two Usage Scenarios

The first scenario is verification during registration. The user registers with a password, receives an email, confirms the address—only then gets full access. The second is passwordless login. The user enters their email, receives an email with a link, clicks it—authenticated without a password. Both scenarios can coexist.

How We Implement Email Verification Turnkey

Email Verification During Registration (Laravel)

The User model implements the MustVerifyEmail contract. This requires defining the sendEmailVerificationNotification() method, which sends a custom notification. We use built-in signed URLs.

class User extends Authenticatable implements MustVerifyEmail { public function sendEmailVerificationNotification(): void { $this->notify(new CustomVerifyEmailNotification()); } } Route::get('/email/verify/{id}/{hash}', [VerifyEmailController::class, '__invoke']) ->middleware(['auth', 'signed', 'throttle:6,1']) ->name('verification.verify'); 

The signed URL is generated with an expiration of 60 minutes. The signature is HMAC-SHA256 using the APP_KEY. Modifying parameters returns a 403.

$url = URL::temporarySignedRoute( 'verification.verify', now()->addMinutes(60), ['id' => $user->id, 'hash' => sha1($user->email)] ); 

OTP Code Instead of Link

Some projects prefer a 6-digit code—more convenient if the email is opened on another device. We cache the code hash with a 10-minute expiration and verify using hash_equals for timing attack protection.

$code = str_pad(random_int(0, 999999), 6, '0', STR_PAD_LEFT); Cache::put("email_verification:{$user->id}", hash('sha256', $code), now()->addMinutes(10)); public function verify(Request $request): JsonResponse { $stored = Cache::get("email_verification:{$user->id}"); if (!$stored || !hash_equals($stored, hash('sha256', $request->code))) { return response()->json(['message' => 'Invalid or expired code'], 422); } $user->markEmailAsVerified(); Cache::forget("email_verification:{$user->id}"); return response()->json(['message' => 'Email verified']); } 

Spam Protection and Resend

RateLimiter is configured so that one email can be sent no more than once every 5 minutes. The frontend shows a countdown until the next send. This prevents brute force and spam attacks.

RateLimiter::for('email-verification', function (Request $request) { return Limit::perMinutes(5, 1)->by($request->user()->id); }); 

Email Change with Verification

Changing an email safely requires confirming the new address. We introduce a pending_email field in the users table or a separate table. A verification email is sent to the new address, and only after successful confirmation is the email updated.

$user->update(['pending_email' => $newEmail]); // Send verification to $newEmail // Upon confirmation: $user->update(['email' => $newEmail, 'pending_email' => null]); 

Queue Configuration and Monitoring

Email sending must be asynchronous to avoid blocking the response. We use the Laravel queue (Redis or SQS drivers) and configure monitoring via Horizon or Laravel Pulse. If an email is not delivered, we log the error and notify the administrator.

How We Implement Email Verification: Step-by-Step Plan

1. Analyze requirements and choose the scenario (registration, passwordless, or both).
2. Design the data model: add email_verified_at, pending_email fields, configure queue relationship.
3. Implement routes and controllers with signed URLs or OTP.
4. Create custom email templates (HTML + plain text).
5. Configure rate limiting and error handling (expired links, repeated clicks).
6. Test edge cases (email change, resend, parallel requests).
7. Deploy using queues and monitoring.

Comparison of OTP and Magic Link

Implementation Stages

Handling Expired Links

If the user clicks an expired link, we return a clear message with a "Resend email" button. If they click an already confirmed link, we return a 200 with a notification that the email is already verified.

Common Mistakes and Their Solutions

• Expired link: display a message and offer to resend.
• Repeated click on link: return 200 with a notification that the email is already verified.
• Missing queue: sending emails synchronously slows the response—we use the Laravel queue.

What You Get as a Result

• Complete source code with comments (models, controllers, notifications).
• Custom email templates adapted to your brand.
• Queue and monitoring configuration (Laravel Horizon/Pulse).
• Developer documentation for deployment and maintenance.
• 30-day guarantee and support after implementation.

Contact us for a consultation—we will assess your project and offer an optimal solution. Order a turnkey implementation and get a ready-made authentication system in the shortest possible time.