Designing a Contact Email Pipeline

Introduction

Sending emails from a contact form looks simple at first. The API receives a request, calls Nodemailer, and sends the message. For small demos, this works. In production, this direct approach can quickly become slow, unreliable, and difficult to debug.

Email handling should be treated as a small production pipeline. It needs validation, abuse protection, queueing, asynchronous processing, retries, logging, and delivery tracking. This keeps the user-facing request fast while making the email system more reliable.

A strong email system is not only about sending messages. It is about making sure valid requests are accepted, spam is controlled, delivery failures are visible, and important communication does not silently disappear.

The Problem

A common contact form implementation sends emails directly inside the API request. This is easy to write, but it tightly couples the user response to the email provider. If the provider is slow, unavailable, or rate-limited, the user request suffers immediately.

await transporter.sendMail(mailOptions);

This looks clean, but it blocks the request and gives the API very little room to retry, recover, monitor, or inspect delivery problems.

The challenge is to make email delivery reliable without slowing down the user-facing API or making the contact form feel complicated.

System Design / Approach

The better approach is to design email handling as a pipeline. The API validates the request, protects against abuse, stores the submission, adds a job to a queue, and returns quickly. A worker then sends the email asynchronously with retry and logging support.

Contact Form Submit
    ↓
Input Validation
    ↓
Rate Limit and Spam Check
    ↓
Store Submission
    ↓
Add Email Job to Queue
    ↓
Worker Sends Email
    ↓
Retry on Failure
    ↓
Log Delivery Status
    ↓
Manual Review if Needed

Implementation

Step 1: Configure Nodemailer Safely

Email credentials should stay on the server. The transporter should be created from environment variables and reused by the email service.

import nodemailer from "nodemailer";

export const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: Number(process.env.SMTP_PORT ?? 587),
  secure: false,
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASSWORD,
  },
});

Server-side transport configuration keeps credentials out of the client bundle and makes provider changes easier later.

Step 2: Define a Validation Schema

Contact form data should be validated before entering the email pipeline. A schema keeps rules explicit, reusable, and easier to maintain.

import { z } from "zod";

export const contactSchema = z.object({
  name: z.string().min(2).max(80),
  email: z.string().email(),
  subject: z.string().min(3).max(120),
  message: z.string().min(10).max(2000),
});

Validation prevents malformed, unsafe, or low-quality input from reaching the email service.

Step 3: Validate Requests in the API

The API should parse the request, validate the payload, and return clear field-level errors when the input is invalid.

export async function POST(request: Request) {
  const body = await request.json();
  const result = contactSchema.safeParse(body);

  if (!result.success) {
    return Response.json(
      {
        success: false,
        error: {
          code: "VALIDATION_ERROR",
          fields: result.error.flatten().fieldErrors,
        },
      },
      { status: 400 }
    );
  }

  return submitContactRequest(result.data);
}

Backend validation protects the system even when frontend validation is bypassed.

Step 4: Add Rate Limiting

Public contact forms are easy targets for spam and abuse. Rate limiting helps prevent repeated submissions from the same source.

if (requestCount > limit) {
  return Response.json(
    {
      success: false,
      error: {
        code: "RATE_LIMITED",
        message: "Too many messages. Please try again later.",
      },
    },
    { status: 429 }
  );
}

Rate limiting protects both the application and the email provider from spam traffic.

Step 5: Store the Contact Submission

Storing the request before sending gives the system a record of what happened. This helps with debugging, retries, analytics, and manual follow-up.

const submission = await db.contactSubmission.create({
  data: {
    name: input.name,
    email: input.email,
    subject: input.subject,
    message: input.message,
    status: "queued",
  },
});

Persisting submissions prevents important contact requests from disappearing silently.

Step 6: Add the Email Job to a Queue

Instead of sending email directly inside the API route, add a job to a queue. This keeps the API fast and lets a worker handle delivery independently.

