Email relay: a server that accepts and forwards your mail, and what an agent sends instead

Two meanings of relay

In mail infrastructure, relaying is a server accepting a message it is not the final destination for and passing it on. This is the sense used in SMTP, in the phrase open relay, and in every product marketed as an SMTP relay service.

In privacy tooling, a relay service issues a disposable alias address that forwards to a real mailbox. The user gives out the alias, and the service strips the connection to the underlying address. That is a receiving and forwarding product, not a sending one.

When a log or message trace says a message was relayed, the server accepted it and handed it to the next hop. It does not mean the message reached the inbox.

This page covers the sending sense. Running a server of your own is covered in the free SMTP server and SMTP hosting guides, and the transactional email services hub lists the related options.

What changes when an AI agent sends instead of a relay

An agent can skip the relay hop for application mail. It sends each message through an API or an MCP server from a sending subdomain that is already verified, and reads delivery status back as events rather than parsing relay logs.

Left to its defaults, an agent asked to "make the app send its receipts" tends to reach for whatever relay the team already has and paste its SMTP username and password into the codebase. The mail goes out, but the credential now lives in source control and the app learns nothing about each message after the relay accepts it.

George Hartley, Nitrosend's co-founder, describes the product as one that can be controlled completely from whatever AI agent a user already works in. On who does what, his view is that the agent does the setup and a person approves what ships. For a relay replacement, that means the agent wires up the domain, the template and the send call, and a person signs off before real users get the mail.

The same work runs from a terminal through the Nitrosend CLI or from code through the transactional email API. Teams working in Claude can start from email for Claude.

How relaying works

A sending application or device connects to the relay and authenticates. The relay accepts the message and takes responsibility for it from that point.

Resolution comes next: the recipient domain's MX records are looked up and a connection opened to the receiving server, with temporary failures retried on a schedule and permanent ones reported back as bounces.

Acceptance by the receiving server ends the relay's job. Placement, meaning inbox versus spam, is decided afterward by the mailbox provider and is not reported back through the protocol.

The relay's real value is what surrounds that transfer: queueing, retry policy, bounce classification and suppression, none of which SMTP itself provides.

Why organizations use one

1. Reputation. A relay authenticates as your domain rather than as a person's mailbox, which removes per-mailbox sending caps and attaches sending history to a domain you control.
2. Stream separation. Transactional mail, marketing campaigns and cold outreach carry different complaint profiles, and routing them through distinct sending subdomains stops the worst one degrading the best. Cold outreach in particular belongs on its own domains and mailboxes, at its own volumes, apart from marketing email.
3. Devices. Printers, scanners and monitoring systems compose messages without being mail servers, and a relay gives them somewhere authenticated to hand mail to.
4. Reporting. Per-message delivery status, bounce reason and a searchable history are what turn a delivery complaint into something investigable. It is the reason teams notice last.

A team that already pays for a sending provider can keep it. Nitrosend can send through those provider credentials, set up with nitro_configure_providers, while contacts, templates and analytics stay in one place.

Open relays

An open relay accepts and forwards mail from any sender to any recipient without authentication. This was the default configuration in SMTP's early years and is the reason large-scale spam relaying was ever practical.

An open relay ends up on blocklists once spammers find it, and receiving servers reject its mail. Authentication on submission is what prevents it, which is why every legitimate relay requires credentials or an allowlisted address before accepting anything for an external recipient.

Misconfiguration is the usual cause rather than intent. A server permitting relay based on a network range that later expands, or one exposed to the internet without a submission policy, becomes an open relay without anyone deciding to make it one.

The two domains in play, and which one the reader sees

The domain you verify for sending is not always the domain the recipient sees in the From line.

A subdomain is what gets verified and carries the sending reputation. The apex is what shows as the sender in the mail client.

Keeping reputation on a subdomain is the point of the arrangement. A campaign that goes badly damages the subdomain that sent it rather than the domain the company's staff use for their own correspondence, and that separation only exists if it was set up before it was needed.

Mail to the apex still has to land somewhere while the subdomain sends. Nitrosend's Coexist is an inbox on your own domain where new mail reaches both Nitrosend and your existing email provider. Separately, every account has an agent inbox that receives mail on your own domain and posts it to your application through the email.received webhook.

Worked example: an agent moves a password reset off an old relay

The prompt, in the user's own words: "Our password reset email goes out through an old office relay. Move it to Nitrosend on send.ourdomain.com."

1. nitro_get_status reads the account context, sender identity and readiness before anything changes.
2. nitro_manage_domains adds send.ourdomain.com as a customer sending domain and verifies it, so resets carry the subdomain's reputation rather than the relay's.
3. nitro_manage_template creates the reset email as a reusable template, with the reset link as a variable.
4. nitro_review_delivery checks that reset template before any test goes out, covering validation, spam analysis and previews without sending a thing.
5. nitro_send_test_message sends a single real reset email to the team's test recipient, the address held in the account's sender defaults through nitro_configure_account.
6. A person opens that test reset, clicks the link, and approves switching the app off the relay.
7. nitro_send_message then sends one reset per request from the app, with an idempotency_key that is reused only when the exact same reset is retried.
8. nitro_get_insights shows how reset mail performs over the following days, with trends and recommendations.

Before: every reset leaves through one shared relay credential, and nobody can tell whether a given user's reset was delivered or bounced.

After: resets leave from the verified send.ourdomain.com subdomain, one call per reset, with each message's status readable afterward.

Where it goes wrong when an agent replaces an email relay

• Fallback becomes an open relay. The agent keeps the old relay running as a fallback and allows a whole network range to submit through it. When that range grows, the fallback becomes an open relay that nobody is watching.
• Permanent bounce retried. A permanent 5xx bounce for a mistyped address gets treated as a temporary failure and retried, so the same dead address is hit again and again.
• Apex verified instead. The apex domain gets verified instead of the sending subdomain, which puts reset traffic on the reputation the company's staff mail depends on.
• Acceptance read as placement. The receiving server accepting a reset gets reported to the team as inbox placement, even though the mailbox provider decides inbox versus spam afterward.
• Duplicate reset sent. A timed-out reset is retried with a fresh idempotency key instead of the original one, and the user receives two reset emails with two different links.

FAQ

What does relayed mean in an email header or log?

It means a server accepted the message and passed it to the next hop toward the recipient. Relayed does not mean delivered to the inbox, because the mailbox provider decides placement afterward.

Is an email relay the same as an SMTP relay?

In the sending sense, yes. An SMTP relay is an email relay that accepts mail over SMTP and forwards it to the recipient's server. The term email relay also covers alias privacy services, which forward incoming mail to a hidden mailbox and send nothing on anyone's behalf.

Does an app need an email relay to send transactional email?

No. An app can send each message through an email API or an MCP server from a verified sending subdomain and read back the status of every message. A relay still suits devices such as printers and scanners that can only hand mail over SMTP, one of the 4 reasons organizations use one.

Go deeper