SMTP relay: what it is, when you need one, and how to set one up

RFC 5321, the SMTP standard, defines a relay as a server that “receives mail from an SMTP client and transmits it” to another server “for further relaying or for delivery”. An SMTP relay service runs that server for you: you get a host name, a port and a login, and it handles delivery, retries and the signatures receivers check.

The login is not optional. A server that passes on mail from anyone is an open relay, spammers find and use it, and its address ends up on blocklists (the blocklist guide covers getting off one). A relay only sends: reading mail at your business address is email hosting, a different product (the business email post).

The usual cases are below. A hosted store such as Shopify sends its order emails from its own servers, so there is no SMTP setting to change; authenticate your domain under Settings → Notifications → Sender email in Shopify instead.

Use 465 if your client offers it: the connection is encrypted with TLS from the first byte, called implicit TLS. Otherwise use 587, which starts in plain text and upgrades with STARTTLS before the login. Port 25 is for servers delivering to each other, and Rasket does not offer it. The SMTP guide explains where the three ports came from, and Email API vs SMTP which hosts block them.

Host:      smtp.rasket.com
Port:      465 (implicit TLS) or 587 (STARTTLS)
Alternate: 2465 (implicit TLS) or 2587 (STARTTLS)
Username:  rasket
Password:  an API key (rk_…) with sending access

The alternates behave the same, for networks that block the usual port. A firewall needs outbound TCP to smtp.rasket.com on the port you use; there is no fixed IP range to allow, so allow it by name.

“SSL” in a plugin dropdown is the old name for implicit TLS, and “TLS” there means STARTTLS: PHPMailer, which wp_mail() sends through, defines 'ssl' as SMTPS and 'tls' as STARTTLS. Crossing them is the usual first failure: “TLS” on 465 hangs until it times out, and “SSL” on 587 fails at once with a TLS error.

DNS records are public notes about your domain, added wherever its DNS is hosted, usually the company you bought the domain from. The domain page lists every record to copy; the domain verification post walks through pasting them at a registrar, including the one-click route for registrars that support it.

You do not edit your existing SPF record, the list of servers allowed to send as your domain: the relay sets the envelope sender to the return-path subdomain whatever your mailer puts in MAIL FROM, and its SPF lives there. You add no include: at the root and spend none of SPF’s 10 DNS lookups. Under DMARC’s default relaxed alignment, SPF and DKIM both align with your From domain; with strict SPF alignment (aspf=s) only DKIM does, which is still enough for DMARC to pass. In short: leave your SPF record alone, and DMARC passes either way.

DMARC itself is yours to publish. When your domain has none, its page offers a starter p=none record that only collects reports, and the DMARC guide covers moving to p=reject. Records usually resolve within an hour, or within their TTL. Once a test message arrives, read its verdicts: SPF, DKIM and DMARC should each pass, with your domain as the DKIM signer.

1. Verify a sending domain — Add the domain the mail will come from, publish the DKIM and sending records its page lists, and wait until it reads verified.
2. Create a key for the relay — Create an API key with sending access, restricted to that domain. It is the SMTP password; keep it in an environment variable.
3. Enter the settings and the From address — Put the host, port, username and key into the client, with the encryption setting that matches the port, and a From address on the verified domain.
4. Send a test and read the reply — Send one message to an address you can read. 250 2.0.0 carries the email's id; 4xx means retry later; 5xx means something has to change.

Settings → SMTP in the dashboard creates the key, fills the settings in and sends a test; from a terminal, this standard-library script does the same. Its X-Rasket-Tags header takes name=value pairs separated by commas. After the 250, a webhook or the Emails page tells you what happened, because the relay never mails a bounce back.

import os, smtplib, ssl
from email import policy
from email.message import EmailMessage
from email.utils import make_msgid

host = os.environ.get("RASKET_SMTP_HOST", "smtp.rasket.com")
port = 465  # implicit TLS; 2465 if your network blocks 465

msg = EmailMessage(policy=policy.SMTP)  # CRLF line endings, as SMTP requires
msg["From"] = os.environ["MAIL_FROM"]  # on a domain you verified
msg["To"] = os.environ["MAIL_TO"]
msg["Message-ID"] = make_msgid(domain=msg["From"].split("@")[-1])
msg["Subject"] = "Relay test"
msg["X-Rasket-Tags"] = "category=relay-test"
msg.set_content("If you can read this, the relay settings work.")

with smtplib.SMTP_SSL(host, port, context=ssl.create_default_context()) as smtp:
    smtp.login("rasket", os.environ["RASKET_API_KEY"])
    code, reply = smtp.mail(msg["From"])
    if code != 250:
        raise SystemExit(f"MAIL FROM refused: {code} {reply.decode()}")
    code, reply = smtp.rcpt(msg["To"])
    if code != 250:
        raise SystemExit(f"RCPT TO refused: {code} {reply.decode()}")
    code, reply = smtp.data(msg.as_bytes())
    print(code, reply.decode())  # 250 2.0.0 Queued as <email id>, or the refusal

