DEV Community: zerodrop

Claude Code Built My SaaS But Couldn't Verify Signup Emails

zerodrop — Sat, 20 Jun 2026 19:40:01 +0000

I've been building with Claude Code for the past few months. It's genuinely changed how I work — I can ship features in hours that used to take days.

But I hit a wall I didn't expect.

Claude Code built me a complete authentication system. NextAuth, email verification, password reset, the works. Every line of code was correct. The tests passed. The PR looked great.

Then I tried to run the E2E tests in CI.

They failed. Every single one.

The problem

Claude Code can write the code that sends an email. It can write the test that checks if an email was sent. But it cannot actually receive that email, read it, and verify the link works.

Here's what the test looked like:

test('user can verify email after signup', async ({ page }) => {
  await page.goto('/signup');
  await page.fill('[name="email"]', 'test@example.com');
  await page.click('[type="submit"]');

  // ??? how do we get the verification email here?
  const verificationLink = ???;

  await page.goto(verificationLink);
  await expect(page).toHaveURL('/dashboard');
});

Claude Code filled in everything except the part that actually mattered.

It suggested three approaches:

Mock the email service — "intercept the sendEmail call and return the link directly"
Use MailHog — "run a local SMTP server to catch emails"
Check the database — "query the verification_tokens table directly"

All three are wrong for the same reason: they don't test whether the email actually arrives.

Why mocking is lying

When you mock the email service, you're testing this:

Your app → [mock] → test passes

When you should be testing this:

Your app → email provider → real inbox → verification link → test passes

The difference matters. Mocking passes even when:

Your Resend API key has expired
Your email template has a broken link
Your DNS is misconfigured and emails are going to spam
Your email provider is down
Your verification token is being generated incorrectly

I've been burned by all of these in production. A mocked test would have caught none of them.

Why MailHog doesn't work in CI

Claude Code's second suggestion — MailHog — is the traditional answer. And it works locally.

In CI it's a different story:

services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - 1025:1025
      - 8025:8025

This adds 15-30 seconds of cold start time to every CI run. Parallel tests share one inbox, which means race conditions. And MailHog hasn't been maintained since 2020 — the Docker image has known vulnerabilities.

More importantly: MailHog doesn't test real email delivery. It's a fake SMTP server that catches outbound emails before they leave your network. You're not testing whether your email actually reaches an inbox — you're testing whether your app can connect to a local port.

The actual solution

The problem I needed to solve was simple: I need a real email address that my CI pipeline can read programmatically.

I built ZeroDrop for this.

import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can verify email after signup', async ({ page }) => {
  // Generate a real, isolated inbox for this test
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  await page.goto('/signup');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  // Wait for the real email to arrive — SSE delivery, sub-second
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  // Magic link auto-extracted — no regex
  expect(email.magicLink).not.toBeNull();

  await page.goto(email.magicLink!);
  await expect(page).toHaveURL('/dashboard');
});

This test:

Sends a real email through your actual email provider (Resend, SendGrid, Postmark)
Catches it in a real inbox
Extracts the verification link automatically
Navigates to it and verifies the flow works end-to-end

If your API key expires — the test fails. If your email template has a broken link — the test fails. If your DNS is misconfigured — the test fails. That's the point.

The GitHub Actions setup

- name: Generate test inbox
  id: inbox
  uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

- name: Run E2E tests
  run: npx playwright test
  env:
    TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
    RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}

Each CI run gets a fresh, isolated inbox. Parallel jobs don't share state. No Docker. No cold start. No MailHog.

What this means for AI-built apps

Claude Code is remarkably good at building auth systems. The code it generates is correct, well-structured, and follows best practices. But it has a blind spot: it can't verify that the system actually works end-to-end because it can't interact with the physical world.

Email delivery is part of the physical world. Your email provider, your DNS configuration, your email templates — none of these exist in Claude Code's context window. It can write code that calls the API. It can't verify the email arrives.

This is the infrastructure gap that AI coding tools expose: as agents ship code faster, the verification layer becomes the bottleneck.

ZeroDrop is one piece of that layer — the email piece. The test that Claude Code couldn't write, ZeroDrop makes possible.

The broader pattern

Every auth-enabled app built with an AI coding tool will eventually hit this wall:

Cursor builds the auth flow → tests mock the email → CI is green → production breaks
Claude Code builds the password reset → MailHog catches it locally → CI Docker fails → nobody notices
Devin ships the signup flow → email verification is skipped in tests → token expiry bugs reach users

The pattern is the same: AI builds fast, verification infrastructure hasn't caught up.

The fix isn't to build slower. It's to give your AI agent the infrastructure layer it's missing.

Try it

npm install zerodrop-client

Free tier. No signup. No API key. No Docker.

The test Claude Code couldn't finish — you can finish it in 5 minutes.

→ zerodrop.dev

Testing Email Flows in Cypress Without a Mail Server

zerodrop — Fri, 19 Jun 2026 20:05:02 +0000

Cypress is one of the most popular E2E testing frameworks for web applications. But testing email flows in Cypress has always required either a running mail server or mocking the email layer entirely.

This guide shows how to test real email flows in Cypress — verification emails, OTP codes, magic links, and password resets — without Docker, without MailHog, and without mocking.

The problem with email testing in Cypress

Most Cypress setups for email testing fall into one of three categories:

1. Mock the email service

cy.intercept('POST', '/api/send-email', { statusCode: 200 });

Fast, but tests nothing. If your email template has a broken link, this passes.

2. Use MailHog

services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - 1025:1025
      - 8025:8025

Requires Docker in CI, 15-30 seconds cold start, shared inbox breaks parallel tests, unmaintained since 2020.

3. Use a shared Gmail account
OAuth setup, manual cleanup, parallel tests collide. Not CI-friendly.

ZeroDrop replaces all three: real emails, no infrastructure, isolated per test.

Install

npm install zerodrop-client

Basic email verification test

// cypress/e2e/auth.cy.js
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

describe('Email verification', () => {
  it('user can sign up and verify email', () => {
    const inbox = Cypress.env('TEST_INBOX') ?? mail.generateInbox();

    // Sign up with disposable email
    cy.visit('/signup');
    cy.get('[name="email"]').type(inbox);
    cy.get('[name="password"]').type('TestPass123!');
    cy.get('[type="submit"]').click();

    cy.url().should('include', '/check-email');

    // Wait for verification email — magic link auto-extracted
    cy.wrap(mail.waitForLatest(inbox, { timeout: 30000 }))
      .then((email) => {
        expect(email.subject).to.contain('Verify');
        expect(email.magicLink).to.not.be.null;

        // Click the verification link
        cy.visit(email.magicLink);
        cy.url().should('include', '/dashboard');
      });
  });
});

OTP verification

ZeroDrop extracts OTP codes automatically — no regex needed in your tests:

it('OTP login flow', () => {
  const inbox = Cypress.env('TEST_INBOX') ?? mail.generateInbox();

  cy.visit('/login');
  cy.get('[name="email"]').type(inbox);
  cy.get('[type="submit"]').click();

  cy.wrap(mail.waitForLatest(inbox, { timeout: 30000 }))
    .then((email) => {
      // email.otp is auto-extracted at the edge
      expect(email.otp).to.not.be.null;

      cy.get('[name="otp"]').type(email.otp);
      cy.get('[type="submit"]').click();
      cy.url().should('include', '/dashboard');
    });
});

