Free SMTP Relay: Send Transactional Email Without Running a Mail Server

A free SMTP relay is the practical way to send password resets, order receipts, contact-form notifications, and product alerts without trying to run a mail server yourself. The relay accepts a message from your application over authenticated SMTP, then handles the delivery infrastructure—but the free tier only works well when your volume, DNS setup, and message type fit its limits.

What a free SMTP relay actually does

SMTP stands for Simple Mail Transfer Protocol, the standard protocol used to move email between sending systems and receiving mail servers. An SMTP relay is a provider-hosted SMTP endpoint: your website, application, CRM, printer, or automation tool authenticates to that endpoint, submits a message, and the provider relays it toward the recipient’s mailbox provider. (nodemailer.com)

This is different from hosting a mailbox. A mailbox service gives a person an inbox such as you@example.com; an SMTP relay is primarily the outbound delivery path used by software. It is also different from a marketing platform: although some platforms support newsletters, the most reliable use for a free relay is usually transactional email triggered by a user action—for example, a receipt after payment or a verification link after sign-up. Brevo, for example, describes its SMTP relay as a way to send transaction-triggered messages from a website, email client, or automation. (help.brevo.com)

A relay does not make email automatically land in the inbox. It gives you a managed sending path. Your domain authentication, sending behavior, recipient consent, content, and the provider’s policies still determine whether a message is accepted and where it appears.

What you need before you start

For a production setup, have these four things ready:

1. A domain you control, such as example.com. Do not build customer-facing sending around an address on a free mailbox domain.
2. Access to the domain’s DNS settings so you can publish the exact SPF, DKIM, and DMARC records your relay requires.
3. An application or tool with SMTP settings, including host, port, username, password, and TLS mode.
4. A real transactional use case with recipients who expect the message—such as an account owner, customer, or opted-in subscriber.

If you only need to test code locally, a sandbox mail-catcher can be easier. If you need to deliver real messages to real recipients, use a provider relay and authenticate a domain before treating the setup as complete.

Is a free SMTP relay really free?

Usually, “free” means a permanent low-volume allowance, not unlimited production email. The limits are commonly measured by day, month, or both; every individual recipient may count as one email. A free plan can therefore work well for a new SaaS product or a small site, but it can fail quickly if one event sends to a large list.

Here are examples of provider-specific free allowances. These are vendor plan details, not universal SMTP limits, so confirm them in the provider dashboard before depending on them:

The headline number is not the only number that matters. If an application sends a weekly digest to 500 people, a 300-per-day plan cannot deliver it all immediately. If an alerting system sometimes sends a burst of 150 messages in an hour, an hourly throttling rule can matter even when the monthly quota looks generous.

Free plans also have operational boundaries. Providers can require sender or account verification, restrict unapproved traffic, queue messages after you hit a limit, or offer less reporting and support than paid plans. Treat a free tier as a useful starting capacity, not an entitlement to send bulk mail forever.

When a free plan becomes the constraint, compare the next paid tier based on the actual number of recipients you send to—not merely the number of campaigns or application events. That is the number that determines your real transactional email costs.

How to choose the right free SMTP relay

Choose based on the sending pattern first, then developer experience. “Best” is not a meaningful universal answer: an ecommerce store sending order receipts, a developer shipping a beta app, and a WordPress contact form have very different needs.

Pick based on volume and burst behavior

Use this decision guide:

• Up to 100 transactional recipients per day: A developer-focused option with a daily cap, such as Resend’s free transactional allowance, can be a fit when you value API tooling as well as SMTP compatibility. (resend.com)
• Up to 200 recipients per day, but under 1,000 per month: SMTP2GO’s free tier is shaped for low-volume use, but verify the sender domain to remove its stated hourly restriction. (smtp2go.com)
• Up to 300 recipients per day: Brevo’s free SMTP offering is a straightforward option for a small application, automation, or site, provided your account is approved for sending. (brevo.com)
• Unpredictable traffic, bulk sends, or business-critical notifications: Plan for a paid provider before launch. A password-reset delay, an invoice queue, or a missed security alert is usually more expensive than the sending plan.

Confirm these settings before committing

