Using your ISP's SMTP server for business email: why it goes wrong
Your internet provider's SMTP server was built for a family's private mailbox, not for a company's mail. As soon as your webshop, invoicing package or CRM sends through it, you run into sending limits, a reputation you share with thousands of other customers, and no authentication for your own domain. For anything that sends mail automatically, the answer is an SMTP relay with a separate login per application.
Why people try it anyway
It is tempting. The settings are on the provider's website, they work immediately on the owner's laptop, and they cost nothing extra. So someone enters the same server name in the till system, the webshop and the invoicing program. For the first few weeks it appears to work. The problems arrive when volume grows or when a recipient tightens its rules.
Problem 1: sending limits
Providers such as Proximus and Telenet typically cap the number of messages a customer may send per hour or per day through their server, and sometimes the number of recipients per message. Those caps are generous for someone emailing relatives, and far too tight for a webshop on a busy day or an invoicing package pushing out a hundred invoices on the first of the month. Whatever exceeds the cap is refused or quietly delayed. Your customer notices the invoice never arrived; you notice when they phone.
Problem 2: a reputation that is not yours
A provider's outgoing server sends on behalf of hundreds of thousands of subscribers at once. The reputation of that IP address is set by all those customers together, including the infected PC sending spam without its owner knowing. If that server is temporarily blocked by a major recipient, your order confirmation does not arrive either. You can do nothing about it, and nobody tells you.
Problem 3: no authentication for your domain
This is the core issue. If you send from info@yourcompany.be through the provider's server, the message claims to come from your domain while leaving from a server that is not in your SPF record. And that server certainly does not add a DKIM signature for your domain. To Gmail, Outlook and most business mail servers, that is exactly what forgery looks like. The message is filed as spam or refused, and your wording has nothing to do with it. How the three records work together is explained on our SPF, DKIM and DMARC page.
Problem 4: you see nothing
A provider's server gives you no log. You do not know which messages were accepted, which bounced and which vanished into quarantine at the recipient. When a customer complains, there is nothing to check. For private mail that is no concern; for a company sending invoices and order confirmations it is.
Problem 5: it only works from your own connection
Many providers only accept their SMTP server from their own network, or otherwise require a separate login. Move your webshop to a hosting company or run your CRM in the cloud and the connection drops. That is often the moment someone discovers the company's mail had been hanging off a home connection for months.
When a relay is the answer
As soon as something other than a person sends mail. A relay is a sending server your applications use with their own login, and it sends with correct SPF and DKIM authentication for your domain. In practice that means:
- No hourly or daily cap that blocks your invoicing on the first of the month, but a volume tier that fits your business.
- A separate login per application: webshop, accounting and CRM each get their own access, which you can revoke individually when a supplier changes.
- A log per message: accepted, delivered, bounced or refused, with the reason.
- Authentication set up from the dashboard, so your domain can prove to the recipient that the message really is yours.
- A connection from anywhere, including your webshop's hosting or a cloud application.
Your staff, meanwhile, keep using their familiar mail program. A relay is for automated mail, not for daily correspondence.
What you can check today
Open the settings of your webshop, your invoicing package and your CRM and look at the outgoing server. If it is your internet provider's, you have found the cause of your delivery problems, even if it still seems to work today. Then send a test message to a Gmail address and an Outlook address and see where it lands. Your own mailbox is not a good test: it already trusts your domain.
Frequently asked questions
So I should never use my provider's SMTP server?
For the mail of a home connection it is fine. For a company's automated mail, with your own domain as sender, it is not.
Do I need to switch internet providers?
No. Your connection stays as it is. You only change the outgoing server in the applications that send mail automatically.
Do I need to change my DNS?
Yes: the relay belongs in your SPF record and signs your mail with DKIM. Both are prepared from the dashboard; it is a one-off job.