Email

Email on free hosting: what works, what won't

Why free hosts block outgoing mail, how to send it anyway through an HTTP API, and the DNS records that decide whether it reaches the inbox.

Ben Johnson · last checked 2026-09-21 · 4 min read

Email is the one part of hosting that behaves differently on a free plan, and the difference surprises people. Your site works, your database works, and then your contact form silently sends nothing. This page explains why that happens and what you do instead.

The short version: free hosts block the usual way of sending mail, on purpose, and the fix is to send through a different channel that they do not block. Once you understand that, the rest is DNS.

Why the normal way is blocked

Mail is normally sent over a port called 25, using a protocol called SMTP. Free hosts close that port. The reason is spam: free accounts are a favourite tool of spammers, and one abusive account can get a whole server’s address blocklisted, which would break mail for everyone else on it. Closing the port is how the host protects the shared reputation.

This is why PHP’s built-in mail() function does not deliver on a free host. It may not even report an error. It hands the message to a mail system that is not there, and the message quietly goes nowhere. If you have been debugging a contact form that “sends” but never arrives, this is almost always why.

How to send anyway

The way around a closed port is to not use the port at all. Instead of handing mail to the server, your code makes an ordinary web request to an email provider, and the provider does the sending. This is called an HTTP email API, and free hosts do not block it because it looks like any other web traffic.

Several providers offer this, and most have a free tier large enough for a contact form or sign-up confirmations, though the exact daily allowance varies by provider and plan. The full walk-through, with working code, is in send email without SMTP. This is the method to reach for; it is more reliable than server mail even on hosts that allow it.

This matters most on the free hosting tier, where the closed port is not a bug to work around but a deliberate part of how the platform stays usable for everyone. Treating an HTTP API as the normal way to send, from day one, saves you the detour of discovering the block the hard way.

Whether it reaches the inbox

Sending mail and getting it into the inbox are two different problems. Once your mail is going out, a set of DNS records decides whether the receiving side trusts it. The two that matter most are SPF, which lists who is allowed to send for your domain, and DKIM, which signs each message so it cannot be forged.

Without these, mail from your domain is more likely to be treated as suspicious and land in spam. With them set correctly, deliverability improves markedly, though no setup can promise the inbox every time. Your email provider gives you the exact records to add. To confirm they are live and correct, run your domain through the email DNS checker before you assume the problem is in your code.

Receiving mail is a separate job

Sending mail from your site and receiving mail at your domain are not the same service, and a free host usually provides neither by default. If you want [email protected] to receive mail, that is a mailbox service you point your domain’s MX records at, and it is independent of everything above. Setting one up does not enable sending, and enabling sending does not create a mailbox.

The whole email setup, in short

If you are wiring up mail for a site on free hosting:

1. Accept that server mail will not work, and do not fight the closed port.
2. Sign up with an HTTP email provider and use its API from your code.
3. Add the SPF and DKIM records the provider gives you.
4. Check those records with the tool before testing.
5. If you also need to receive mail, set up a separate mailbox service and its MX records.

That is the entire picture. Each step links to its how-to, and the mistake to avoid is step one: waiting for mail() to start working, which it never will.