Password reset flow

it('password reset flow', () => {
  const inbox = Cypress.env('TEST_INBOX') ?? mail.generateInbox();

  // Request password reset
  cy.visit('/forgot-password');
  cy.get('[name="email"]').type(inbox);
  cy.get('[type="submit"]').click();

  cy.contains('Check your email').should('be.visible');

  // Catch reset email
  cy.wrap(mail.waitForLatest(inbox, { timeout: 30000 }))
    .then((email) => {
      expect(email.magicLink).to.not.be.null;

      cy.visit(email.magicLink);
      cy.get('[name="password"]').type('NewPass123!');
      cy.get('[type="submit"]').click();
      cy.contains('Password updated').should('be.visible');
    });
});

Parallel tests — zero configuration

Each test generates its own isolated inbox. No shared state, no race conditions:

describe('Parallel email flows', () => {
  it('flow A', () => {
    const inbox = mail.generateInbox(); // unique per test
    // ...
  });

  it('flow B', () => {
    const inbox = mail.generateInbox(); // different inbox
    // ...
  });
});

Run with cypress run --parallel — each spec gets its own inbox automatically.

Cypress custom command

Add a reusable command to your cypress/support/commands.js:

// cypress/support/commands.js
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

Cypress.Commands.add('waitForEmail', (inbox, options = {}) => {
  return cy.wrap(
    mail.waitForLatest(inbox, { timeout: 30000, ...options }),
    { timeout: 35000 }
  );
});

Cypress.Commands.add('generateInbox', () => {
  return cy.wrap(
    Cypress.env('TEST_INBOX') ?? mail.generateInbox()
  );
});

// Usage in tests
it('verifies email', () => {
  cy.generateInbox().then((inbox) => {
    cy.visit('/signup');
    cy.get('[name="email"]').type(inbox);
    cy.get('[type="submit"]').click();

    cy.waitForEmail(inbox).then((email) => {
      cy.visit(email.magicLink);
      cy.url().should('include', '/dashboard');
    });
  });
});

cypress.config.js

const { defineConfig } = require('cypress');

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000',
    defaultCommandTimeout: 10000,
    pageLoadTimeout: 60000,
    env: {
      // TEST_INBOX injected by GitHub Actions
    },
  },
});

GitHub Actions workflow

name: Cypress E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run Cypress tests
        run: npx cypress run
        env:
          CYPRESS_TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}
          CYPRESS_BASE_URL: ${{ secrets.STAGING_URL }}

The CYPRESS_ prefix automatically makes variables available as Cypress.env('TEST_INBOX').

Replacing MailHog

If you're migrating from MailHog, here's the before and after:

Before — MailHog:

# docker-compose.yml
services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - 1025:1025
      - 8025:8025

// cypress/e2e/auth.cy.js
cy.request('GET', 'http://localhost:8025/api/v2/messages')
  .then((response) => {
    const message = response.body.items[0];
    const link = message.Content.Body.match(/https?:\/\/\S+/)?.[0];
    cy.visit(link);
  });

After — ZeroDrop:

cy.wrap(mail.waitForLatest(inbox, { timeout: 30000 }))
  .then((email) => {
    cy.visit(email.magicLink); // auto-extracted, no regex
  });

No Docker. No service block. No regex. No cold start.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to E2E Test Amazon SES Email Workflows in Playwright

zerodrop — Fri, 19 Jun 2026 19:53:38 +0000

Amazon SES is the go-to transactional email service for teams already in the AWS ecosystem. But testing SES emails end-to-end in CI is notoriously painful — IAM permissions, sandbox restrictions, and no easy way to catch sent emails programmatically.

This guide shows the complete setup for testing Amazon SES email flows in Playwright using ZeroDrop — no Docker, no shared inboxes, no mocking.

The app we're testing

A Next.js API route that sends a verification email via Amazon SES:

// app/api/auth/signup/route.ts
import { SESClient, SendEmailCommand } from '@aws-sdk/client-ses';

const ses = new SESClient({
  region: process.env.AWS_REGION!,
  credentials: {
    accessKeyId: process.env.AWS_ACCESS_KEY_ID!,
    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY!,
  },
});

export async function POST(req: Request) {
  const { email } = await req.json();

  const token = crypto.randomUUID();
  const verifyUrl = `${process.env.NEXT_PUBLIC_URL}/verify?token=${token}`;

  await ses.send(new SendEmailCommand({
    Source: 'noreply@yourapp.com',
    Destination: { ToAddresses: [email] },
    Message: {
      Subject: { Data: 'Verify your email' },
      Body: {
        Html: {
          Data: `<p>Click <a href="${verifyUrl}">here</a> to verify your email.</p>`,
        },
      },
    },
  }));

  return Response.json({ success: true });
}

Stage 1 — Local development: SES sandbox mode

When you first create an Amazon SES account, it starts in sandbox mode. In sandbox mode:

You can only send emails to verified email addresses
You can only send emails from verified email addresses or domains
There's a sending limit of 200 emails per day

This is fine for local development — verify your own email address in the SES console and use it as the test recipient. But sandbox mode completely blocks automated CI testing because you can't verify a randomly generated @zerodrop-sandbox.online address.

What it solves: Basic local testing with a fixed test email address.

What it doesn't solve: Automated testing with random addresses, parallel test runs, or CI pipelines.

Stage 2 — Request production access

To use SES with ZeroDrop in CI, you need to move out of sandbox mode. Request production access in the AWS SES console:

Go to SES → Account dashboard
Click Request production access
Fill in your use case — "transactional email for application testing"
AWS typically approves within 24 hours

Once approved, SES can send to any email address including ZeroDrop inboxes.

Stage 3 — CI: SES production + ZeroDrop

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can sign up and verify email', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  // 2. Sign up — SES sends a real verification email to this inbox
  await page.goto('/signup');
  await page.fill('[data-testid="email"]', inbox);
  await page.click('[data-testid="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);

  // 5. Assert verified
  await expect(page).toHaveURL('/dashboard');
});

OTP flows

await ses.send(new SendEmailCommand({
  Source: 'noreply@yourapp.com',
  Destination: { ToAddresses: [email] },
  Message: {
    Subject: { Data: 'Your verification code' },
    Body: {
      Html: { Data: `<p>Your code is: <strong>${otp}</strong></p>` },
    },
  },
}));

const email = await mail.waitForLatest(inbox, { timeout: 30000 });

// OTP auto-extracted at the edge — no regex needed
expect(email.otp).not.toBeNull();
await page.fill('[data-testid="otp"]', email.otp!);
await page.click('[data-testid="verify"]');

IAM permissions for CI

Create a dedicated IAM user for CI with minimal permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource": "*"
    }
  ]
}

