SMTP relay or email API: which one, and when both.

Published 18 October 2026

Most companies never ask whether to connect over SMTP or use an API; they take whatever their software offers. That is fine, and often right. But when you do have the choice, it is worth two minutes, because the answer depends on what is sending the mail, not on which one sounds more modern.

What the two actually are

SMTP is the protocol mail servers have spoken to each other since the eighties. Your application, or your mail server, opens a connection to our relay on port 587, authenticates with a relay login, hands over the message, and the relay takes it from there. Every language, every framework and every piece of business software knows how to do this. The configuration is three fields: server, port, login.

The submission API is the same relay reached over HTTPS. You send one HTTPS request with the message as JSON, or a batch of up to 500 messages in one call, and get a response back that tells you what was accepted. No SMTP library, no connection handling, and an idempotence key per message so a retry after a timeout never sends the same invoice twice.

Both land on the same servers, go out from the same IP addresses, and show up in the same delivery log. The choice does not change your deliverability. It changes how your code talks to us.

When SMTP is the right answer

• Software you did not write. An ERP, a payroll package, a webshop platform, a monitoring tool. They all have an "outgoing mail server" screen, and that screen speaks SMTP. You fill in tlsrelay.teneo.be, 587, your relay login, and you are done.
• An existing mail server. If your Exchange, Postfix or Exim already handles your company's mail and you want its outbound traffic to leave from your own warmed IPs, you set our relay as its smart host. One line of configuration.
• A mature application that already sends over SMTP. Switching to an API gives you nothing you do not already have; keep the code that works and point it at us.
• Large attachments. SMTP streams the message; a 15 MB PDF is not something you want to base64 into a JSON body. The relay itself sets no limit, but stay under 20 MB per message: several large mailbox providers refuse anything bigger, whatever path it took.

When the API is the right answer

• You are writing the sending code today. One HTTPS call is easier to write, test and log than an SMTP session, and the response is structured.
• You send in bursts. A batch of 500 messages in one request, say the payslips of one company at month end, is one round trip instead of five hundred connections, and the batch is accepted and on its way within seconds.
• You run in an environment that blocks or frowns on outbound port 587. Serverless functions, locked-down containers, corporate networks. Outbound HTTPS is always open.
• Retries matter. Your job scheduler re-runs a failed task; with the idempotence key the relay recognises the message it already accepted and does not send it again.
• You want the result in your own system. The response tells you per message whether it was accepted, so your application can store that next to the order or the employee record.

What our customers actually do

Nearly all of them send over SMTP, and have done so for years. Their payroll software, their shop platform, their ticket system and their mail servers all speak it, and nothing about a relay gets better by rewriting code that works. The API is the newer door, used by teams that build their own sending today and want batching, retries and a structured answer per message. Both doors lead to the same room: one relay login family, the same IP addresses, the same delivery log, one invoice. Nothing has to be chosen once and for all; a company can connect its platform over SMTP in five minutes and move one high-volume flow to the API later, side by side.

What is the same either way

• The IP addresses. Dedicated to you once your flow is real, warmed up by us, shared with nobody.
• The delivery log. Every message, the IP it left from, and the receiving server's own answer in plain words, kept for a year.
• The sending domains. SPF include and DKIM selector are set once per domain and apply to both paths.
• The people. A ticket in the console reaches the people who run the servers, whichever path the mail took.

What is different, in one table

How to decide in one minute

If the thing that sends mail has a settings screen, it is SMTP. If it has a code base you maintain, it is the API. If you have both, use both. And if you are not sure, start with SMTP; it is five minutes of configuration and you can add the API next month without touching the first part.

The SMTP settings and the API reference are in the console documentation: Submission API docs and API v4 docs. If you want to talk it through for your case, write to us; we answer within one working day.