Reference
Everything, precisely.
Written from the running configuration, not from memory. Every value, limit and response string below is what the relay will actually do — including the parts that are inconvenient to us.
Connection
| Hostname | mail.send25.net |
|---|---|
| Ports | 25 · 587 |
| Greeting | 220 mail.send25.net ESMTP |
| HELO/EHLO | Required. The relay refuses to proceed without one. Any name your device offers is accepted — it does not need to resolve. |
| Advertised | PIPELINING · SIZE · STARTTLS · ENHANCEDSTATUSCODES · 8BITMIME · DSN · SMTPUTF8 · CHUNKING |
| Not offered | VRFY (disabled — returns 502 5.5.1) and ETRN (removed from the capability list). Neither has any use on an outbound relay, and both are reconnaissance tools. |
| Idle timeout | 300 seconds per command |
Which port, and why
| Port 587 | Username and password. TLS mandatory. The connection must upgrade to STARTTLS before we will accept credentials or mail. Anything unauthenticated is refused outright. Use this wherever the device supports it — a credential can be revoked for one machine without touching any other. |
|---|---|
| Port 25 | Your IP address is the credential. No login. For hardware that cannot do modern authentication — which is most of why this service exists. TLS is offered and used if the device supports it, and not required if it doesn't. You tell us the source address; anything else is refused. |
Port 25 is not a lesser option. Mail sent through it is signed,
authenticated at the DNS layer and delivered identically. The only difference is how we decide
the connection is yours. We keep it open because a fifteen-year-old copier cannot be made to do
OAuth, and replacing the copier is not a mail problem.
Encryption
| Protocols | TLS 1.2 and TLS 1.3.TLS 1.0 and 1.1 are refused — deprecated by RFC 8996 and forbidden under PCI-DSS. |
|---|---|
| Negotiated | TLSv1.3 · TLS_AES_256_GCM_SHA384 |
| Certificate | CN=mail.send25.net, Let's Encrypt, renewed automatically |
| On port 587 | Mandatory. No STARTTLS, no mail. |
| On port 25 | Opportunistic. Used whenever the device offers STARTTLS; not required. |
| Onward delivery | TLS is attempted for every outbound hop and used whenever the receiving server supports it. |
"Encryption: off" on an old device is not a security failure on your part.
A scanner on your own LAN, talking to a relay that then encrypts the onward hop, is a reasonable
trade — and it is a far better position than the mail not going at all. Turn TLS on wherever the
device can manage it; where it cannot, port 25 is why we are here.
Authentication
| Mechanisms | PLAIN · LOGINBoth are offered only inside TLS, so the password never crosses the network in clear. Most device firmware calls this "Normal password", "Basic" or simply "Login". |
|---|---|
| Username | The full string we issue, including the @mail.send25.net part.Some device firmware truncates at the @ sign and then reports "authentication failed". If you see that, check what the field actually kept. |
| One per device | We issue a separate credential per machine, so a compromised scanner is revoked on its own. |
| Port 25 | No credential. The source IP address authorises the connection. |
What we do to your message
Deliberately very little. The relay is not an editor.
| Added | DKIM-Signature — a cryptographic signature over the message, using your domain. |
|---|---|
| Added | Received — one hop, recording that we handled it. Required by the standard. |
| Untouched | Subject, body, attachments, From, To, Reply-To, and every other header. We do not add footers, tracking pixels, link rewriting, or unsubscribe headers. |
| Not stored | The content of your message is never written to our database. It exists in the mail queue on disk only until it is delivered. |
DKIM signing
| Selector | mr2026 |
|---|---|
| Key | RSA 2048-bit, generated on our hardware, one per domain. The private key never leaves the relay. |
| Signing domain | Taken from the From header, not the envelope.This is what makes relayed mail pass DMARC alignment — including strict alignment (adkim=s), which many providers quietly fail. |
| Mismatch | If the From header and the envelope sender disagree, we refuse rather than sign something misleading. |
| No key, no signature | We only sign domains we hold a key for. An unknown domain cannot be signed into legitimacy. |
Limits
| Message size | 25 MB (26,214,400 bytes) including attachments and encoding overhead.Base64 inflates attachments by about a third, so a 20 MB scan may not fit. Scanners that produce large PDFs are the usual cause. |
|---|---|
| Recipients | 1,000 per message |
| Sending quota | Per hour, per day and per month — set per customer, visible in your console. |
| Bad commands | After 5 errors the relay begins delaying responses by 5 seconds; after 10 it closes the connection. Normal clients never reach this. |
What happens when you hit a quota
Two behaviours, chosen per customer. Defer is the default, and the right one for almost everybody:
| Defer (default) | 451 — a temporary failure. Your device holds the message and retries. Nothing is lost. It goes out as soon as the window rolls over. |
|---|---|
| Reject | 550 5.7.1 Sending quota exceeded — a permanent failure. The message bounces immediately.Choose this when you would rather a runaway system fail loudly than quietly queue thousands of messages. |
Windows are wall-clock, not rolling: the hourly counter resets on the hour, the daily at midnight, the monthly on the 1st. Counters are per customer, so nobody else's traffic can consume your allowance.
Response codes
Every rejection the relay itself produces, verbatim, with the actual cause. Anything not on this list came from the receiving server, not from us.
| 554 5.7.1 Client host rejected: Access denied |
We don't recognise where you're connecting from. On port 25 that means the source IP isn't on your allow-list — often because the office broadband address changed. On 587 it means no valid credential was presented. Fix: confirm your current public IP and tell us, or switch that device to 587 with a username and password so the address stops mattering. |
|---|---|
| 553 5.7.1 You are not authorised to send as this domain |
The connection is yours, but the address you're sending as is not. The domain in your From address isn't verified against your account. Fix: add and verify the domain in your console. This is also the message an attacker would get — it is the control that stops another customer sending as you. |
| 550 5.1.1 Recipient suppressed |
We're refusing to mail an address that has already hard-bounced. Repeatedly sending to dead mailboxes is one of the fastest ways to lose sending reputation, so we stop it on your behalf. Fix: correct the address. If it was suppressed in error, remove it from the suppression list in your console. |
| 550 5.7.1 Sending quota exceeded |
You've reached your hourly, daily or monthly limit, and your account is set to reject rather than defer. The message names which window and what the limit is. Fix: wait for the window to roll over, or ask us to raise the ceiling. |
| 451 | Temporary — try again shortly. Usually the quota with defer behaviour. Your device will retry on its own; no action needed and nothing is lost. |
| 502 5.5.1 VRFY command is disabled |
Something tried to enumerate addresses. Deliberate, and not an error you will see from a mail client. |
| 552 | The message exceeded 25 MB. Almost always an oversized scan — reduce the resolution or split the document. |
| 535 | Authentication failed. Wrong password, or the device truncated the username at the @. |
A code beginning 4 is temporary; a code beginning 5 is permanent. That
single distinction resolves most "is my mail lost?" questions — a 4xx means the message is still
queued on your device and will go out by itself.
Delivery, retries and bounces
What happens after we accept a message, minute by minute.
| Normal delivery | Handed to the recipient's mail server within seconds. We deliver direct to their MX — there is no third-party sending platform in between. |
|---|---|
| First retry | After 5 minutes, if the receiving server is temporarily unavailable. |
| Backoff | Retry intervals grow to a maximum of about 67 minutes. |
| Giving up | After 5 days of failed attempts, the message bounces back to the sender with the reason. |
| Hard failure | A permanent rejection (bad mailbox, domain refuses mail) bounces immediately — no retries. The address is then suppressed. |
If the relay is unreachable, your mail is delayed — not lost. SMTP is
store-and-forward: your printer or application holds the message and keeps retrying, typically
for days. That is a property of the protocol rather than a promise from us, and you can confirm
it against your own equipment.
The suppression list
An address that hard-bounces is added automatically and blocked from future sends. You can see and edit the list in your console. It is the one place we keep recipient addresses beyond 30 days, because a suppression that expires is a suppression that stops working — and the whole point is to stop mailing an address that does not exist.
What we record
| Per message | Sender, recipient, time, size, and the delivery result — plus the receiving server's own response, which is what tells you why something failed. |
|---|---|
| Never | Subject, body or attachments. There is no column in our database that could hold them. |
| How long | 30 days, then deleted by a scheduled job — enforced, not intended. |
| Who can see it | You, for your own account. Every administrative action is recorded in an audit trail you can read and export. |
Relaying from a mail server
If you already run a mail server and want its outbound mail to leave through us, point it at mail.send25.net as a smart host. Full configuration for Postfix and Microsoft 365 is on the integrations page.
Something here not matching what you're seeing? Tell us — support@send25.net. This page is generated from the relay's real configuration, so if it disagrees with reality, one of the two is a bug and we want to know which.