Store AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as GitHub Actions secrets — never in your codebase.

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          AWS_REGION: ${{ secrets.AWS_REGION }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          NEXT_PUBLIC_URL: ${{ secrets.STAGING_URL }}

Pro tip: Use GitHub's OIDC integration with AWS IAM roles instead of long-lived access keys — more secure and no key rotation needed.

The full picture

	SES sandbox (local)	SES production (staging)	SES production + ZeroDrop (CI)
Verified recipients only	✅ (limitation)	❌	❌
Random test addresses	❌	✅	✅
Automated in CI	❌	❌	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Request production SES access early — it unlocks automated testing and takes 24 hours to approve. Once approved, the live SES + ZeroDrop combination gives you full E2E coverage in CI.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to E2E Test Mailgun Email Workflows in Playwright

zerodrop — Fri, 19 Jun 2026 19:51:55 +0000

Mailgun is a popular transactional email API trusted by developers for reliable delivery. But how do you test that your Mailgun emails actually arrive, contain the right content, and work end-to-end in CI?

This guide covers the full testing progression — from local development to automated Playwright tests in GitHub Actions.

The app we're testing

A Next.js API route that sends a verification email via Mailgun:

// app/api/auth/signup/route.ts
import Mailgun from 'mailgun.js';
import FormData from 'form-data';

const mailgun = new Mailgun(FormData);
const mg = mailgun.client({
  username: 'api',
  key: process.env.MAILGUN_API_KEY!,
});

export async function POST(req: Request) {
  const { email } = await req.json();

  const token = crypto.randomUUID();
  const verifyUrl = `${process.env.NEXT_PUBLIC_URL}/verify?token=${token}`;

  await mg.messages.create(process.env.MAILGUN_DOMAIN!, {
    from: 'noreply@yourapp.com',
    to: email,
    subject: 'Verify your email',
    html: `<p>Click <a href="${verifyUrl}">here</a> to verify your email.</p>`,
  });

  return Response.json({ success: true });
}

Stage 1 — Local development: Mailgun sandbox domain

Mailgun provides a sandbox domain for testing. Emails sent to the sandbox domain are captured in your Mailgun dashboard without being delivered to real inboxes.

const mg = mailgun.client({
  username: 'api',
  key: process.env.MAILGUN_API_KEY!,
});

// Use sandbox domain for local development
await mg.messages.create(
  process.env.NODE_ENV === 'development'
    ? process.env.MAILGUN_SANDBOX_DOMAIN!  // sandbox.mailgun.org
    : process.env.MAILGUN_DOMAIN!,
  {
    from: 'noreply@sandbox.mailgun.org',
    to: email,
    subject: 'Verify your email',
    html: `<p>Click <a href="${verifyUrl}">here</a> to verify.</p>`,
  }
);

Important: Mailgun's sandbox domain only delivers to pre-authorized recipient email addresses. You must add your test email to the authorized list in your Mailgun dashboard.

What it solves: Visual inspection during local development without sending real emails.

What it doesn't solve: Automated testing. You can't programmatically read emails from Mailgun's dashboard in a Playwright test. The authorized recipient limitation also makes it unsuitable for CI where you need random inbox addresses.

Stage 2 — Staging: Mailgun live domain to a real inbox

Switch to your live Mailgun domain for staging:

await mg.messages.create(process.env.MAILGUN_DOMAIN!, {
  from: 'noreply@yourapp.com',
  to: email,
  subject: 'Verify your email',
  html: `<p>Click <a href="${verifyUrl}">here</a> to verify.</p>`,
});

Emails now go through real delivery. You can manually verify they arrive, links work, and nothing lands in spam.

What it solves: Does the email actually reach a real inbox end-to-end?

What it doesn't solve: Automation. You can't run this in CI without access to a real inbox your test can read.

Stage 3 — CI: Mailgun live domain + ZeroDrop

For automated Playwright tests in GitHub Actions:

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can sign up and verify email', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  // 2. Sign up — Mailgun sends a real verification email to this inbox
  await page.goto('/signup');
  await page.fill('[data-testid="email"]', inbox);
  await page.click('[data-testid="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);

  // 5. Assert verified
  await expect(page).toHaveURL('/dashboard');
});

No authorized recipient list. No sandbox limitations. ZeroDrop generates a new inbox for every test run — Mailgun delivers to it like any real email address.

OTP flows

await mg.messages.create(process.env.MAILGUN_DOMAIN!, {
  from: 'noreply@yourapp.com',
  to: email,
  subject: 'Your verification code',
  html: `<p>Your code is: <strong>${otp}</strong></p>`,
});

const email = await mail.waitForLatest(inbox, { timeout: 30000 });

// OTP auto-extracted at the edge — no regex needed
expect(email.otp).not.toBeNull();
await page.fill('[data-testid="otp"]', email.otp!);
await page.click('[data-testid="verify"]');

Using Mailgun templates

If you use Mailgun's stored templates:

await mg.messages.create(process.env.MAILGUN_DOMAIN!, {
  from: 'noreply@yourapp.com',
  to: email,
  template: 'verify-email',
  'h:X-Mailgun-Variables': JSON.stringify({
    verify_url: verifyUrl,
    username: 'Test User',
  }),
});

// ZeroDrop catches the fully rendered template
const email = await mail.waitForLatest(inbox, { timeout: 30000 });
expect(email.magicLink).not.toBeNull();

This tests that your Mailgun template renders correctly with real variable substitution.

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          MAILGUN_API_KEY: ${{ secrets.MAILGUN_API_KEY }}
          MAILGUN_DOMAIN: ${{ secrets.MAILGUN_DOMAIN }}
          NEXT_PUBLIC_URL: ${{ secrets.STAGING_URL }}

// Use CI inbox or generate locally
const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

The full picture

	Sandbox domain (local)	Live domain (staging)	Live domain + ZeroDrop (CI)
Visual inspection	✅ dashboard	✅ real inbox	✅ automated
No real emails sent	✅	❌	❌
Authorized recipients only	✅ (limitation)	❌	❌
Automated in CI	❌	❌	✅
Random test addresses	❌	✅	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Use the sandbox during development, the live domain for manual staging verification, and the live domain + ZeroDrop for automated CI.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to Test Nodemailer Email Flows in Playwright

zerodrop — Fri, 19 Jun 2026 19:38:07 +0000

Nodemailer is the most widely used email library in Node.js. If your Express, Next.js, or NestJS app sends emails, there's a good chance it's using Nodemailer under the hood.

But testing those emails end-to-end in CI has always been the hard part. This guide shows how to test the complete email flow with Playwright and ZeroDrop — no Docker, no fake SMTP server, no mocking.

The typical Nodemailer setup

// lib/email.ts
import nodemailer from 'nodemailer';

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: Number(process.env.SMTP_PORT),
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS,
  },
});

export async function sendVerificationEmail(to: string, token: string) {
  const verifyUrl = `${process.env.APP_URL}/verify?token=${token}`;

  await transporter.sendMail({
    from: 'noreply@yourapp.com',
    to,
    subject: 'Verify your email',
    html: `<p>Click <a href="${verifyUrl}">here</a> to verify your email.</p>`,
  });
}

export async function sendPasswordResetEmail(to: string, token: string) {
  const resetUrl = `${process.env.APP_URL}/reset-password?token=${token}`;

  await transporter.sendMail({
    from: 'noreply@yourapp.com',
    to,
    subject: 'Reset your password',
    html: `<p>Click <a href="${resetUrl}">here</a> to reset your password.</p>`,
  });
}

export async function sendOTPEmail(to: string, otp: string) {
  await transporter.sendMail({
    from: 'noreply@yourapp.com',
    to,
    subject: 'Your verification code',
    html: `<p>Your code is: <strong>${otp}</strong></p>`,
  });
}

Stage 1 — Local development: Nodemailer test account

Nodemailer has a built-in test account generator using Ethereal Email:

// For local development only
const testAccount = await nodemailer.createTestAccount();

