Why not to run your own email server, and what to use instead

You have a domain, a server that runs your site, and someone tells you that you can put email there too. It sounds logical: one subscription less, everything in one place. Then a client calls to ask why they never received the quote. They did receive it, in Spam. Or they never received it at all and nobody knows where it went.

With email, sending is easy and arriving is hard. The rules are set by those who receive, meaning Gmail, Outlook and Yahoo, and they tightened them in 2024. A server of your own enters this game with no history, no reputation and all the responsibility on your shoulders.

Below you will find what the big providers require from a sender, how much a server costs in time that never shows up on the invoice, and the two services that do the job better than you would.

The problem is not sending, it is reaching the Inbox

Any server can send email. The protocol is old, open and asks no permission. What no server can guarantee is that the message will be accepted and placed in the Inbox. That decision belongs to the recipient’s server, and at Gmail, Outlook and Yahoo it is made on reputation: the reputation of the IP the message comes from and of the sender’s domain.

A new server starts with zero reputation, so the filters are cautious. Worse, the IP you got from the hosting provider was most likely used by someone else before. If that someone sent spam, the IP may be on blacklists before you send your first message.

And reputation is lost quickly. A contact form with no protection, used by bots to send thousands of messages through your server. An account with a weak password, broken into and put to work sending spam for a night. A single incident of this kind puts the IP and the domain on blacklists, and getting off them takes days. In the meantime, neither invoices nor quotes get through.

What Gmail, Outlook and Yahoo require from senders

Since 2024, Google and Yahoo have published clear requirements for anyone sending email in volume to their users, and Microsoft has followed the same direction. In short: SPF, DKIM and DMARC published in DNS, a spam complaint rate below a small threshold, one-click unsubscribe for newsletters, a valid PTR record for the sending IP and delivery over TLS. Google’s official list is in the email sender guidelines.

SPF: who is allowed to send on behalf of the domain

SPF is a list published in your domain’s DNS, in which you state which servers are allowed to send email with @company.ro addresses. When Gmail receives a message from you, it checks whether the server it came from is on the list. If it is not, the message is suspect. Without SPF, anyone can send email under your name and the recipient has no way to tell a real message from a forged one.

DKIM: the signature that proves the message was not altered

DKIM adds a cryptographic signature to every message, and the key used to verify it also lives in DNS. The recipient can confirm that the message left a server authorised by your domain and that it was not modified along the way. Without DKIM, messages carry no proof of authenticity, and filters treat them accordingly.

DMARC: what happens when SPF or DKIM fails

DMARC is the policy through which you tell the recipient what to do with messages that fail the checks above: accept them anyway (p=none), put them in quarantine (p=quarantine) or reject them (p=reject). DMARC also sends you reports on who has been sending on behalf of your domain and with what result. Without DMARC, SPF and DKIM are checks without consequences, and since 2024 the missing policy is itself a reason for rejection for bulk senders.

The rest of the list: PTR, TLS, spam rate and unsubscribe

PTR, or reverse DNS, means that your server’s IP answers with a domain name when asked; without it, the server looks like a home computer. TLS means the connection between servers is encrypted. The spam rate is the percentage of recipients who press “Report spam” on your messages, as measured by Google in Postmaster Tools. One-click unsubscribe applies to marketing messages and has to work from the message header, not only from a link in the footer.

What maintaining an email server actually means

Installing it is the easy part. An email server that works well requires, week after week:

• security updates for the mail server, the antispam and the operating system, applied on time;
• an antispam filter for what you receive and an antivirus one for attachments, with rules that go stale;
• blacklist monitoring, so you find out you have been listed before your clients do;
• queues of stuck messages, which fill up silently when a large recipient temporarily refuses you;
• disk space, because people never delete anything and the 2 GB mailbox becomes 40 GB;
• backups of the mailboxes, tested, not just configured;
• availability: when the server goes down on a Sunday evening, someone has to bring it back up.

None of this appears on the hosting invoice. All of it gets paid for, though, in the hours of someone in the company or of an external administrator, or in lost messages. In practice, a properly maintained email server costs more in time than the subscription you wanted to avoid.

Two different needs, two solutions

“The company’s email” actually means two things that have little in common. You put them on separate services.

People’s mailboxes

