How it works
A relay sits between something that composes a message and the server that accepts it for a recipient. The sending device authenticates to the relay, hands over the message, and the relay takes responsibility for delivery from there.
The relay's value is what it does after accepting: queueing, retrying temporary failures on a schedule, and reporting permanent ones back. A device that sends directly has to implement all of that itself, or drop mail silently when a receiver defers.
Submission
Submission is the first hop, where an authenticated client hands a message to the relay on port 587. The relay verifies credentials, applies rate limits, and accepts or rejects.
Authentication at this stage is what separates a relay from an open relay. A server that accepts and forwards mail from anyone is the configuration that made spam viable in the first place, and any host doing it today is blocklisted quickly.
Lookup
The relay resolves the recipient domain's MX records to find which server accepts mail for it, then connects to that server in priority order.
DNS is also where sending fails before it starts. A sending domain whose records are missing or unpropagated produces rejections that look like delivery problems and are actually configuration problems.
We put a DNS verification step in front of every connecting sending domain for exactly this reason. The subdomain is what gets verified, and the apex domain is what shows as the sender in the mail client. Chong on our team traced one launch where a list of 87 contacts sat in retries until DNS was ready, then every email went out. The relay treating unpropagated DNS as a retryable state rather than a failure is what saved that send.
Delivery
The relay opens a connection to the recipient's mail server and transmits. Acceptance returns 250, temporary failures defer and retry, permanent failures generate a bounce back to the return path.
Delivery is where authentication is evaluated. SPF, DKIM and DMARC are checked by the receiver at this point, and a message that fails alignment can be rejected outright regardless of the relay's reputation.
Common uses
Three cases account for most relay traffic. Applications sending transactional mail, devices that cannot run a mail client, and bulk sending that exceeds mailbox limits.
Nitrosend sits on the application side of that picture. We integrate with the major relays, SendGrid, Postmark and SES among them, so you keep ownership of the sending infrastructure while the platform handles composition, suppression and reporting above it.
Printers and scanners
Devices with scan-to-email cannot authenticate the way a modern application does. They frequently support only older TLS versions or basic authentication, which is precisely what mailbox providers are removing.
Port 587 with STARTTLS is the target configuration. If a device cannot manage it, relay through a server that can, rather than weakening the requirement to suit the hardware.
Bulk mail
Bulk sending through a relay avoids the per-mailbox limits that mailbox providers apply to personal accounts. Those limits are sized for a person, and an application will exhaust them quickly.
Volume alone does not make sending safe. Ramping matters more than the ceiling: a domain with no history that suddenly sends thousands of messages looks exactly like a compromised account. For Gmail in particular, George, our CEO, has watched domain reputation matter more than IP reputation, and IP reputation carries a 120-day memory. A bad month follows you for four.
George ran the bulk playbook at SmartrMail, which sent billions of emails for 12,000 customers. Large sends went out in batches of 5,000 with a pause on any deliverability trouble. His longer-term practice is blunter still: send from an alternate domain and warm it up, so a Spamhaus listing caused by a spammer never touches your main domain. Nick on our team hears the enterprise version of the same instinct constantly, requests to rotate or throttle sends across multiple domains.
Security
A relay's security model protects two things: your domain from being used by someone else, and the relay's shared reputation from being ruined by any one sender.
Authentication and rate limiting do the first. Abuse monitoring does the second, and it is the reason a new account cannot send its full allowance immediately.
We have built multiple systems and monitoring to prevent spammers from impacting our sending IPs and domains, and that work never stops. When I finished the deliverability layer and the DNS layer and we switched sending to SES, our approval came with a 50,000 per day cap, the same starting cap Mailgun gives. At that ceiling one big sender can leave the queue taking days, which is exactly why per-sender limits and abuse gates exist on a shared relay.
How a relay is kept from becoming an open relay
An open relay accepts mail from anyone and forwards it anywhere, and it is the single failure that turns a mail server into spam infrastructure. Closing it is not one setting but a stack of constraints, and it is worth seeing a real one rather than a principle.
Ours accepts mail only from our own authenticated control plane, on TCP 2525, and only after the upstream provider has already accepted and validated the inbound message. The port itself is firewall-restricted to that one host, so nothing else on the internet can open a conversation with it.
Every route carries a signature. One-recipient route and MX snapshots are HMAC-signed, and the relay rejects unsigned or replayed requests outright, alongside arbitrary destinations, extra recipients, loops back into our own MX, and multiple forwarding hops. Each of those is a specific abuse route rather than a general precaution.
The design choice underneath is that each accepted message becomes one durable single-recipient delivery obligation, forwarded to the customer's captured pre-cutover MX host. Single-recipient is doing real work there: a relay that accepts one message for many recipients is a relay that can be made to fan out, and fan-out is what an abuser wants.
Bounce and reply handling need their own machinery. SRS and VERP correlate delivery status notifications back to the original send, ARC preserves the authentication result validated at ingress so a forwarded message does not fail downstream, and Rspamd inspects the relay traffic itself. Forwarding breaks SPF by design, and ARC exists precisely to carry the earlier verdict across that break.
The host running this does not send marketing campaigns and is not an open relay. Keeping forwarding infrastructure separate from bulk sending is deliberate: they have different abuse profiles, different reputation consequences, and mixing them means one compromises the other.