A relay should give you all of the following:

• SMTP credentials that are separate from your main account password.
• TLS support and a documented submission port.
• Domain authentication instructions and a domain-verification status page.
• Event logs or webhooks for delivered, bounced, deferred, and rejected messages.
• A way to suppress hard bounces and complaints automatically.
• A documented route for handling quota limits and rejected messages.

SMTP is portable: most providers support it even if they prefer an HTTP email API. That makes SMTP valuable when you need to connect older software, CMS plugins, or a library that already expects an SMTP host and credentials. APIs can provide richer provider-specific capabilities, but SMTP avoids tying every integration to one vendor’s SDK. (nodemailer.com)

Do not use a personal Gmail account as your application relay

Many guides suggest smtp.gmail.com because Gmail supports standard SMTP and TLS, including port 465 for SSL and port 587 for TLS/STARTTLS. That makes Gmail useful for a person configuring a mail client, but it is not the same thing as a purpose-built free SMTP relay for an application. (developers.google.com)

The operational issue is authentication and ownership. Google documents OAuth 2.0 support for Gmail SMTP, and applications using a person’s mailbox credentials inherit the fragility of that mailbox relationship: password changes, security policies, account suspension, consent flows, and sender identity complications. (developers.google.com)

Use a transactional-email provider instead when your product sends mail on behalf of a domain. You gain a clearer separation between human mailbox access and application credentials, a sending log, domain-level verification, and a more intentional path to scaling.

Authenticate your domain before sending real mail

The most common free SMTP relay mistake is getting a message accepted by the provider and assuming the setup is complete. It is not. A production sender should authenticate the domain used in the visible From: address.

Authentication is implemented through DNS records. Your relay provider will generate the exact hostnames and values for its service; copy those values precisely. Do not substitute record values from a blog post, because each provider can use different selectors, return paths, and verification tokens.

SPF: authorize mail sources

SPF is a TXT record that tells receiving servers which infrastructure is authorized to send mail for a domain. Google describes SPF as helping prevent outgoing email from being marked as spam and instructs administrators to publish it as a DNS TXT record. (support.google.com)

A simplified SPF record may look like this:

Type: TXT
Host: @
Value: v=spf1 include:provider-example.invalid -all

The include value above is intentionally illustrative. Use the exact include mechanism supplied by your relay. Also, publish one SPF record per domain: if you already use Google Workspace, Microsoft 365, another relay, or a help desk, combine the authorized mechanisms into one record rather than creating multiple independent v=spf1 TXT records.

DKIM: sign each message

DKIM adds a cryptographic signature to outgoing mail. The relay keeps the private signing key, while you publish the matching public key in DNS. Google’s DKIM guidance explains that the public key is added to DNS after it is generated. (support.google.com)

A provider-generated DKIM record commonly resembles this shape:

Type: CNAME or TXT
Host: selector1._domainkey
Value: provider-generated-value

Do not invent the selector or value. Add the records the dashboard presents, wait until the provider reports verification, and keep the records in DNS after verification. Removing them later breaks authentication for future mail.

DMARC: set policy and receive reports

DMARC uses SPF and DKIM results to tell receiving servers how to handle unauthenticated mail that claims to be from your domain. Its policy options include delivery, quarantine, and rejection; it can also send aggregate reports to an address you control. (support.google.com)

A prudent starting record is:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=none asks receivers to report rather than enforce a quarantine or rejection policy. DMARC.org recommends beginning with reporting so you can identify legitimate services that send using your domain before increasing enforcement. (dmarc.org)

After you know all valid senders are aligned, you can evaluate a stricter policy such as p=quarantine or p=reject. Do not escalate blindly: an overly strict policy can disrupt legitimate mail from a billing platform, support system, or old website that has not been authenticated.

Free SMTP relay setup: a worked Brevo and Node.js example

This example uses Brevo because it offers an SMTP relay on its free plan with a stated cap of 300 sends per day. The SMTP hostname and credential model in this section are Brevo-specific; do not reuse them with another provider. (brevo.com)

Step 1: create the account and finish sending approval