This covers contact@, sales@ and the address of each employee. These are mailboxes read by people, with replies, attachments and a calendar. For them, Google Workspace or Microsoft 365 are the natural choices: storage, shared calendar, two-step authentication, good spam filters, support and a delivery reputation built over years.

The site’s automated emails

Order confirmations, password resets, form notifications, automatically generated invoices. Nobody replies to them, but they have to arrive every time, and quickly. For these you use a transactional SMTP provider: SMTP2GO, Postmark, Amazon SES, Brevo and Mailgun are well-known examples. All of them give you what you do not have on a server of your own: a log of every message, delivery statistics, bounce reports. If a client says they never received the confirmation, you look up the address in the log and see right away whether it was delivered, bounced or marked as spam.

Why you do not mix them

Reputation is calculated per domain, not per mailbox. If you send a newsletter to a few thousand addresses from contact@company.ro and a few dozen people report it as spam, the reputation of the whole domain drops. The next day, the quote a colleague sends from their own address lands in Spam too. Campaigns belong on a platform built for that, with unsubscribe and clean lists; what an email marketing programme involves, done without damaging your reputation, is a separate discussion from infrastructure.

Why not PHP mail() from the web server

Most sites, WordPress included, send email by default through PHP’s mail() function. The web server thus becomes an improvised email server, without any of the conditions above. There is no authentication. There is no DKIM signature. On shared hosting, the IP is the same as that of dozens of other sites, and its reputation depends on the neighbours. And there is no log: the message leaves and you know nothing more about it.

The result shows up on almost every new site: password resets do not arrive, order confirmations land in Spam, form messages disappear. The fix is an SMTP plugin in WordPress, configured to send through the transactional provider you chose. Checking that it works is part of the site’s normal upkeep, just like updates.

Common traps

Even with good services, a few configuration mistakes keep coming up.

Sender addresses that do not exist. A no-reply@company.ro that rejects replies seems harmless, but every rejected reply is a negative signal, and the client is left without an answer. Worse: the administrator address in WordPress, where password resets and security notifications go, is sometimes an address that never existed or one belonging to a former employee. Check what is written in Settings and whether that mailbox is read by anyone.

SPF with too many “include” entries. The SPF check allows at most 10 DNS lookups. Each include: uses one, and the included services have includes of their own. With Google Workspace, a transactional provider, a newsletter platform and a CRM, the limit is easily exceeded and the SPF record becomes invalid, as if you did not have one.

DMARC on “reject” before checking every source. The strict policy is the goal, but set too early it stops the emails from the invoicing system or from the CRM you forgot you had. Start with p=none, read the reports for a few weeks, add every legitimate source to SPF and DKIM, then move up to quarantine and finally to reject.

Automated emails on the main domain. Many companies send transactional email from a dedicated subdomain, for example notifications.company.ro, with its own SPF and DKIM. If a form is abused or a store sends too much in one day, it is the subdomain’s reputation that suffers, not that of the domain people write from.

How to check it yourself

You do not need an administrator to find out what state your domain is in. Send an email from the company address to a personal Gmail account. Open the message, press the three dots and choose “Show original”. At the top you see three lines: SPF, DKIM and DMARC, each with PASS or FAIL. For the site, run the same test with a password reset or a test order. The message has to arrive DKIM-signed by the transactional provider, not by the web server.

There are also public DNS checking tools, free, where you enter the domain and see the SPF, DKIM and DMARC records with the mistakes marked: extra includes, wrong syntax, missing policies. And if DMARC is published with a reporting address, the reports tell you, source by source, who is sending under your name and how much of it passes the checks.

Checklist

• People’s mailboxes are on Google Workspace or Microsoft 365, not on the site’s server.
• The site’s automated emails go out through a transactional SMTP provider, with a delivery log.
• WordPress sends through an SMTP plugin, not through mail().
• SPF is published and stays under the limit of 10 DNS lookups.
• DKIM is active for every service that sends on behalf of the domain.
• DMARC is published, with a reporting address, and the policy was raised gradually.
• The administrator address in the site exists and is read by someone.
• Newsletters go out from a marketing platform, not from contact@.
• Automated emails have their own subdomain, with separate SPF and DKIM.
• “Show original” in Gmail shows PASS on all three.