Everything people ask us.

An outbound SMTP relay for the equipment and software in your building that needs to send email — printers, scanners, backup servers, accounting packages — and can no longer do it through Microsoft or Google.

We take those machines exactly as they are, sign their mail properly so it reaches the inbox, and keep no copy of what they send.

Microsoft and Google switched off the old, simple way of sending mail — a plain username and password over an unencrypted connection, or no credentials at all. Modern authentication replaced it. Your copier was configured years ago and has no idea any of that happened; it keeps trying the only way it knows.

Nothing broke on your end. The rules changed underneath you.

No. Nothing about your mailboxes changes — not your provider, not your addresses, not your passwords, not where staff mail arrives.

send25 handles outbound mail from equipment and software. Your people carry on using Microsoft 365, Google Workspace or whatever you have now, untouched. The two coexist deliberately: adding our records to DNS does not affect how your staff mail is authenticated, because DNS is additive.

The DNS guide explains exactly what each record does and why it cannot disturb your existing email.

Yes — it comes from your domain, your address. We sign it cryptographically as you, which is the part that makes it trustworthy to Gmail and Outlook. Recipients never see our name, and replies come straight back to you.

Most sites are sending the same day. The work is: we approve your account, you publish three DNS records, and someone changes the SMTP settings on the device. The DNS records are the slow part, and only because DNS takes a few minutes to propagate.

Yes. The equipment can be anywhere — the relay just needs to be reachable over the internet. Being in St. John's matters for where your data lives and for being able to get a human on the phone, not for where your copier sits.

Yes, and this is the entire reason we exist. We accept plain connections and older encryption on port 25 — then re-send everything onward using modern encryption. The old machine never has to change.

Every large email platform refuses these connections outright. We don't.

Not a problem at all. We issue a username and password per device instead, and those work from any connection — including one whose address changes.

A fixed IP is only a convenience: it saves typing credentials into a control panel, and it is the fallback for hardware too old to authenticate at all. If you're on a dynamic address and using the IP method, be aware that a router reboot can change it and stop mail abruptly — trap 6 covers the symptom.

No fixed cap. We issue a separate credential per device, so a compromised scanner can be revoked on its own without disturbing anything else — that isolation is the reason for per-device credentials rather than one shared login.

What is capped is total volume, agreed per customer. Twenty devices sending a few scans a day is unremarkable; one device sending fifty thousand messages a month is a different conversation.

Those are some of our favourite customers, because nobody else will take them.

Alarm panels, building management systems, door controllers, industrial monitoring, older NAS units — anything with an SMTP settings page works. Much of that equipment can only do port 25 with no encryption and no login, which is precisely why we still offer it.

If the device has a field for "mail server" and one for "from address", it will work. See which port your device can manage.

Yes, and it's about half of what the service does. Anything that can be told an SMTP server, port and credential will work — accounting packages, ERP systems, backup software, the NAS, alarm and monitoring systems, a WordPress contact form, a script somebody wrote in 2014.

We publish working configuration for WordPress, Synology, Veeam, UniFi, Home Assistant, Grafana, PowerShell, Python, PHP, Node and msmtp on the integrations page — copy-paste, not API documentation.

If yours isn't listed, it still almost certainly works: tell us what it is and we'll work it out with you.

Yes. Point it at mail.send25.net as a smart host and its outbound mail leaves through us — signed and authenticated — while everything else about it stays as it is.