const transporter = nodemailer.createTransport({
  host: 'smtp.ethereal.email',
  port: 587,
  auth: {
    user: testAccount.user,
    pass: testAccount.pass,
  },
});

// After sending, preview the email
const info = await transporter.sendMail({ ... });
console.log('Preview URL:', nodemailer.getTestMessageUrl(info));

This is useful for inspecting emails locally — the preview URL opens in a browser. But you can't automate reading from Ethereal in a Playwright test, and it doesn't work in CI.

What it solves: Visual inspection during local development.

What it doesn't solve: Automated testing. No programmatic API to read the email in a test.

Stage 2 — CI: Nodemailer + real SMTP + ZeroDrop

For automated testing in GitHub Actions, point Nodemailer at a real SMTP provider (Resend, SendGrid, Postmark) and use ZeroDrop to catch the emails:

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('email verification flow', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

  // 2. Sign up — Nodemailer sends the verification email
  await page.goto('/signup');
  await page.fill('[name="email"]', inbox);
  await page.fill('[name="password"]', 'TestPass123!');
  await page.click('[type="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);
  await expect(page).toHaveURL('/dashboard');
});

OTP flow

test('OTP login', async ({ page }) => {
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

  await page.goto('/login');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  // OTP auto-extracted at the edge — no regex needed
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });
  expect(email.otp).not.toBeNull();

  await page.fill('[name="otp"]', email.otp!);
  await page.click('[type="submit"]');

  await expect(page).toHaveURL('/dashboard');
});

Password reset flow

test('password reset', async ({ page }) => {
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

  await page.goto('/forgot-password');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  const email = await mail.waitForLatest(inbox, { timeout: 30000 });
  expect(email.magicLink).not.toBeNull();

  await page.goto(email.magicLink!);
  await page.fill('[name="password"]', 'NewPass123!');
  await page.click('[type="submit"]');

  await expect(page.getByText('Password updated')).toBeVisible();
});

Configuring Nodemailer for CI

The key is using a real SMTP provider in CI while keeping Ethereal for local development:

// lib/email.ts
const isCI = process.env.CI === 'true';

const transporter = isCI
  ? nodemailer.createTransport({
      // Real SMTP in CI — emails actually delivered
      host: process.env.SMTP_HOST,      // e.g. smtp.resend.com
      port: 587,
      auth: {
        user: process.env.SMTP_USER,    // e.g. resend
        pass: process.env.SMTP_PASS,    // e.g. your Resend API key
      },
    })
  : nodemailer.createTransport({
      // Ethereal locally — visual inspection only
      host: 'smtp.ethereal.email',
      port: 587,
      auth: {
        user: process.env.ETHEREAL_USER,
        pass: process.env.ETHEREAL_PASS,
      },
    });

Using Resend as the SMTP backend:

SMTP_HOST=smtp.resend.com
SMTP_PORT=587
SMTP_USER=resend
SMTP_PASS=re_your_api_key

Using SendGrid:

SMTP_HOST=smtp.sendgrid.net
SMTP_PORT=587
SMTP_USER=apikey
SMTP_PASS=SG.your_api_key

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          CI: true
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          SMTP_HOST: smtp.resend.com
          SMTP_PORT: 587
          SMTP_USER: resend
          SMTP_PASS: ${{ secrets.RESEND_API_KEY }}
          APP_URL: ${{ secrets.STAGING_URL }}

The full picture

	Ethereal (local)	Real SMTP (staging)	Real SMTP + ZeroDrop (CI)
Visual inspection	✅ preview URL	✅ real inbox	✅ automated
No real emails sent	✅	❌	❌
Automated in CI	❌	❌	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Use Ethereal locally for template inspection. Use a real SMTP provider + ZeroDrop in CI for full end-to-end coverage.

Why not use MailHog?

MailHog is the traditional alternative — a fake SMTP server that catches emails locally. The problems:

Requires a running Docker container in CI
Adds 15-30 seconds cold start time per CI run
Parallel tests share one inbox — race conditions when multiple tests send emails simultaneously
Unmaintained since 2020

ZeroDrop solves all three: no Docker, no cold start, and every test gets its own isolated inbox.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to E2E Test Postmark Email Workflows in Playwright

zerodrop — Thu, 18 Jun 2026 20:43:37 +0000

Postmark is known for fast, reliable transactional email delivery. But how do you test that your Postmark emails actually arrive, contain the right content, and work end-to-end in CI?

This guide covers the full testing progression — from local development to automated Playwright tests in GitHub Actions.

The app we're testing

A Next.js API route that sends a verification email via Postmark:

// app/api/auth/signup/route.ts
import { ServerClient } from 'postmark';

const client = new ServerClient(process.env.POSTMARK_API_TOKEN!);

export async function POST(req: Request) {
  const { email } = await req.json();

  const token = crypto.randomUUID();
  const verifyUrl = `${process.env.NEXT_PUBLIC_URL}/verify?token=${token}`;

  await client.sendEmail({
    From: 'noreply@yourapp.com',
    To: email,
    Subject: 'Verify your email',
    HtmlBody: `<p>Click <a href="${verifyUrl}">here</a> to verify your email.</p>`,
    MessageStream: 'outbound',
  });

  return Response.json({ success: true });
}

Stage 1 — Local development: Postmark test message stream

Postmark has a dedicated test message stream that accepts emails without delivering them. Change MessageStream from outbound to outbound with a test server token:

// Use Postmark's test API token for local development
const client = new ServerClient(
  process.env.NODE_ENV === 'development'
    ? 'POSTMARK_API_TEST' // Postmark's built-in test token
    : process.env.POSTMARK_API_TOKEN!
);

Postmark's POSTMARK_API_TEST token accepts all emails and returns a success response without delivering anything. You can inspect sent emails in your Postmark dashboard under the test server.

What it solves: Does my app call Postmark correctly? Is my email template valid?

What it doesn't solve: Automated testing. You can't read emails from Postmark's test server programmatically in a Playwright test.

Stage 2 — Staging: Postmark live token to a real inbox

Switch to your live Postmark server token for staging:

const client = new ServerClient(process.env.POSTMARK_API_TOKEN!);

Emails now go through Postmark's real delivery infrastructure. You can manually verify they arrive, links work, and the content is correct. Catches real issues like missing DKIM records or template rendering bugs.

What it solves: Does the email actually reach a real inbox end-to-end?

What it doesn't solve: Automation. You can't run this in CI without a real inbox your test can read.

Stage 3 — CI: Postmark live token + ZeroDrop

For automated Playwright tests in GitHub Actions:

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can sign up and verify email', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  // 2. Sign up — Postmark sends a real verification email to this inbox
  await page.goto('/signup');
  await page.fill('[data-testid="email"]', inbox);
  await page.click('[data-testid="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);

  // 5. Assert verified
  await expect(page).toHaveURL('/dashboard');
});

OTP flows

If your app sends a numeric OTP via Postmark:

await client.sendEmail({
  From: 'noreply@yourapp.com',
  To: email,
  Subject: 'Your verification code',
  HtmlBody: `<p>Your code is: <strong>${otp}</strong></p>`,
  MessageStream: 'outbound',
});

const email = await mail.waitForLatest(inbox, { timeout: 30000 });

// OTP auto-extracted at the edge — no regex needed
expect(email.otp).not.toBeNull();
await page.fill('[data-testid="otp"]', email.otp!);
await page.click('[data-testid="verify"]');

