E-mail

Transactional email: why the emails from your website end up in spam

Written by Sam Serrien · October 17, 2026

A glass envelope follows a green line of light from a browser window to an inbox, past a shield with a checkmark

A customer fills in your contact form and never hears back. Not because you did not want to answer, but because the notification never reached your inbox. Or a customer orders from your web shop and only finds the confirmation a week later, in the spam folder. These are two of the email problems we see most often at small businesses, and they usually share the same cause: the way your website sends email. In this article I explain what transactional email is, why it so often goes wrong and how to set it up properly.

What is transactional email?

Transactional email is email your website or application sends automatically, in response to something a user does. Think of:

A notification that someone filled in your contact form
An order confirmation, shipping notification or invoice from your web shop
A confirmation of a sign up or registration
A link to reset your password
A login code or an appointment reminder

The difference with a newsletter matters. A newsletter goes to a whole list at once, at a moment you choose. A transactional email goes to one person, at the moment that person asked for it. That is why the recipient expects it, and why it has to arrive right away.

Why it so often goes wrong

A website can send email in several ways. The ways we come across most often are also the ways that cause the most problems.

1. Straight from the web server

Many websites, WordPress sites in particular, send email through the server's built in mail function by default. Technically that works, but those emails almost always lack the checks Gmail and Microsoft use to verify that an email really comes from your domain. On top of that, you often share the server with other websites. If one of them sends spam, the reputation of the whole server suffers, and so does that of your emails.

Watch out

Gmail and Microsoft have become a lot stricter in recent years. Email without correct SPF, DKIM and DMARC is rejected or sent to spam more and more often. In Improving email deliverability I explain what those three do.

2. Through your regular mailbox

A second common setup: your website logs in to your own mailbox over SMTP, for example info@yourcompany.com, and sends its emails that way. That seems convenient, but it comes with a few risks:

Your mailbox password is stored in your website. If your website gets hacked, the attacker also gets access to your mailbox.
Your mailbox has sending limits. A busy day in your web shop, or a spam bot hammering your form, and suddenly you cannot send email yourself.
Change the password and your website stops sending. And you usually only notice when a customer calls.

3. The contact form that pretends to be the visitor

A classic mistake with contact forms: the email is sent with the visitor's address as the sender, so you can simply click "reply". But then your website sends an email on behalf of, say, a Gmail address, from a server that has nothing to do with it. To Gmail and Microsoft that is exactly what phishing looks like, so the email gets rejected.

The right approach

The email is sent from an address on your own domain (or your email service), and the visitor's address goes in the "reply to" field. When you click reply, your answer still goes to the visitor.

What a transactional email service does differently

A transactional email service is a mail server meant only for sending email from websites and applications. Your website connects to it over SMTP, just like an email program does, but with its own credentials that are separate from your mailbox.

Through a transactional email service

SPF, DKIM and DMARC set up correctly
Sending servers that only send transactional email
Separate credentials, independent of your mailbox
Volume matched to what your website sends

Through the web server or your mailbox

Authentication is often missing
Reputation shared with other websites
Your mailbox password stored in your website
The sending limits of a regular mailbox

Your mailbox is for conversations between people. A transactional email service is for the emails your website sends automatically. Keeping them apart makes both work better.

A short checklist for your website

Not sure whether your website sends email properly? Go through these points:

Fill in your own contact form. Does the notification arrive within a minute, and not in spam?
Is the sender an address on your own domain, and not the visitor's address?
Is the visitor's address in the "reply to" field?
Does your website use its own SMTP credentials, and not the password of your regular mailbox?
Are SPF, DKIM and DMARC set up for the domain your website sends from?

If you cannot answer "yes" to all five, chances are that emails will get lost sooner or later.

How to set it up with Inboxx Send

With Inboxx Send we offer transactional email over SMTP, in two versions:

Send Lite (€ 2 per website per month) is for contact forms and other notifications that end up with you. The email is sent from a shared GeNx sender address, with the visitor as reply address. You do not need to change anything in your DNS. Up to 1,000 emails per month, plenty for any contact form.
Inboxx Send (from € 9 per month for 5,000 emails) is for emails to your customers: orders, invoices, sign ups and password resets. They are sent from your own domain, and we set up SPF, DKIM and DMARC for you.

It works with WordPress (through an SMTP plugin), Laravel, Kirby, most web shops and any application that can send email over SMTP. An API is in the works.

Already have a mailbox with us?

Then still do not let your website send through that mailbox. With Send Lite or Inboxx Send, your mailbox and your website each stay in their own lane.