SMTP Settings

Any application that can send email over SMTP can send through a Bridge: web frameworks, e-commerce platforms, CMS plugins, help desks and your own code. This page lists the settings, the rules each message has to follow, and examples for common clients.

Connection settings

Copy these from the Bridge's details page. Go to Transactional → Bridges and click the Bridge's name; the values are under Method 1: Send via SMTP.

Setting	Value
Host	The Host shown on the Bridge, smtp.mumara.com
Port	587 (recommended)
Encryption	STARTTLS. The Bridge page shows this as TLS.
Authentication	Required. PLAIN or LOGIN
Username	The Bridge's Username
Password	The Bridge's Password

In a generic mail client or a framework's mail settings, that looks like this:

SMTP server:     smtp.mumara.com
Port:            587
Security:        STARTTLS
Authentication:  Normal password (PLAIN or LOGIN)
Username:        YOUR_BRIDGE_USERNAME
Password:        YOUR_BRIDGE_PASSWORD

Copy the username exactly

A Bridge's username is a long generated string. Use the copy button on the Bridge's details page rather than retyping it, and make sure no spaces or line breaks come along with it.

Ports and encryption

The relay listens on four ports. The same Bridge credentials work on all of them.

Port	Encryption	When to use it
587	STARTTLS	The default for applications submitting mail. Use this unless you have a reason not to.
2525	STARTTLS	An alternative when your network or hosting provider blocks 587.
25	STARTTLS	Works, but many hosting and cloud providers block outgoing connections on port 25.
465	Implicit TLS	For clients that only offer "SSL" or "SSL/TLS". The connection is encrypted from the first byte, with no STARTTLS step.

STARTTLS means the client connects in plain text and then upgrades the connection to TLS before logging in. Implicit TLS means the connection is encrypted from the start. In most clients:

• Ports 587, 2525 and 25: choose STARTTLS or TLS, and in Nodemailer set secure: false.
• Port 465: choose SSL or SSL/TLS, and in Nodemailer set secure: true.

Encryption is required

The relay only offers login after the connection is encrypted. If your client is set to None or plain text, it can't authenticate and every message is refused. Always connect using the host name, not an IP address, so the TLS certificate matches.

Which From addresses are allowed

Every message has to come from one of your verified sending domains. The relay checks two addresses:

• The envelope sender (MAIL FROM), which many clients call the return path or bounce address.
• The From: header, which is what the recipient sees.

The domain of both must be a sending domain you've added and verified under Setup → Sending Domains. See Sending Domains.

• The match is exact. If you've verified example.com and want to send from alerts@mail.example.com, add and verify mail.example.com as a sending domain of its own.
• Any Bridge can use any of your verified domains. You don't need a separate Bridge for each domain.
• Display names are fine. "Example Store" <orders@example.com> is accepted.
• An empty envelope sender isn't accepted. Most clients use the From address as the envelope sender automatically. If yours lets you set a separate return path or bounce address, leave it empty or use an address on the same verified domain; Mumara ONE replaces it with its own bounce address anyway.
• A disabled sending domain is refused, even though it's verified.

What Mumara ONE sets on every message

Mumara ONE adds or replaces a few things on every message it relays, so bounces, complaints and tracking work without any setup on your side:

• DKIM signature. The message is signed with your sending domain's DKIM key. A DKIM-Signature header your application adds is removed first.
• Message-ID. Replaced with one that Mumara ONE generates, which it uses to match bounces, complaints, opens and clicks to the message.
• Return path. Replaced with a Mumara ONE bounce address, so bounces are processed for you.
• Tracking. If the Bridge has Track Opens or Track Clicks switched on, the HTML part is changed as described in Bridges.

Custom headers

Your own headers pass through unchanged. Use them to carry your own references, such as an order or ticket number:

X-Order-Id: 10025
X-Customer-Ref: C-88213

Use your own X- names. A small number of X- headers are reserved for Mumara ONE's own use and are replaced when the message is relayed.

Test without delivering

To check that your settings work without sending anything to a real recipient, add this header to the message:

X-Mode: mta-discard

The relay runs every check on the message, including your login, the sending domain and the Bridge's status, then accepts it and discards it instead of delivering it. It doesn't use any of your sending allowance. Remove the header when you're ready to send for real.

Limits

• Message size: up to 25 MB per message, including attachments. Attachments are base64-encoded in email, which makes them about a third larger than the original files. The relay announces this limit in its SMTP SIZE extension, so most clients warn you before sending.
• Sending allowance: every message counts against your plan's transactional sending allowance. When it runs out, the relay refuses new messages with 550 Insufficient transactional credits until the allowance is topped up. See Plan and Usage.
• Credentials in the message: the relay refuses a message whose content includes both the Bridge's username and its password, with a "credential leak detected" error. Never put credentials in an email body.