Using Postmark Templates

If you use Postmark's template system:

await client.sendEmailWithTemplate({
  From: 'noreply@yourapp.com',
  To: email,
  TemplateAlias: 'verify-email',
  TemplateModel: {
    verify_url: verifyUrl,
    product_name: 'YourApp',
  },
  MessageStream: 'outbound',
});

// ZeroDrop catches the fully rendered template output
const email = await mail.waitForLatest(inbox, { timeout: 30000 });
expect(email.magicLink).not.toBeNull();

This tests that your Postmark template renders correctly with real data — something the test token can't verify.

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          POSTMARK_API_TOKEN: ${{ secrets.POSTMARK_API_TOKEN }}
          NEXT_PUBLIC_URL: ${{ secrets.STAGING_URL }}

// Use CI inbox or generate locally
const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

The full picture

	Test token (local)	Live token (staging)	Live token + ZeroDrop (CI)
Validates API call	✅	✅	✅
No real emails sent	✅	❌	❌
Tests template rendering	❌	✅	✅
Automated in CI	❌	❌	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Use the test token during development, the live token for manual staging verification, and the live token + ZeroDrop for automated CI.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to E2E Test SendGrid Email Workflows in Playwright

zerodrop — Thu, 18 Jun 2026 20:37:33 +0000

SendGrid powers transactional email for millions of applications. But how do you test that your SendGrid emails actually arrive, contain the right content, and work end-to-end in CI?

This guide covers the full testing progression — from local development to automated Playwright tests in GitHub Actions.

The app we're testing

A Next.js API route that sends a verification email via SendGrid:

// app/api/auth/signup/route.ts
import sgMail from '@sendgrid/mail';

sgMail.setApiKey(process.env.SENDGRID_API_KEY!);

export async function POST(req: Request) {
  const { email } = await req.json();

  const token = crypto.randomUUID();
  const verifyUrl = `${process.env.NEXT_PUBLIC_URL}/verify?token=${token}`;

  await sgMail.send({
    from: 'noreply@yourapp.com',
    to: email,
    subject: 'Verify your email',
    html: `<p>Click <a href="${verifyUrl}">here</a> to verify your email.</p>`,
  });

  return Response.json({ success: true });
}

Stage 1 — Local development: SendGrid sandbox mode

SendGrid has a sandbox mode that intercepts emails without delivering them. Enable it by passing mail_settings in your API call:

await sgMail.send({
  from: 'noreply@yourapp.com',
  to: email,
  subject: 'Verify your email',
  html: `<p>Click <a href="${verifyUrl}">here</a> to verify.</p>`,
  mailSettings: {
    sandboxMode: {
      enable: process.env.NODE_ENV === 'development',
    },
  },
});

In sandbox mode, SendGrid processes the request and validates it but doesn't deliver the email. You can verify delivery in the SendGrid Activity Feed dashboard.

What it solves: Does my app call SendGrid correctly? Is my email template valid?

What it doesn't solve: Automated testing. You can't read emails from SendGrid's Activity Feed programmatically in a test.

Stage 2 — Staging: SendGrid live key to a real inbox

Switch sandbox mode off for staging:

mailSettings: {
  sandboxMode: {
    enable: false,
  },
},

Emails now go through real delivery. You can manually verify they arrive, links work, and nothing lands in spam. Catches real delivery issues like domain authentication problems.

What it solves: Does the email actually reach a real inbox end-to-end?

What it doesn't solve: Automation. You can't run this in CI without access to a real inbox your test can read.

Stage 3 — CI: SendGrid live key + ZeroDrop

For automated Playwright tests in GitHub Actions:

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can sign up and verify email', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  // 2. Sign up — SendGrid sends a real verification email to this inbox
  await page.goto('/signup');
  await page.fill('[data-testid="email"]', inbox);
  await page.click('[data-testid="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);

  // 5. Assert verified
  await expect(page).toHaveURL('/dashboard');
});

OTP flows

If your app sends a numeric OTP via SendGrid:

await sgMail.send({
  from: 'noreply@yourapp.com',
  to: email,
  subject: 'Your verification code',
  html: `<p>Your code is: <strong>${otp}</strong></p>`,
});

const email = await mail.waitForLatest(inbox, { timeout: 30000 });

// OTP auto-extracted at the edge — no regex needed
expect(email.otp).not.toBeNull();
await page.fill('[data-testid="otp"]', email.otp!);
await page.click('[data-testid="verify"]');

Using SendGrid Dynamic Templates

If you use SendGrid's Dynamic Templates, the flow is the same — ZeroDrop catches the rendered email:

await sgMail.send({
  from: 'noreply@yourapp.com',
  to: email,
  templateId: 'd-your-template-id',
  dynamicTemplateData: {
    verify_url: verifyUrl,
    username: 'Test User',
  },
});

// ZeroDrop catches the fully rendered template output
const email = await mail.waitForLatest(inbox, { timeout: 30000 });
expect(email.magicLink).not.toBeNull();

This tests that your Dynamic Template renders correctly and the link is valid — something sandbox mode can't verify.

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          SENDGRID_API_KEY: ${{ secrets.SENDGRID_API_KEY }}
          NEXT_PUBLIC_URL: ${{ secrets.STAGING_URL }}

// Use CI inbox or generate locally
const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

The full picture

	Sandbox mode (local)	Live key (staging)	Live key + ZeroDrop (CI)
Validates API call	✅	✅	✅
No real emails sent	✅	❌	❌
Tests template rendering	❌	✅	✅
Automated in CI	❌	❌	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Use sandbox mode during development, the live key for manual staging verification, and the live key + ZeroDrop for automated CI.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

Testing Password Reset Flows End-to-End in Next.js with Playwright

zerodrop — Thu, 18 Jun 2026 20:16:53 +0000

Password reset is one of the most critical flows in any application. It's also one of the most commonly untested.

The reason is always the same — the flow requires a real email. You click "Forgot password", an email arrives, you click the link, you reset. There's no way to test this without catching that email.

This guide shows how to test the complete password reset flow in a Next.js app using Playwright and ZeroDrop — end-to-end, in CI, without mocking.

The flow we're testing

User requests a password reset
App sends a reset email with a unique token link
User clicks the link
User sets a new password
User logs in with the new password

Every step needs to work. Most test suites only test step 4 and 5 by navigating directly to the reset URL with a hardcoded token. That's not a real test.

The Next.js API routes

// app/api/auth/forgot-password/route.ts
import { Resend } from 'resend';
import { db } from '@/lib/db';
import crypto from 'crypto';

const resend = new Resend(process.env.RESEND_API_KEY);

export async function POST(req: Request) {
  const { email } = await req.json();

  // Generate a secure reset token
  const token = crypto.randomBytes(32).toString('hex');
  const expires = new Date(Date.now() + 60 * 60 * 1000); // 1 hour

  // Store token in database
  await db.passwordResetToken.create({
    data: { email, token, expires }
  });

  const resetUrl = `${process.env.NEXT_PUBLIC_URL}/reset-password?token=${token}`;

  // Send reset email
  await resend.emails.send({
    from: 'noreply@yourapp.com',
    to: email,
    subject: 'Reset your password',
    html: `
      <p>You requested a password reset.</p>
      <p>Click <a href="${resetUrl}">here</a> to reset your password.</p>
      <p>This link expires in 1 hour.</p>
    `,
  });

  return Response.json({ success: true });
}