Create the account, complete the provider’s onboarding, and ensure the dashboard says the account is approved or activated for sending. Brevo states that new accounts start on a Free plan and can begin sending up to 300 emails per day once approved for sending. (brevo.com)

Do not send application traffic before that status is clear. A provider may accept your login but still restrict or hold traffic while it reviews the account.

Step 2: add and authenticate a sending domain

In the provider dashboard, add a domain such as example.com or, preferably for application mail, a subdomain such as mail.example.com. Follow the generated DNS instructions for verification and DKIM. Brevo’s domain-authentication flow is designed to generate the records needed for its setup, and it requires that you own and control the domain. (help.brevo.com)

Use a sender address that matches the authenticated domain, for example:

From: Example Alerts <alerts@mail.example.com>
Reply-To: support@example.com

Using a subdomain for transactional messages can make operations clearer. You can keep human correspondence on example.com while mail.example.com is dedicated to automated receipts, alerts, and account messages. This does not eliminate the need for consent, useful content, or bounce handling, but it gives your team cleaner boundaries.

Step 3: create an SMTP key and store it as a secret

Create a dedicated SMTP key in the provider dashboard. Brevo uses a unique SMTP login as the username and an SMTP key as the password; it warns that newly created keys are not fully displayed later, so store the key in a secret manager or environment variable immediately. (help.brevo.com)

For a local project, your .env file might contain:

BREVO_SMTP_LOGIN=your-provider-login@example.com
BREVO_SMTP_KEY=replace-with-a-real-secret
MAIL_FROM="Example Alerts <alerts@mail.example.com>"

Never commit this file to Git. In production, set the same values in your hosting platform’s encrypted environment-variable or secrets interface. Rotate the SMTP key if it appears in a log, repository, support ticket, or screenshot.

Step 4: configure SMTP over port 587 with STARTTLS

Brevo’s relay hostname is smtp-relay.brevo.com. Its documentation covers ports 587, 465, and 2525; port choice and TLS configuration are client-specific. For the common STARTTLS pattern, connect on port 587 and allow the client to upgrade the connection to TLS. (help.brevo.com)

Install Nodemailer:

npm install nodemailer

Then create send-test-email.mjs:

import nodemailer from "nodemailer";

const transporter = nodemailer.createTransport({
  host: "smtp-relay.brevo.com",
  port: 587,
  secure: false, // false for STARTTLS on port 587
  auth: {
    user: process.env.BREVO_SMTP_LOGIN,
    pass: process.env.BREVO_SMTP_KEY,
  },
});

await transporter.verify();

const result = await transporter.sendMail({
  from: process.env.MAIL_FROM,
  to: "your-test-inbox@example.net",
  subject: "SMTP relay test",
  text: "Your authenticated SMTP relay is working.",
  html: "<p>Your authenticated SMTP relay is working.</p>",
});

console.log({ messageId: result.messageId, accepted: result.accepted });

Nodemailer’s SMTP transport is designed for this sequence: configure a transporter, compose the message, and send it. Its verify() capability tests the SMTP configuration before you send a real message. (nodemailer.com)

Run it with your environment variables loaded using your preferred environment loader. A successful verify() means your app can establish the configured SMTP connection and authenticate; it does not prove the message will reach the inbox. The accepted response indicates that the relay accepted the recipient for processing, not that the recipient’s mailbox provider has completed delivery.

Step 5: test the complete delivery path

Send to at least two inbox providers you control, such as Gmail and Outlook. Check for the message in Inbox, Spam, and any tabs or categories. Then inspect the message headers.

In Gmail on the web, open the message menu and use Show original to view the full header. Gmail documents this header view as the way to inspect where a received message came from. (support.google.com)

You want to see a result equivalent to:

SPF: PASS
DKIM: PASS
DMARC: PASS

The exact header formatting differs by mailbox provider. A pass is strong evidence that your DNS and message alignment are working. It is not a permanent inbox-placement guarantee, because mailbox providers also evaluate reputation, recipient engagement, content, and complaints.

SMTP settings you can reuse with other providers

Every relay dashboard uses different hostnames, usernames, and keys, but most SMTP clients ask for the same fields:

Port 587 is commonly used for SMTP submission with STARTTLS. For example, Amazon SES documents STARTTLS support on ports 25, 587, and 2587, while its TLS-wrapper option uses ports 465 or 2465. This illustrates why you should match your client setting to the provider’s port documentation rather than assuming that every port behaves identically. (docs.aws.amazon.com)

If port 587 fails from a server, do not immediately switch to unencrypted SMTP. First check your host’s outbound firewall policy and the relay’s supported alternate ports. Network restrictions are a documented cause of SMTP connection failures. (docs.aws.amazon.com)

Common problems and the fixes that actually work

“Authentication failed” or “535 login incorrect”

Most authentication failures come from using the wrong credential type, copying a key with whitespace, rotating a key without updating the deployment, or configuring an account password instead of an SMTP-specific key. Recreate or rotate the SMTP key, update the deployed secret, and run the library’s connection-verification method before sending a message. Brevo identifies credentials, IP authorization settings, and network restrictions as common causes of SMTP login problems. (help.brevo.com)

“Connection timed out” or “ECONNREFUSED”

This is usually a network or port issue, not a DNS-authentication issue. Confirm the hostname, use the documented TLS mode, check whether your cloud host blocks outbound SMTP, and try the provider-supported alternative port if one exists. Do not use port 25 by default: it is often filtered to reduce abuse.

“Sender address rejected”

Your provider may require sender verification, a verified domain, or a From: address that matches an authenticated domain. Add the domain correctly, wait for DNS verification, and change the sender address to a matching domain or subdomain. Do not attempt to send as a customer’s domain unless that customer has explicitly authorized and authenticated it through the provider.

“Accepted” but no message arrives

Check the relay’s event log first. Look for a deferred, bounced, rejected, or delivered event. If the provider says delivered but the message is absent, search Spam and mailbox categories, then inspect headers on a message delivered to another test inbox.

A provider’s “delivered” status generally means it handed the message to the recipient’s receiving system. It does not necessarily mean that the user saw it in the Inbox. This distinction is why you should monitor both provider delivery events and real mailbox placement during testing.

SPF, DKIM, or DMARC fails

Verify the DNS record name as well as the value. Frequent errors include putting _dmarc.example.com into a DNS console that automatically appends the domain again, using more than one SPF record, publishing a DKIM record on the root domain instead of under the requested selector, or copying quotation marks that the DNS host adds automatically.

Start DMARC with reporting (p=none) while you inventory valid senders. Once all legitimate paths pass SPF or DKIM with alignment, consider enforcement. Gmail requires bulk senders—defined in its guidance as those sending 5,000 or more messages per day to Gmail accounts—to authenticate mail and provide easy unsubscribe for marketing and subscribed messages. (support.google.com)

How to know the setup worked

A relay is working only when all of these layers succeed:

1. Connection: your application can connect using TLS and authenticate with the SMTP credentials.
2. Submission: the library receives a message ID and the relay accepts the recipient.
3. Provider processing: the relay logs the message as delivered, deferred, bounced, or rejected rather than silently disappearing.
4. Authentication: a received copy shows SPF, DKIM, and DMARC passing where expected.
5. Mailbox outcome: the test message is visible in a real recipient inbox or, if not, you can explain the spam, deferral, or rejection result.

For meaningful ongoing monitoring, track delivery, bounces, complaints, deferrals, and authentication failures. At higher volume, Gmail Postmaster Tools provides dashboards for spam rate, reputation, authentication, and delivery errors for eligible senders. Gmail’s sender guidance says spam rates reported there should stay below 0.3%. (support.google.com)

Also test a realistic message. A one-line “hello” mail can pass while a receipt with a long tracking URL, a PDF attachment, or a particular HTML template produces a different outcome. Keep a plain-text alternative, use a recognizable sender name, and ensure the reply-to address is monitored.

Free relay versus an email API, self-hosted server, and Amazon SES

A free SMTP relay is one option, not a universal architecture.

SMTP relay versus email API

Choose SMTP when you need compatibility with existing tools: WordPress plugins, form builders, legacy apps, scanners, and libraries. Choose an email API when your engineering team wants first-class templates, idempotency patterns, structured event webhooks, inbound processing, or provider-specific features.

