How to Send Email with Sendrealm SMTP

SMTP is the quickest way to connect Sendrealm to an application, framework, or third-party product that already knows how to send mail. You keep the existing mail library and replace its server settings with Sendrealm credentials.

This guide covers the connection values, working Node.js examples for both supported ports, a safe production setup, and the checks to make when delivery fails.

Sendrealm SMTP settings

Use these values:

The From address must belong to a verified domain in the same Sendrealm project as the API key.

Port 587 or 465?

Use 587 with STARTTLS when the library opens a normal SMTP connection and upgrades it to TLS. This is the standard submission path and is the best default for most application frameworks and hosted products.

Use 465 with implicit TLS, sometimes labeled SMTPS or SSL, when the client expects encryption from the first byte of the connection.

These settings are not interchangeable. A client configured with secure: true on port 587 may fail because it attempts implicit TLS where STARTTLS is expected. A client configured with secure: false on port 465 makes the opposite mistake.

Before sending: verify a domain and create a key

1. Add the sending domain in the Sendrealm dashboard.
2. Publish the DNS records shown for that domain.
3. Wait until the domain is verified.
4. Create a project API key with email-sending permission.
5. Store the key in your server-side secret manager.

Name the key after its owner and environment, for example billing-worker-production. Avoid a single key shared by the web application, background workers, development laptops, and external integrations.

Node.js example with port 587

Install Nodemailer:

npm install nodemailer

Then create a transporter:

import nodemailer from 'nodemailer';

const transporter = nodemailer.createTransport({
  host: 'smtp.sendrealm.com',
  port: 587,
  secure: false,
  requireTLS: true,
  auth: {
    user: 'smtp',
    pass: process.env.SENDREALM_API_KEY
  }
});

await transporter.sendMail({
  from: 'Example App <[email protected]>',
  to: '[email protected]',
  subject: 'Your report is ready',
  text: 'Your report is ready to download.',
  html: '<p>Your report is ready to download.</p>'
});

secure: false does not mean the session stays unencrypted. On port 587, Nodemailer connects and then upgrades the connection with STARTTLS. requireTLS: true prevents continuing if that upgrade is unavailable.

Node.js example with port 465

For implicit TLS, change the port and secure mode:

import nodemailer from 'nodemailer';

const transporter = nodemailer.createTransport({
  host: 'smtp.sendrealm.com',
  port: 465,
  secure: true,
  auth: {
    user: 'smtp',
    pass: process.env.SENDREALM_API_KEY
  }
});

await transporter.sendMail({
  from: 'Example App <[email protected]>',
  to: '[email protected]',
  subject: 'Security notice',
  text: 'A new sign-in was detected.'
});

Choose one configuration that matches the deployment environment; you do not need to use both ports.

Framework and third-party configuration

Most SMTP integrations ask for the same fields under slightly different names:

• SMTP server, server, or host: smtp.sendrealm.com
• login or username: smtp
• password: the project API key
• encryption: STARTTLS for 587, SSL/TLS for 465
• sender or From address: an address on the verified domain

If the product has a “test connection” button, remember that a successful login only proves authentication. Send an actual message to validate the sender domain, message construction, recipient handling, and delivery events.

Production practices that prevent outages

Keep credentials server-side

An SMTP password authorizes sending. Never place it in browser JavaScript, a mobile application, a public .env file, or a client-side build variable. If the email originates from a browser or mobile action, call your own trusted backend and send from there.

Separate environments

Use different Sendrealm projects or at least different keys for development, staging, and production. Development mail should not be able to impersonate production accidentally or consume its operational quota.

Set timeouts and handle errors

SMTP clients can experience network timeouts, temporary recipient-server deferrals, and permanent rejections. Log the SMTP response without logging the API key or sensitive message content. Retry only temporary failures and use bounded backoff rather than an unending loop.

Make application requests idempotent

If a job times out after handing a message to SMTP, the application may not know whether the message was accepted. Retrying blindly can create duplicate receipts, codes, or alerts. Use a durable job identifier and record the outcome around the send operation.

Send both text and HTML where appropriate

A plain-text alternative improves accessibility and gives clients a fallback. Keep both versions semantically consistent, and test links in the rendered message.

Troubleshooting

Authentication failed

Check that the username is smtp, not your account email, and that the password is an active API key from the intended project. Remove whitespace introduced while copying the secret.

Connection or TLS error

Confirm that the port and encryption mode match. Try 587 with STARTTLS if a hosted product rejects implicit TLS, or 465 with SSL/TLS if it requires encryption immediately.

Sender is not authorized

The From address must use a verified domain in the API key's project. A verified example.com domain does not automatically authorize an unrelated address such as [email protected].

The send succeeds, but the recipient cannot find the message

Open Messages → Emails in Sendrealm and inspect the recipient timeline. “Delivered” means the receiving server accepted the message; mailbox placement can still be affected by filtering, recipient rules, and reputation. Bounce, delay, complaint, and suppression events each point to a different cause.

When to use the API instead

SMTP is ideal for compatibility. The Sendrealm HTTP API or SDK is often a better fit when a new backend integration needs structured payloads, typed errors, explicit metadata, attachments, tags, or request-level application logic.

Choose based on the integration boundary:

• existing framework or third-party SMTP field: use SMTP
• new trusted backend with application-specific behavior: consider the API or SDK
• frontend or mobile client: call a trusted backend; never embed either credential

Final checklist

• domain verified
• sender address belongs to that domain
• key scoped and stored as a secret
• port matches encryption mode
• connection and send tested separately
• errors logged without secrets
• temporary retries bounded
• duplicate sends considered
• recipient events monitored after launch

Open the Sendrealm dashboard to verify a domain, create an API key, and test SMTP delivery.