SMTP authentication and submission ports
The relay listens on three submission ports following
the standard authenticated submission convention.
Port 587 is the modern default: the SMTP submission
port defined by RFC 6409, accepts plaintext connections
that must upgrade to TLS via STARTTLS before AUTH. Port
465 is SMTPS: legacy implicit TLS where the connection
starts encrypted before any SMTP commands; still widely
supported. Port 2525 is an alternative submission port
we offer for environments where 587 and 465 are blocked
by upstream networks (some cloud providers and some
residential ISPs block these to prevent spam relay
abuse).
Authentication uses SMTP AUTH PLAIN over the TLS-protected
connection. Credentials format is base64-encoded
username and password concatenated; standard library
implementations handle this transparently. We do not
accept LOGIN auth (deprecated, brittle) or CRAM-MD5
(broken cryptographically). PLAIN over TLS is the
modern default across all SMTP libraries.
DNS configuration walkthrough
Three DNS records per sending domain land you in
authenticated-sender territory. The SPF record at the
domain apex authorises our relay IP: a TXT record at
example.com containing "v=spf1 ip4:[your-IP] -all" or
"v=spf1 include:relay.our-domain.com -all" depending
on whether you publish IPs directly or use our SPF
include macro.
The DKIM record at selector._domainkey.example.com
publishes the public key of the keypair we generated:
a TXT record containing "v=DKIM1; k=rsa; p=[base64
public key]". The selector is configurable; we default
to the year and quarter (s2026q1) for operations that
want quarterly rotation discipline. The relay signs
outbound messages with the corresponding private key,
which never leaves our infrastructure.
The DMARC record at _dmarc.example.com sets your
alignment policy: a TXT record containing "v=DMARC1;
p=quarantine; rua=mailto:[email protected]"
for monitoring mode, or stronger enforcement
(p=reject) once you have validated alignment. We
recommend escalating from p=none (monitoring only) to
p=quarantine to p=reject over a 30-90 day window
while watching DMARC reports for any legitimate mail
missing from the alignment.
Integration code examples
Most SMTP libraries take five lines of configuration.
For Node.js with nodemailer: const transporter =
nodemailer.createTransport with host: relay.our-domain,
port: 587, secure: false, auth: user and pass, tls
requireTLS: true. The require-TLS flag forces STARTTLS
upgrade and rejects the connection if the server does
not advertise STARTTLS support; this prevents
accidental plaintext submission.
For Python with smtplib: smtplib.SMTP(host, 587),
conn.starttls(), conn.login(user, pass), conn.sendmail.
Use SMTP_SSL on port 465 for implicit TLS variant.
For PHP with PHPMailer: $mail->isSMTP(), $mail->Host,
$mail->Port = 587, $mail->SMTPAuth = true,
$mail->SMTPSecure = STARTTLS. For applications using
framework-level mail abstractions (Rails ActionMailer,
Django mail, Laravel Mail), set the SMTP host, port,
and credentials in the framework configuration; the
framework handles protocol details.
Bounce handling and webhook integration
Bounces and FBL complaints reach you through two
channels. Channel one is the accounting log: structured
log file containing every delivery event (accepted,
deferred, bounced, complained), available via SFTP
pull on a per-customer basis. Channel two on Pro and
Scale plans is webhook delivery: each event posts to
your endpoint as JSON within seconds of occurrence.
Webhook payload structure: event type (delivered,
bounced, complained, deferred), timestamp, message-id,
recipient, sender, bounce category, enhanced status
code, reason text. Standard pattern for bounce
processing: receive webhook, extract recipient, mark
recipient as bounced in your subscriber database,
stop sending to recipient until bounce reason
resolves. Hard bounces (5.x.x codes for permanent
failures) typically result in permanent suppression;
soft bounces (4.x.x codes for temporary failures)
retry per relay schedule and only suppress after
repeated failures.
Migration from SaaS providers
Migration from SendGrid, Mailgun, Amazon SES, or
Postmark is straightforward at the technical level
because all of these expose SMTP submission interfaces.
Steps: (1) request relay setup with us, providing
your sending domains; (2) we generate DKIM keypairs
and provide DNS records to publish; (3) you publish
DNS records; (4) we provide credentials for SMTP
submission; (5) you update your application
configuration to point at our relay endpoint with our
credentials; (6) you decommission the SaaS provider.
Data migration concern: subscriber lists, suppression
lists, and historical engagement data live in the SaaS
provider's system. We do not import historical data
(we operate at the relay layer, not the application
layer); your application needs to retain or migrate
its own subscriber and suppression data. For
operations using MailWizz or Acelle on top of the
relay, the application data lives in your MailWizz or
Acelle database and migration is straightforward.