Many services offer both. Resend, for example, provides a transactional email product with REST API, SDKs, and SMTP service. That lets a team start with SMTP for compatibility and migrate selected flows to an API later. (resend.com)

SMTP relay versus self-hosting

Self-hosting a mail transfer agent gives you control, but it also makes you responsible for IP reputation, reverse DNS, TLS, spam-abuse prevention, bounce processing, queue management, monitoring, and provider-specific delivery behavior. That is rarely a good trade for a small product simply trying to send account email.

Use self-hosting only when you have a concrete infrastructure or compliance reason and the operational expertise to own it. “Free” server software does not make reliable delivery free.

SMTP relay versus Amazon SES

Amazon SES supports SMTP and is often evaluated for its usage-based model, but it is an AWS service rather than a simple permanent free-relay plan. Its SMTP credentials are unique to each AWS Region, and they are distinct from ordinary AWS secret access keys. (docs.aws.amazon.com)

SES can be appropriate when your infrastructure is already in AWS and your team is comfortable with IAM, regional configuration, and cloud billing. A low-volume free tier from a focused email provider is often simpler for a first deployment.

Security and compliance rules for application email

SMTP credentials are production secrets. Limit each key to the smallest practical scope where the provider supports it, store it outside source control, rotate it when staff leave or exposure is suspected, and avoid putting it in client-side JavaScript. A browser must never connect directly to your SMTP relay because that would expose the credentials to every user.

Send transactional mail only when it is expected. Password resets, receipts, account verification, security notices, and service alerts are ordinarily tied to a user action or relationship. Marketing mail needs a clear permission basis, accurate sender identity, and a working unsubscribe mechanism. Do not hide promotional content inside a transactional template merely to bypass unsubscribe or consent expectations.

Separate streams when the provider makes that practical. Transactional traffic and promotional traffic can have different recipient expectations and risk profiles; keeping them distinct helps your team reason about complaints, engagement, templates, and sending policies.

The practical bottom line

A free SMTP relay is enough to launch a low-volume application email flow if you keep the scope small: authenticate a domain, use TLS on the provider’s documented submission port, store an SMTP key safely, send an end-to-end test, and monitor what happens after the relay accepts a message.

For most small projects, the best starting point is not the provider with the largest-looking quota. It is the provider whose free limit fits your daily peak, whose DNS flow you can complete correctly, and whose logs let you answer a simple but critical question: did the recipient actually receive the message, and did authentication pass?

FAQ

What is the best free SMTP relay?

There is no single best option. Brevo provides up to 300 emails per day on its free plan, SMTP2GO provides up to 1,000 per month and 200 per day, and Resend provides 3,000 transactional emails per month with a 100-per-day cap. Choose based on your daily peak, monthly volume, required tools, and whether you need SMTP only or an API too. (help.brevo.com)

Can I use a free SMTP relay for WordPress?

Yes. Use an SMTP plugin that supports a custom SMTP host, port, encryption mode, username, and password. Authenticate your domain first, generate a provider SMTP key, send a test from the plugin, and inspect the received message headers. The exact plugin interface varies, but the SMTP settings are the same core fields used by custom applications.

Which SMTP port should I use?

Use the port and TLS mode documented by your provider. Port 587 with STARTTLS is a common submission configuration; port 465 is commonly used for implicit TLS by providers that support it. Never choose an unencrypted mode simply to make a connection work. (docs.aws.amazon.com)

Why are my free SMTP relay emails going to spam?

The typical causes are missing or misaligned SPF/DKIM/DMARC, an unverified sender domain, poor recipient engagement, unwanted content, a new or weak sending reputation, or a mismatch between the visible From: domain and the authenticated sending domain. First confirm authentication passes in message headers, then use the relay’s event logs and real inbox tests to isolate the problem. (support.google.com)

Can I send newsletters through a free SMTP relay?

Technically, some providers allow marketing messages on free plans, but a free daily cap and compliance requirements make it a poor fit for most newsletters. Send only to people who opted in, include a clear unsubscribe method, and move to a plan designed for your list size before a campaign can exceed the daily allowance.