Full working configuration for Postfix (including the square brackets that stop it looking for an MX that doesn't exist) and for a Microsoft 365 connector is on the integrations page.

If you're routing an entire M365 tenant's outbound mail through us, talk to us first — it's supported, but it changes your sending profile substantially and interacts with your limits.

Because otherwise Gmail and Outlook have no way to tell your mail apart from someone forging your company's name. The records let us sign your mail as you — that signature is what puts it in the inbox rather than the junk folder.

We generate the exact values, show you what to paste, and then check them against live DNS so you're not guessing whether it worked.

Whoever does — your web developer, IT provider, or domain registrar — can add them in a couple of minutes. We give you a page you can forward to them with the exact records on it.

No. The records we add are additional, not replacements. Your existing mail flow keeps working exactly as it does now. If you already have an SPF record we merge into it rather than overwrite it — and we show you the merged result before you publish anything.

Usually yes, and it is usually DNS. Your console checks your live records per domain and names precisely what is missing — an unsigned or unauthenticated message is far and away the biggest cause of junk placement.

If all three records are green and it still happens, send us one of the messages with full headers (Show original in Gmail, Properties → Internet headers in Outlook). The receiving server states its verdict in there, and we will read it with you.

Two causes we cannot fix from our side: mail the recipient's own organisation has filtered by policy, and content that genuinely looks like bulk marketing. We will tell you honestly which one you have rather than adjust settings and hope.

We notice, and stop sending to it automatically. Repeatedly mailing dead addresses is one of the fastest ways to damage a sender's reputation, so we suppress them for you. You can see the list and remove anything you know is valid again.

No. Every account is locked to the domains it has proven it owns, and we check that on both the technical sending address and the visible From address a recipient sees. An attempt to send as someone else's domain is rejected outright and logged.

Before any domain can send at all, you publish a one-time record proving you control it. Approval alone isn't enough — that's what stops someone signing up claiming a domain that isn't theirs.

No. We keep delivery records — who it went to, when, how big, and whether it arrived — not the contents. Enough to answer "did that invoice actually go out on the 3rd?", and nothing more.

Thirty days. After that the delivery records are deleted automatically — a job runs every night and removes anything older, so it happens whether or not anyone remembers.

We keep it short deliberately. Data we no longer hold cannot be lost in a breach, handed over, or sold. If you need a longer record than that, your own sent items are the right place for it — not our database.

On our own hardware in St. John's, Newfoundland. Not a rented cloud region, not a reseller account — a machine we own, in the province.

Your mail does not leave the province on its way out, and the only government that can compel us to produce anything is Canada's, through a Canadian court. Most email platforms process everything in the United States or Europe regardless of where you are.

The trust page sets out exactly who can compel us and what we hold — including the parts that are inconvenient to us.

Two-factor authentication is mandatory on every account — not optional, not encouraged. Sign-in can be restricted per account by network, repeated failures lock the account automatically, and every administrative action is written to an audit trail you can read and export.

Invitations are claimed with a single-use token sent to the address, so knowing someone's email is never enough to take their account. Sessions expire on idle, and a password reset immediately invalidates every existing session.

More on how we handle access and data on the trust page.

It hits your sending limit and stops. Because limits are per customer, it cannot spend anyone else's allowance or damage anyone else's delivery — that containment is the main reason the limits exist.

We are alerted before you would notice. Any single device can be cut off on its own: if it uses a username and password we revoke that one credential, and every other device carries on untouched. That is the practical argument for port 587 over an IP allow-list where the hardware can manage it — an allow-listed address covers everything behind it.

Addresses that hard-bounce are suppressed automatically, so a compromised device also cannot burn your reputation by hammering dead mailboxes.

Hourly, daily and monthly, set to suit your normal traffic — generous enough never to interrupt an ordinary office, tight enough to cap a device stuck in a loop. You can see your current usage against your limit in the console at any time.

Mail is held and retried, not thrown away. Your device gets a temporary response and tries again later, so nothing is lost. We're alerted, and if the new volume is legitimate we raise the limit.

This matters more than it sounds: several large platforms silently discard mail once you pass a quota. Your device reports success and the message simply never arrives.

25 MB per message, including attachments and encoding overhead.

That last part catches people out: email encoding inflates attachments by roughly a third, so a 20 MB PDF arrives as about 27 MB and is refused. Colour scanning at 600 dpi produces enormous files — dropping to 300 dpi or greyscale typically cuts it by three-quarters with no practical loss on a document.

The device reports this as error 552. See the size trap for the full explanation.

Three things, and only the second involves anyone outside your building:

1. Tell us your sending domain and how your equipment should identify itself — a username and password, or your office IP address. 2. Publish three DNS records. Your console shows exactly what to add and checks them live; the DNS guide has step-by-step instructions for Cloudflare, GoDaddy, Microsoft 365, Azure, Route 53 and others. 3. Change the SMTP server on each device — see the setup guide.

Nothing changes for your existing mailboxes at any point, and nothing happens until you point a device at us. Start with one machine that nobody will miss for an afternoon.

Point the equipment somewhere else and delete the DNS records. That is the whole exit.

Nothing of yours is held here. The domain is registered to you, the DNS lives in your zone under your control, the equipment is yours, and there is no data of ours embedded in any of it. We cannot make leaving difficult even if we wanted to — that is a property of how the service is built, not a promise.

No notice period and no "contact your account manager" step. If you want your delivery records first, export them from the console before you go.

Either way. The console walks you through it, the setup guide covers the common copier brands with the specific traps each one has, and the DNS guide has click-by-click instructions for every major provider.

If you would rather someone just did it, say so when you request access — that is a conversation, not an upsell. And if you get halfway and something argues with you, email support@send25.net with the make and model and the exact error text. You will not be the first person whose copier has picked a fight with a mail server.

Your mail is delayed, not lost. SMTP is store-and-forward — your printer or application holds the message and keeps retrying, typically for days. A relay outage postpones delivery; it does not discard anything. That is a property of the protocol you can verify against your own equipment, not a promise from us.

We commit to 99% availability — about seven hours a month. We publish 99 rather than a longer string of nines because there is one relay node, and we would rather keep a number than have it read well. A second node on separate hardware is the next infrastructure step; until it exists we are not claiming it.

Automated monitoring runs continuously and alerts a real person. Our published commitment is same business day, Newfoundland time, plus an emergency contact for genuine emergencies.

We are not going to claim a staffed 24/7 operations centre, because there isn't one. Before that counts against us, compare it honestly with your current escalation path at a large provider — the realistic alternative is a web form and a queue.

A fair question about any small provider, and it deserves better than reassurance.

The structural answer is that you are never locked in. The DNS records pointing mail at us live in your zone, under your control, and you can repoint them at another provider in minutes without asking anyone. There is no proprietary format holding your data — we run standard Postfix and rspamd, which any competent mail administrator can take over.

That is the guarantee we can actually make. A named second engineer is on the roadmap; when there is one, this answer will say so.

No SOC 2, and we will be straight about why. A Type II audit runs tens of thousands of dollars up front plus an annual fee, on a timeline measured in quarters. At our size that cost lands on your invoice and what it buys you is a PDF.

What we offer instead is the thing SOC 2 is a proxy for: you can inspect the actual behaviour. Send a message and read the headers. Look up our reverse DNS. Ask your IT consultant to interrogate the configuration on a call with us — we would rather answer than be taken on faith.

If your procurement process hard-requires SOC 2, we are the wrong vendor and we will tell you that on the first call rather than waste your time.

Yes, and it is a common arrangement. We can issue them a console login scoped to your account so they can add devices, publish DNS and read your delivery log — without being able to see any other customer.

Every administrative action is recorded in an audit trail you can read and export, so delegating access does not mean losing visibility of what was done.

Three practical differences, and one philosophical one.

We take port 25 with no authentication. The large platforms do not, which is why half the equipment in your building stopped working. That alone decides it for a lot of people.

We do not store your messages. Postmark keeps the body of every email for 45 days by default and it cannot be turned off. Mailchimp's transactional product keeps the HTML and text for 30 days, and Intuit's privacy statement permits using personal information to train AI models. We keep delivery metadata for 30 days and no content at all, ever.

We are Canadian-owned and Canadian-run. Mailgun is Swedish-owned, but you contract with a Texas corporation under Texas law. Neither Postmark nor Mailchimp Transactional offers a Canadian region at all.

And the philosophical one: they are built for volume, we are built for the mail your business cannot afford to lose. We cap customers deliberately. If you need to send half a million marketing emails a month we are the wrong service, and we will say so.

We commit to 99.9% of accepted mail delivered, measured as accepted by the receiving mail server. That holds because of six things on our side: every message DKIM signed for your domain, SPF and DMARC aligned, a dedicated IP with matching forward and reverse DNS, delivery straight to the recipient's server with no shared platform in between, per-customer limits so nobody else can spend your reputation, and automatic suppression of addresses that have hard-bounced.

What no provider controls is what a recipient's own spam filter decides — anyone telling you otherwise is selling something. What we can tell you is that nothing on our side will give it a reason.