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.
The rest of this page covers the sending sense.
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 organisations use one
Reputation is the main reason. 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.
Separation of streams is the second. 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. George, our CEO, draws that line hard: cold infrastructure is not marketing email. Different domains, different mailboxes, different volumes, different deliverability rules.
Devices that cannot run a mail client are the third. Printers, scanners and monitoring systems compose messages without being mail servers, and a relay gives them somewhere authenticated to hand mail to.
Reporting is the fourth and the one teams notice last. Per-message delivery status, bounce reason and a searchable history are what turn a delivery complaint into something investigable.
Using a relay also does not mean surrendering to one. We integrate with the major SMTP relays, SendGrid, Postmark and SES among them, so users keep ownership of their sending infrastructure while everything above it, contacts, templates, analytics and the agent surface, lives 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.
Any host operating as an open relay today is blocklisted quickly, and mail from it is rejected broadly. 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
Apex-domain coexistence is the problem this architecture exists to solve, and it turns on a distinction that trips people constantly: the domain that gets verified for sending is not necessarily the domain a 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. Both facts are true at once, which is why an argument about apex against subdomain usually turns out to be two people talking about different layers.
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.
We operate a dedicated inbound-mail forwarding relay for exactly this apex-domain coexistence, so mail sent to the apex still arrives while a subdomain carries the sending reputation.
Forwarding infrastructure has to fail safe, which is the property worth designing for. Ours is swallow-safe: a failure in the forwarding path cannot break the agent or chat path, so the thing customers use every day does not depend on the thing handling edge-case inbound mail.
The host doing this deliberately does not send marketing campaigns and is not an open relay. Keeping forwarding separate from bulk sending is a boundary rather than an accident, because the two have different abuse profiles and mixing them means one can compromise the other.