// app/api/auth/reset-password/route.ts
export async function POST(req: Request) {
  const { token, password } = await req.json();

  const resetToken = await db.passwordResetToken.findUnique({
    where: { token }
  });

  if (!resetToken || resetToken.expires < new Date()) {
    return Response.json({ error: 'Invalid or expired token' }, { status: 400 });
  }

  // Update password and delete token
  await db.user.update({
    where: { email: resetToken.email },
    data: { password: await hashPassword(password) }
  });

  await db.passwordResetToken.delete({ where: { token } });

  return Response.json({ success: true });
}

The Playwright test

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test.describe('Password reset flow', () => {
  test('user can reset password via email link', async ({ page }) => {
    // 1. Generate a disposable inbox
    const inbox = mail.generateInbox();

    // 2. Create a test user with this inbox
    // (assuming you have a signup flow or seed script)
    await page.goto('/signup');
    await page.fill('[data-testid="email"]', inbox);
    await page.fill('[data-testid="password"]', 'OriginalPassword123!');
    await page.click('[data-testid="submit"]');
    await expect(page).toHaveURL('/dashboard');

    // 3. Sign out
    await page.click('[data-testid="signout"]');
    await expect(page).toHaveURL('/login');

    // 4. Request password reset
    await page.goto('/forgot-password');
    await page.fill('[data-testid="email"]', inbox);
    await page.click('[data-testid="submit"]');

    await expect(page.getByText('Check your email')).toBeVisible();

    // 5. Catch the reset email — magic link auto-extracted
    const email = await mail.waitForLatest(inbox, { timeout: 30000 });

    expect(email.subject).toContain('Reset your password');
    expect(email.magicLink).not.toBeNull();

    // 6. Click the reset link
    await page.goto(email.magicLink!);
    await expect(page).toHaveURL(/reset-password/);

    // 7. Set new password
    await page.fill('[data-testid="password"]', 'NewPassword123!');
    await page.fill('[data-testid="confirm-password"]', 'NewPassword123!');
    await page.click('[data-testid="submit"]');

    await expect(page.getByText('Password updated')).toBeVisible();

    // 8. Login with new password
    await page.goto('/login');
    await page.fill('[data-testid="email"]', inbox);
    await page.fill('[data-testid="password"]', 'NewPassword123!');
    await page.click('[data-testid="submit"]');

    // 9. Assert logged in successfully
    await expect(page).toHaveURL('/dashboard');
  });

  test('expired reset link shows error', async ({ page }) => {
    const inbox = mail.generateInbox();

    // Request reset
    await page.goto('/forgot-password');
    await page.fill('[data-testid="email"]', inbox);
    await page.click('[data-testid="submit"]');

    const email = await mail.waitForLatest(inbox, { timeout: 30000 });

    // Tamper with the token to simulate expiry
    const expiredUrl = email.magicLink!.replace(/token=\w+/, 'token=expired_token');
    await page.goto(expiredUrl);

    await expect(page.getByText('Invalid or expired')).toBeVisible();
  });
});

Testing with NextAuth

If you're using NextAuth for authentication, the password reset flow is handled differently. Here's how to test it:

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('NextAuth email sign-in (magic link)', async ({ page }) => {
  const inbox = mail.generateInbox();

  // Request magic link sign-in
  await page.goto('/auth/signin');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  await expect(page.getByText('Check your email')).toBeVisible();

  // Catch the magic link email
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.magicLink).not.toBeNull();

  // Click the sign-in link
  await page.goto(email.magicLink!);

  // Should be signed in
  await expect(page).toHaveURL('/dashboard');
});

In GitHub Actions

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}
          NEXT_PUBLIC_URL: ${{ secrets.STAGING_URL }}
          DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}

// Use CI inbox or generate locally
const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

What you're actually testing

A complete password reset test with ZeroDrop verifies:

✅ Your API correctly generates a reset token
✅ Your email provider actually delivers the email
✅ The reset link contains a valid token
✅ The token correctly authenticates the reset
✅ The new password works for login
✅ The old password no longer works
✅ Expired tokens are rejected

That's the full security surface of your password reset flow — tested on every commit.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

From MailHog to Zero Infrastructure: Migrating Your CI Email Tests

zerodrop — Thu, 18 Jun 2026 17:03:01 +0000

MailHog was the right answer for a long time. A fake SMTP server, a web UI to inspect emails, zero dependencies beyond Docker. It worked.

Then it stopped being maintained. The last commit was in 2020. The Docker image hasn't been updated. The issues tab is a graveyard of unanswered questions.

If you're still running MailHog in your CI pipeline, this guide shows you how to migrate to ZeroDrop — no Docker, no SMTP server, no infrastructure to maintain.

What MailHog costs you in CI

Before migrating, it's worth being honest about what MailHog actually costs.

The Docker tax

Every MailHog setup in GitHub Actions looks like this:

services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - 1025:1025
      - 8025:8025

That service block spins up a Docker container on every CI run. It takes 15-30 seconds to pull the image on a cold runner. It takes another few seconds to start. For a pipeline that runs on every push, that's minutes of wasted CI time per week.

On GitHub Actions, you're billed by the minute. MailHog's startup time costs real money.

The parallel testing nightmare

MailHog runs as a single instance. All your tests share one inbox.

Run 10 parallel Playwright tests that all sign up with different email addresses, and you'll have 10 emails sitting in the same MailHog inbox. Your test needs to find its email among 9 others.

The typical workaround:

// Fragile — depends on subject line matching
const emails = await mailhog.messages();
const myEmail = emails.items.find(e => e.To[0].Mailbox === username);

This breaks when tests run fast enough that emails arrive out of order. It breaks when the subject line format changes. It breaks when two tests use similar usernames.

The real solution is inbox isolation — each test gets its own inbox that only receives its own emails. MailHog has no concept of this.

The maintenance vacuum

MailHog is unmaintained. When Node.js updates break something, there's no fix coming. When the Docker image has a security vulnerability, there's no patch. When you need a feature, there's nobody to ask.

Mailpit is the maintained fork — it's better than MailHog. But it still requires Docker in CI, still has the parallel testing problem, and still means infrastructure you're responsible for.

What the migration looks like

Here's a typical MailHog test:

// Before — MailHog
import { MailhogService } from './mailhog';

const mailhog = new MailhogService('http://localhost:8025');

test('email verification flow', async ({ page }) => {
  const username = `user_${Date.now()}`;
  const email = `${username}@example.com`;

  await page.goto('/signup');
  await page.fill('[name="email"]', email);
  await page.click('[type="submit"]');

  // Wait and poll MailHog
  await page.waitForTimeout(2000);
  const messages = await mailhog.getMessagesFor(email);
  expect(messages.length).toBeGreaterThan(0);

  // Parse OTP with regex — fragile
  const body = messages[0].Content.Body;
  const otp = body.match(/\b(\d{6})\b/)?.[0];
  expect(otp).toBeDefined();

  await page.fill('[name="otp"]', otp!);
  await page.click('[type="submit"]');
  await expect(page).toHaveURL('/dashboard');
});

Here's the same test after migration:

// After — ZeroDrop
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('email verification flow', async ({ page }) => {
  const inbox = mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  await page.goto('/signup');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  // SSE delivery — sub-second, no polling needed
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  // OTP auto-extracted — no regex
  expect(email.otp).not.toBeNull();

  await page.fill('[name="otp"]', email.otp!);
  await page.click('[type="submit"]');
  await expect(page).toHaveURL('/dashboard');
});

No Docker. No SMTP config. No regex. No shared inbox.

Step 1 — Remove MailHog from your stack

GitHub Actions — remove the service block:

# Remove this entire block
services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - 1025:1025
      - 8025:8025

Your app config — remove the SMTP override:

// Remove this from your test environment config
SMTP_HOST=localhost
SMTP_PORT=1025

Your app needs to send real emails now — use your transactional email provider (Resend, SendGrid, Postmark) with a live API key pointed at your staging environment.

Step 2 — Install zerodrop-client

npm install zerodrop-client

Step 3 — Generate the GitHub Actions inbox

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}

Step 4 — Update your tests

import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

// Use CI inbox or generate locally
const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

Parallel tests — zero configuration

With MailHog you had to work around the shared inbox. With ZeroDrop, parallel isolation is the default.

// Each test generates its own inbox — no shared state
test.describe.parallel('Auth flows', () => {
  test('signup verification', async ({ page }) => {
    const inbox = mail.generateInbox(); // unique per test
    // ...
  });

  test('password reset', async ({ page }) => {
    const inbox = mail.generateInbox(); // different inbox
    // ...
  });
});

50 parallel tests. 50 inboxes. Zero collisions.

The before and after

	MailHog	ZeroDrop
Docker required	✅ always	❌ never
CI startup time	15-30s	0s
Parallel isolation	❌ shared inbox	✅ per-test inbox
OTP extraction	❌ regex in tests	✅ auto-extracted
Maintained	❌ last commit 2020	✅ active
Real email delivery	❌ fake SMTP	✅ real infrastructure
Cost	Docker compute	Free tier

What you're actually testing now

The biggest difference isn't the developer experience — it's what you're testing.

MailHog tests that your app calls an SMTP server. ZeroDrop tests that your app sends a real email that a real user could receive.

If your email provider goes down, MailHog passes. If your email template has a broken link, MailHog passes. If your DKIM is misconfigured, MailHog passes.

ZeroDrop fails on all of these. Which is the point.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to E2E Test Resend Email Workflows in Playwright

zerodrop — Wed, 17 Jun 2026 21:02:15 +0000

Resend is the standard for transactional email in modern Next.js and React apps. But how do you test that your Resend emails actually arrive, contain the right verification link, and work end-to-end in CI?

This guide covers the full testing progression — from local development to automated Playwright tests in GitHub Actions.

The app we're testing

A Next.js API route that sends a verification email via Resend:

// app/api/auth/signup/route.ts
import { Resend } from 'resend';

const resend = new Resend(process.env.RESEND_API_KEY);

export async function POST(req: Request) {
  const { email } = await req.json();

  const token = crypto.randomUUID();
  const verifyUrl = `${process.env.NEXT_PUBLIC_URL}/verify?token=${token}`;

  await resend.emails.send({
    from: 'hello@yourapp.com',
    to: email,
    subject: 'Verify your email',
    html: `<p>Click <a href="${verifyUrl}">here</a> to verify your email.</p>`,
  });

  return Response.json({ success: true });
}

Stage 1 — Local development: Resend test API key

Resend's re_test_ API keys capture every email in their dashboard without sending to real inboxes. No email leaves Resend's servers.

RESEND_API_KEY=re_test_xxx npm run dev

Sign up in your browser, check the Resend dashboard — the email appears with full HTML preview. Perfect for template development.

What it solves: Does my app call Resend correctly? Does the template render?

What it doesn't solve: Automated testing. Your Playwright test can't read Resend's dashboard.

Stage 2 — Staging: Resend live key to a real inbox

Switch to a live key for staging environment testing:

RESEND_API_KEY=re_live_xxx

Emails now go through real delivery infrastructure. You can manually verify that emails arrive, links work, and nothing lands in spam. Catches real delivery issues like domain configuration problems.

What it solves: Does the email actually reach a real inbox end-to-end?

What it doesn't solve: Automation. You can't run this in CI without access to a real inbox your test can read.

Stage 3 — CI: Resend live key + ZeroDrop

For automated Playwright tests in GitHub Actions, you need a disposable inbox your test can read programmatically:

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can sign up and verify email', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  // 2. Sign up — Resend sends a real verification email to this inbox
  await page.goto('/signup');
  await page.fill('[data-testid="email"]', inbox);
  await page.click('[data-testid="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);

  // 5. Assert verified
  await expect(page).toHaveURL('/dashboard');
  await expect(page.getByText('Email verified')).toBeVisible();
});

Resend's live infrastructure delivers the email. ZeroDrop catches it at Cloudflare's edge. The test reads it automatically.

OTP flows

If your app sends a numeric OTP via Resend:

await resend.emails.send({
  from: 'hello@yourapp.com',
  to: email,
  subject: 'Your verification code',
  html: `<p>Your code is: <strong>${otp}</strong></p>`,
});

const email = await mail.waitForLatest(inbox, { timeout: 30000 });

// OTP auto-extracted — no regex needed
expect(email.otp).not.toBeNull();
await page.fill('[data-testid="otp"]', email.otp!);
await page.click('[data-testid="verify"]');

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}
          NEXT_PUBLIC_URL: ${{ secrets.STAGING_URL }}

// Use CI inbox or generate locally
const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

The full picture

	Test key (local)	Live key (staging)	Live key + ZeroDrop (CI)
Visual inspection	✅ dashboard	✅ real inbox	✅ automated
No real emails sent	✅	❌	❌
Automated in CI	❌	❌	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Use the test key during development, the live key for manual staging verification, and the live key + ZeroDrop for automated CI.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

Why Mocking Email in Tests is Lying to Yourself

zerodrop — Wed, 17 Jun 2026 20:54:34 +0000

There is a category of test that feels productive, passes consistently, and catches absolutely nothing. It lives in most codebases. It gets written during sprints, committed without question, and reviewed without comment. Nobody talks about it because it looks fine.

It is the mocked email test.

What it looks like

jest.mock('../lib/email', () => ({
  sendVerificationEmail: jest.fn().mockResolvedValue({ id: 'mock-id' })
}));

test('sends verification email on signup', async () => {
  await signupUser({ email: 'test@example.com' });
  expect(sendVerificationEmail).toHaveBeenCalledWith('test@example.com');
});

This test passes. It will always pass. It will pass when your SMTP credentials expire. It will pass when your email template has a broken link. It will pass when your transactional email provider changes their API. It will pass when the verification token generation has a bug that makes every link invalid.

You have not tested that the email works. You have tested that your code calls a function.

The lie

Mocking email is a form of wishful testing. You mock the thing you don't want to deal with — the network, the third-party service, the timing — and you replace it with a version that always does exactly what you tell it to do.

The mock never fails. The mock never bounces. The mock never ends up in spam. The mock never has a broken template. The mock is not your email system. The mock is a ghost.

When a real user signs up and the verification email lands in spam because your SPF record is misconfigured — your mocked test was passing the entire time. When your password reset link expires in 10 minutes instead of 24 hours because someone changed a constant — your mocked test was passing. When your email provider silently rate-limits your account and stops delivering — your mocked test was passing.