await emailQueue.add(
  "send-contact-email",
  {
    submissionId: submission.id,
  },
  {
    attempts: 3,
    backoff: {
      type: "exponential",
      delay: 5000,
    },
  }
);

Queueing makes email delivery retryable, observable, and independent from the user request.

Step 7: Return a Fast User Response

The user does not need to wait for the email provider. After validation, storage, and queueing, the API can return a fast response saying the message was received.

return Response.json(
  {
    success: true,
    message: "Message received. I will get back to you soon.",
    submissionId: submission.id,
  },
  { status: 202 }
);

A fast response improves user experience while the system continues processing in the background.

Step 8: Process Email Jobs in a Worker

The worker reads queued jobs, loads the stored submission, sends the email, and updates the delivery status.

emailWorker.process(async (job) => {
  const submission = await db.contactSubmission.findUnique({
    where: {
      id: job.data.submissionId,
    },
  });

  if (!submission) {
    throw new Error("Submission not found");
  }

  await sendContactEmail(submission);

  await db.contactSubmission.update({
    where: {
      id: submission.id,
    },
    data: {
      status: "sent",
      sentAt: new Date(),
    },
  });
});

Workers isolate email delivery from the API layer and make processing easier to scale.

Step 9: Send Email Through a Dedicated Service

Email formatting and delivery should live in a dedicated service. This keeps templates, recipients, reply-to headers, and provider logic away from API routes.

export async function sendContactEmail(submission: ContactSubmission) {
  return transporter.sendMail({
    from: process.env.MAIL_FROM,
    to: process.env.CONTACT_RECEIVER_EMAIL,
    replyTo: submission.email,
    subject: `New contact message: ${submission.subject}`,
    text: `
Name: ${submission.name}
Email: ${submission.email}

${submission.message}
    `,
  });
}

A dedicated email service keeps delivery logic reusable, testable, and easier to change.

Step 10: Handle Failed Deliveries

Email failures should be logged and tracked. After retries are exhausted, the submission should be marked as failed for later inspection.

emailWorker.on("failed", async (job, error) => {
  await db.contactSubmission.update({
    where: {
      id: job.data.submissionId,
    },
    data: {
      status: "failed",
      failureReason: error.message,
      failedAt: new Date(),
    },
  });
});

Failure tracking makes delivery problems visible instead of silently losing messages.

Step 11: Prevent Duplicate Submissions

Users may double click, refresh, or retry during slow network conditions. Idempotency helps prevent duplicate contact records and repeated emails.

const existing = await db.contactSubmission.findUnique({
  where: {
    idempotencyKey,
  },
});

if (existing) {
  return existing;
}

Idempotency protects the system from repeated user actions and network retries.

Step 12: Add Delivery Monitoring

The system should track queued, sent, failed, and retried emails. These states help developers understand whether the pipeline is healthy.

const stats = await db.contactSubmission.groupBy({
  by: ["status"],
  _count: {
    status: true,
  },
});

Delivery monitoring helps detect provider issues, queue failures, and unexpected spam spikes.

Trade-offs

Real-World Impact

What I Learned

• Email sending should not block user-facing API responses.
• Validation protects the email pipeline from bad input and spam payloads.
• Queues make delivery retryable, observable, and easier to scale.
• Stored submissions create a useful audit trail for debugging and follow-up.
• Rate limiting is important because contact forms are public endpoints.
• Idempotency prevents duplicate emails caused by retries or double clicks.
• Monitoring delivery status makes production email issues easier to detect.

Conclusion

Email handling in production is more than calling Nodemailer from an API route. It needs validation, queueing, retries, delivery tracking, and abuse protection.

A strong email pipeline keeps the user-facing request fast while making delivery reliable through workers, stored submissions, retry policies, and failure monitoring.

The key lesson is simple: contact form email should be treated like a small production system. The more visible and decoupled the pipeline is, the more reliable communication becomes.