250 2.0.0 Queued as 01a148de-30f2-7894-9e5e-5acbbcb214ef

For a store owner, the whole job is five steps:

• Verify your domain (the DNS section above).
• Create an API key with sending access, restricted to the store’s domain, so a leaked one can only send as the store.
• Install an SMTP plugin that keeps an email log and can resend a failed message (the free FluentSMTP is one), and enter host smtp.rasket.com, port 465, encryption SSL, authentication on, username rasket, the key as the password, and a From email on your verified domain.
• Set WooCommerce’s own sender address, as below.
• Place a test order and check the order email arrives and shows on the Emails page.

Rasket's own WordPress plugin, which sends over the API instead, is not in the plugin directory yet. Without a plugin, this hook in a small plugin file or your theme’s functions.php does the same as step 3:

add_action('phpmailer_init', function ($mailer) {
    $mailer->isSMTP();
    $mailer->Host = 'smtp.rasket.com';
    $mailer->Port = 465;
    $mailer->SMTPSecure = 'ssl';
    $mailer->SMTPAuth = true;
    $mailer->Username = 'rasket';
    $mailer->Password = getenv('RASKET_API_KEY');
});

add_filter('wp_mail_from', fn () => 'shop@acme.example');
add_filter('wp_mail_from_name', fn () => 'Acme');

On shared hosting, or a PHP-FPM host that clears the environment, put define('RASKET_API_KEY', 'rk_…'); in wp-config.php and use $mailer->Password = RASKET_API_KEY; instead.

Every WooCommerce email goes through wp_mail(), so every one of them uses the relay: new order, processing, completed, refunded, customer note and account emails. None is sent another way unless a plugin replaces WooCommerce’s mailer. WooCommerce does set its own From address on its emails, and for those it wins over the filters above. Its default is the site’s admin email; if that is not on your verified domain, WordPress’s own login emails go out while every WooCommerce email is refused with 550 5.7.1. Change it under WooCommerce → Settings → Emails, in the sender options.

Each relayed message is one POST /emails made with your key, so it counts against the same 10-a-second team rate as the API (the rate limits post explains the bucket). A reply’s first digit decides what your mailer does: 2 success, 4 retry later, 5 change something. The x.y.z after it is an enhanced status code (RFC 3463), and the text is the API’s own error message.

A 451 4.7.1 for the rate limit clears in a second. One for a monthly quota or the spend cap will not clear by waiting: it can outlast a mail queue’s give-up time, which RFC 5321 puts at “at least 4-5 days”, and then the mailer bounces the message to its own sender. The relay uses X.7.1 for every limit, so only the text tells them apart; act on the email and banner team admins get at 80 % and 100 % of the monthly allowance. The SMTP docs list the rarer replies.

250 means accepted, not delivered. The id in the reply is the email’s id, the same one an API send returns. Looking it up needs a full-access key; the relay’s sending-only key gets 401 restricted_api_key here:

curl -s "${RASKET_API_URL:-https://api.rasket.com}/emails/$EMAIL_ID" \
  -H "Authorization: Bearer $RASKET_FULL_ACCESS_KEY"

{
  "id": "01a148de-30f2-7894-9e5e-5acbbcb214ef",
  "last_event": "queued",
  "tags": { "category": "relay-test" }
}

On a read, tags come back as an object keyed by name, here from the X-Rasket-Tags header the test set. Later webhook events (email.delivered, email.bounced, email.complained and the rest) carry the same id and the same tags; the webhooks post shows how to receive them. A suppressed recipient is accepted and skipped, with an email.suppressed event; the suppression list post says which suppressions apply.

RFC 5321’s relay passes a message on unchanged. Rasket’s is strictly a submission server (RFC 6409), and it changes messages further than that RFC’s own examples:

• Message-ID is replaced with one Rasket assigns, after the idempotency key above is read. In-Reply-To and References are kept, so mail apps thread replies, but a help desk that matches replies against the Message-ID it generated will not find them. Thread on a ticket number in the subject or a per-ticket Reply-To address, if it offers either.
• Internal headers are dropped. Received lines your servers added are not forwarded; your own X- headers are.
• List-Unsubscribe is dropped, and a marketing unsubscribe does not stop relay mail.
• Bcc-only mail is refused with 550 5.6.0: at least one address in the To: header must also be an envelope recipient (RCPT TO).
• S/MIME and PGP are refused, because rebuilding the message would break the signature.
• Old devices without TLS 1.2 or a login cannot connect. A small local relay such as Postfix, accepting only that device’s address, can take their mail and log in upstream; never let it accept mail from anyone else.

Whichever path you take, start with the domain and one key restricted to it, send a test from Settings → SMTP, and only then change the software that sends.