One recipient per message

You can put several recipients on one message, but sending a separate message to each recipient keeps opens, clicks and bounces attributed to the right person.

Examples

Replace the placeholders with your Bridge's credentials, and the addresses with ones on your verified sending domain. Keep credentials in environment variables or your framework's secrets store, not in source code.

PHP (PHPMailer)

<?php
use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\Exception;

require 'vendor/autoload.php';

$mail = new PHPMailer(true);

try {
    $mail->isSMTP();
    $mail->Host       = 'smtp.mumara.com';
    $mail->Port       = 587;
    $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS; // use ENCRYPTION_SMTPS with port 465
    $mail->SMTPAuth   = true;
    $mail->Username   = getenv('MUMARA_BRIDGE_USERNAME');
    $mail->Password   = getenv('MUMARA_BRIDGE_PASSWORD');

    $mail->setFrom('orders@example.com', 'Example Store');
    $mail->addAddress('jane@example.com', 'Jane Doe');
    $mail->addCustomHeader('X-Order-Id', '10025');

    $mail->isHTML(true);
    $mail->Subject = 'Your order has shipped';
    $mail->Body    = '<html><body><p>Good news: your order is on its way.</p></body></html>';
    $mail->AltBody = 'Good news: your order is on its way.';

    $mail->send();
    echo "Message sent\n";
} catch (Exception $e) {
    echo "Message could not be sent: {$mail->ErrorInfo}\n";
}

Node.js (Nodemailer)

const nodemailer = require('nodemailer');

const transporter = nodemailer.createTransport({
  host: 'smtp.mumara.com',
  port: 587,
  secure: false,     // false for STARTTLS on 587, 2525 or 25; true for port 465
  requireTLS: true,  // refuse to continue if STARTTLS isn't available
  auth: {
    user: process.env.MUMARA_BRIDGE_USERNAME,
    pass: process.env.MUMARA_BRIDGE_PASSWORD,
  },
});

async function main() {
  const info = await transporter.sendMail({
    from: '"Example Store" <orders@example.com>',
    to: 'jane@example.com',
    subject: 'Your order has shipped',
    text: 'Good news: your order is on its way.',
    html: '<html><body><p>Good news: your order is on its way.</p></body></html>',
    headers: { 'X-Order-Id': '10025' },
  });
  console.log('Accepted:', info.accepted, info.response);
}

main().catch(console.error);

Troubleshooting

Symptom	Likely cause and fix
The client says the server doesn't support authentication, or the login command isn't recognised	The connection isn't encrypted, so login is never offered. Set the client to STARTTLS on 587, 2525 or 25, or SSL/TLS on 465.
535 authentication failed	The username or password is wrong, or only partly copied. Copy both again from the Bridge's details page. Also check that the Bridge still exists and hasn't been deleted.
The connection times out on port 25	Your network or hosting provider blocks outgoing port 25. Use 587, or 2525 if 587 is blocked too.
wrong version number, or the TLS handshake fails straight away	The encryption setting doesn't match the port. Use STARTTLS (secure: false) on 587, 2525 and 25, and implicit TLS (secure: true) only on 465.
Certificate or host name mismatch	You're connecting to an IP address or a different host name. Use the Host exactly as shown on the Bridge. If the error persists, update the CA certificates on your server.
... is not authorized to relay emails	The domain in the From address or envelope sender isn't one of your verified sending domains. Verify it under Setup → Sending Domains, or change the From address.
... is disabled	Either the sending domain has been disabled, or the Bridge's Status switch is off.
550 Insufficient transactional credits	Your transactional sending allowance has run out. See Plan and Usage.
Your account is suspended	Contact Mumara support.
The message is rejected as too large	Keep each message, including encoded attachments, under 25 MB. Link to large files instead of attaching them.

To check that your server can reach the relay and negotiate TLS, open a connection from the command line:

openssl s_client -starttls smtp -connect smtp.mumara.com:587 -crlf

1. Near the end of the output, look for Verify return code: 0 (ok). Anything else points to a certificate problem on your side.
2. Type EHLO example.com and press Enter. The reply should include AUTH PLAIN LOGIN, which confirms that login is offered over the encrypted connection.
3. Type QUIT to close the connection.

If the command hangs without printing anything, your network is blocking the port. Try 2525 instead of 587.

For the HTTP alternative to SMTP, see Sending API.