{"id":408,"date":"2026-09-16T01:21:00","date_gmt":"2026-09-16T06:51:00","guid":{"rendered":"https:\/\/photonconsole.com\/blog\/?p=408"},"modified":"2026-09-16T07:51:30","modified_gmt":"2026-09-16T13:21:30","slug":"sending-email-from-next-js-server-actions-api-routes-and-edge-limits","status":"publish","type":"post","link":"https:\/\/photonconsole.com\/blog\/sending-email-from-next-js-server-actions-api-routes-and-edge-limits\/","title":{"rendered":"Sending Email from Next.js: Server Actions, API Routes and Edge Limits"},"content":{"rendered":"\n

You add Nodemailer to a Next.js project, wire it into a contact form, and the build fails with a module resolution error about net<\/code> or tls<\/code>. Or it builds fine, deploys, and every send times out. Or worse, it works \u2014 and a security scan later shows your SMTP password sitting in the browser bundle.<\/p>\n\n\n\n

Next.js makes email harder than a traditional Node server because code can run in three different places: the browser, a Node.js serverless function, or the Edge runtime. Only one of those can open an SMTP connection.<\/p>\n\n\n\n

This guide covers where email code belongs in a Next.js app, how to configure the runtime correctly, and how to avoid the credential leak that catches a surprising number of projects.<\/p>\n\n\n\n

Quick Answer: How Do You Send Email in Next.js?<\/h2>\n\n\n\n

Send from a Route Handler or Server Action running on the Node.js runtime, never from a client component:<\/p>\n\n\n\n

\/\/ app\/api\/send\/route.ts\nimport nodemailer from 'nodemailer';\nimport { NextResponse } from 'next\/server';\n\nexport const runtime = 'nodejs';   \/\/ required \u2014 Edge cannot open SMTP\n\nconst transporter = nodemailer.createTransport({\n  host: process.env.SMTP_HOST,\n  port: Number(process.env.SMTP_PORT),\n  secure: false,\n  auth: {\n    user: process.env.SMTP_USER,\n    pass: process.env.SMTP_PASS,\n  },\n});\n\nexport async function POST(request: Request) {\n  const { email, message } = await request.json();\n\n  await transporter.sendMail({\n    from: process.env.MAIL_FROM,\n    to: 'you@yourdomain.com',\n    replyTo: email,\n    subject: 'New contact form submission',\n    text: message,\n  });\n\n  return NextResponse.json({ ok: true });\n}<\/code><\/pre>\n\n\n\n
Two things decide whether this works: the runtime must be nodejs<\/code>, and the credentials must never carry the NEXT_PUBLIC_<\/code> prefix. An authenticated relay such as PhotonConsole<\/a> handles the delivery side once the code is in the right place.<\/p>\n\n\n\n
Why You Cannot Send Email from the Browser<\/h2>\n\n\n\n
SMTP is a raw TCP protocol. Browsers do not permit raw TCP connections \u2014 they speak HTTP<\/a> and WebSockets only. There is no browser API that can open an SMTP session, and no library can work around that.<\/p>\n\n\n\n
This is a security feature rather than a limitation. If a browser could send SMTP, your mail credentials would have to be present in code the user can read, which means anyone could extract them and send mail as your domain.<\/p>\n\n\n\n
So every email path in Next.js has to terminate on the server. The question is only which server context you use.<\/p>\n\n\n\n
The Three Places Code Runs in Next.js<\/h2>\n\n\n\n
\"Diagram
Only the Node.js runtime can open an SMTP connection. The browser and Edge runtime cannot.<\/figcaption><\/figure>\n\n\n\n
Understanding this table prevents most Next.js email problems.<\/p>\n\n\n\n
Context<\/th>Can open SMTP?<\/th>Use for email?<\/th><\/tr><\/thead>
Client component (browser)<\/td>No \u2014 no raw TCP<\/td>Never. Credentials would be exposed<\/td><\/tr>
Edge runtime<\/td>No \u2014 no Node net<\/code> or tls<\/code> modules<\/td>Only via an HTTP email API<\/td><\/tr>
Node.js runtime<\/td>Yes<\/td>Yes \u2014 this is where SMTP belongs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The Next.js documentation<\/a> covers runtime selection in detail. The practical rule is simple: anything touching Nodemailer needs export const runtime = 'nodejs'<\/code>.<\/p>\n\n\n\n
Why Next.js Email Fails<\/h2>\n\n\n\n
Most failures come from the runtime, the environment variables, or the serverless execution model rather than from the mail code itself.<\/p>\n\n\n\n
1. The Route Is Running on the Edge<\/h3>\n\n\n\n
Edge functions run in a restricted JavaScript environment without Node’s net<\/code><\/a> and tls<\/code> modules. Nodemailer<\/a> depends on both. You will see build errors about unresolved modules, or runtime errors about missing Node APIs.<\/p>\n\n\n\n
Setting export const runtime = 'nodejs'<\/code> in the route file fixes this.<\/p>\n\n\n\n
2. Credentials Are Prefixed with NEXT_PUBLIC_<\/h3>\n\n\n\n
Any environment variable starting with NEXT_PUBLIC_<\/code> is inlined into the JavaScript bundle sent to the browser. Naming your SMTP password NEXT_PUBLIC_SMTP_PASS<\/code> publishes it to every visitor.<\/p>\n\n\n\n
This happens because developers hit an “undefined variable” error in a client component and add the prefix to make the error go away. It does make the error go away. It also leaks the credential.<\/p>\n\n\n\n
3. Nodemailer Is Imported into a Client Component<\/h3>\n\n\n\n
Importing a server-only library in a component that runs in the browser produces bundling errors. Keep mail code in Route Handlers, Server Actions, or files marked 'use server'<\/code>.<\/p>\n\n\n\n
4. The Function Times Out Before the Send Completes<\/h3>\n\n\n\n
Serverless functions have execution time limits that vary by platform and plan. An SMTP handshake on a cold start can take several seconds, and a slow mail server can push past the limit. The request fails with a platform timeout rather than a mail error, which makes it look like a Next.js fault.<\/p>\n\n\n\n
5. No Authentication Records on the Sending Domain<\/h3>\n\n\n\n
Without SPF and DKIM, receiving servers cannot verify your application is authorised to send as your domain, in line with Google’s sender guidelines<\/a>. Our guide to SPF, DKIM and DMARC<\/a> covers the records, and the free email deliverability checker<\/a> shows what your domain publishes today.<\/p>\n\n\n\n
Common Mistake<\/p>\n\n\n\n
Adding NEXT_PUBLIC_<\/code> to an SMTP variable to silence an undefined error. Everything with that prefix is compiled into the browser bundle and is readable by anyone who opens developer tools. If you have ever deployed with NEXT_PUBLIC_SMTP_PASS<\/code> or similar, treat that credential as compromised, rotate it, and move the send into a Route Handler or Server Action where server-only variables are available.<\/p>\n\n\n\n
Quick Fix<\/p>\n\n\n\n
Module Not Found: net, tls or dns<\/p>\n\n\n\n