The test suite is green. The product is broken.

Why developers do it anyway

Because testing email is genuinely hard. The alternatives have historically been painful:

MailHog — run a fake SMTP server locally. Works until it doesn't, requires Docker in CI, abandoned since 2020.

Shared test inbox — use a real Gmail account for tests. Race conditions in parallel runs, manual cleanup required, leaks real credentials into CI.

Hardcoded bypass codes — add if (process.env.NODE_ENV === 'test') skip email. You've just made your test environment behave differently from production. Congratulations.

Skip it entirely — "we'll test email manually in staging." Manual testing doesn't run on every commit.

Every option requires either accepting the lie (mocking) or accepting the pain (infrastructure). So developers accept the lie.

What testing email actually requires

A real email test needs three things:

A real inbox — not a mock, an actual email address that can receive mail
Isolation — each test run gets its own inbox so parallel tests don't collide
Automation — the test can read the inbox programmatically without human intervention

When you have all three, your test looks like this:

test('user can sign up and verify email', async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto('/signup');
  await page.fill('[data-testid="email"]', inbox);
  await page.click('[data-testid="submit"]');

  // Real email, caught at the edge, OTP auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  await page.goto(email.magicLink!);
  await expect(page).toHaveURL('/dashboard');
});

This test fails when:

Your email provider is down
Your SMTP credentials are invalid
Your email template doesn't render the verification link
Your token generation has a bug
Your email ends up in spam filtering

These are exactly the things you need to know about.

The argument for mocking

There is a real argument for mocking: unit tests should be fast, isolated, and deterministic. Email delivery is slow, external, and non-deterministic. Unit tests that hit real email infrastructure are slow and flaky.

This argument is correct. And it is a reason to mock email in unit tests.

It is not a reason to mock email in integration tests or E2E tests.

The question is not "should we ever mock email?" The question is "what are we actually trying to verify?"

If you're testing that your signup controller calls the email service — mock it. That's a unit test.

If you're testing that a user can sign up, receive a verification email, click the link, and land on the dashboard — that is an E2E test. Mock nothing. Use a real inbox.

The cost of the lie

Every mocked email test is a gap in your coverage. Not a small gap — a gap in the exact flow that new users experience first. Signup, verification, password reset — these are the first things a user does. They are also the first things that break.

The production incidents that come from untested email flows are not subtle. They are "users can't sign up" incidents. They are "nobody told us the verification emails were going to spam for three days" incidents.

A mocked test suite would have passed through all of them.

The alternative is not that hard anymore

Disposable email APIs have made real inbox testing in CI straightforward. No Docker. No shared credentials. No cleanup.

npm install zerodrop-client

import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();
const inbox = mail.generateInbox(); // instant, no network request

The inbox exists. It can receive real email. It expires in 30 minutes. It works in parallel CI runs. OTPs are extracted automatically — no regex.

There is no longer a good reason to mock email in E2E tests. The pain that made mocking reasonable is gone.

Stop testing that you call the function. Start testing that the email arrives.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to E2E Test SendPigeon Email Workflows in Playwright

zerodrop — Tue, 16 Jun 2026 22:04:33 +0000

When you integrate SendPigeon into your app, you get three stages of email testing. Each stage solves a different problem. This guide walks through all three — and shows how to combine SendPigeon with ZeroDrop for full end-to-end coverage in CI.

The app we're testing

A Next.js signup flow that sends a verification email via SendPigeon:

// app/api/auth/signup/route.ts
import { SendPigeon } from 'sendpigeon';

const pigeon = new SendPigeon(process.env.SENDPIGEON_API_KEY!);

export async function POST(req: Request) {
  const { email } = await req.json();

  const token = crypto.randomUUID();
  const verifyUrl = `${process.env.NEXT_PUBLIC_URL}/verify?token=${token}`;

  await pigeon.send({
    from: 'hello@yourapp.com',
    to: email,
    subject: 'Verify your email',
    html: `
      <p>Welcome! Click below to verify your email address.</p>
      <a href="${verifyUrl}">Verify email</a>
    `,
  });

  return Response.json({ success: true });
}

Simple. Now how do you test it at each stage?

Stage 1 — Local development: SendPigeon test key

SendPigeon's sp_test_ API keys capture every email in their dashboard without sending anything to real inboxes. Zero config needed.

SENDPIGEON_API_KEY=sp_test_xxx npm run dev

Sign up in your browser, check the SendPigeon dashboard — the email is there. Subject, HTML, links, everything. This is perfect for visually inspecting your email templates during development.

What it solves: Am I calling SendPigeon correctly? Does my email template look right?

What it doesn't solve: Automated testing. You can't write a Playwright test that reads emails from SendPigeon's dashboard.

Stage 2 — Staging: SendPigeon live key to a real inbox

When you're testing against a staging environment, switch to a live key:

SENDPIGEON_API_KEY=sp_live_xxx

Now emails go to real inboxes. You can test the full flow manually — sign up with your own email, check Gmail, click the link. This catches real delivery issues like spam filtering, DKIM failures, or broken links.

What it solves: Does the email actually reach a real inbox? Does the verification link work end to end?

What it doesn't solve: Automation. You can't run this in CI because the test would need to access your personal Gmail — and parallel test runs would collide on the same inbox.

Stage 3 — CI: SendPigeon live key + ZeroDrop

For automated Playwright tests in GitHub Actions, you need:

SendPigeon live key — so real emails are sent through actual delivery infrastructure
ZeroDrop — to catch those emails in an isolated, disposable inbox your test can read

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can sign up and verify email', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  // 2. Sign up — SendPigeon sends a real verification email to this inbox
  await page.goto('/signup');
  await page.fill('[data-testid="email"]', inbox);
  await page.click('[data-testid="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted, no regex needed
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);

  // 5. Assert verified
  await expect(page).toHaveURL('/dashboard');
  await expect(page.getByText('Email verified')).toBeVisible();
});

This tests the real path — SendPigeon's live infrastructure delivers the email, ZeroDrop catches it at Cloudflare's edge, the test reads it automatically.

OTP flows

If your app sends a numeric OTP instead of a magic link:

await pigeon.send({
  from: 'hello@yourapp.com',
  to: email,
  subject: 'Your verification code',
  html: `<p>Your code is: <strong>${otp}</strong></p>`,
});

const email = await mail.waitForLatest(inbox, { timeout: 30000 });

// OTP auto-extracted at the edge — no regex needed
expect(email.otp).not.toBeNull();
await page.fill('[data-testid="otp"]', email.otp!);
await page.click('[data-testid="verify"]');

ZeroDrop extracts 4-8 digit OTP codes automatically before the email reaches your test.

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          SENDPIGEON_API_KEY: ${{ secrets.SENDPIGEON_API_KEY }}
          NEXT_PUBLIC_URL: ${{ secrets.STAGING_URL }}

// Use CI inbox or generate locally
const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

Each CI run gets a fresh isolated inbox. Parallel matrix builds get separate inboxes — no cross-test contamination.

The full picture

	Test key (local)	Live key (staging)	Live key + ZeroDrop (CI)
Visual inspection	✅ dashboard	✅ real inbox	✅ automated
No real emails sent	✅	❌	❌
Automated in CI	❌	❌	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Each stage has a purpose. Use the test key during development, the live key for manual staging verification, and the live key + ZeroDrop for automated CI.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm