No MX record. Nothing. That was the whole answer when I finally ran a DNS lookup, on 19 September 2026, against the domain of one of my own websites, a site that has printed a contact address on its contact page since the day it went live. Every message anyone has ever sent to that address went somewhere I cannot reconstruct, and almost certainly nowhere.
That is the least professional thing on any site I run, and it survived because email on your own domain fails in a very particular way: silently, from the outside, in a system that keeps reporting that everything is fine. So rather than another comparison of mail providers, this is an audit of the five domains I own, what I found on each, and the four checks that would have caught all of it in about two minutes.
Five domains, one correct configuration
| Domain I own | MX | SPF | DMARC |
|---|---|---|---|
| This blog | mx1 and mx2 at the host, priority 5 and 10 | Yes, host’s include, ends ~all | Yes, p=none |
| My second blog | None | None | None |
| My agency site | None | None | None |
| My SaaS application | None | Yes, registrar’s include | None |
| My static site | Yes, a third-party mail provider | None returned | Yes, p=reject |
One out of five has the full set. The domain I would have guessed was fine is the one with no records at all, and the domain with the strictest policy of the five is also the one where I could not find the record that policy depends on. I am publishing this rather than quietly fixing it first because the pattern is the point: none of these sites reported a problem, none of these panels showed a warning, and I was not looking for any of it.
What actually happens to mail sent to a domain with no MX
Not an instant bounce, which is what I assumed. When a sending server finds no MX record for a domain, the standard tells it to fall back to the address record and attempt delivery to that host as if it were the mail server (RFC 5321, section 5.1). For a domain like mine, that address record points at a web server, which is not listening for mail on port 25. The connection is refused, the sender queues the message, retries for hours or days, and eventually gives up.
So from the sender’s side: nothing for a day or two, then a delivery failure that many people never read carefully. From my side: absolutely nothing. No error, no log, no signal of any kind. A contact page with a dead address does not look broken, it looks quiet, and “quiet” is exactly what a new site looks like anyway. That is why this can run for months.
The four records, in the order they actually matter
They get listed as a set, as though you configure all four on the same afternoon. They do different jobs and they fail differently.
- MX decides whether you receive. It names the servers that accept mail for the domain, with a priority number. On this blog the lookup returns the host’s two mail servers at priority 5 and 10 — primary and backup. Without this record, the address on your contact page is decoration.
- SPF decides who is allowed to send as you. It is a TXT record listing the servers permitted to send on the domain’s behalf. Mine ends in
~all, a soft fail, which tells receivers that anything from elsewhere is suspicious rather than forbidden. The stricter-allis a hard fail. Soft fail is the right default while you are still discovering which systems send mail for you, and I have not yet enumerated mine, so soft fail is where it stays. - DKIM signs each message with a key whose public half lives in DNS, so a receiver can verify the message was not altered and really came from an authorised system. It sits at
selector._domainkey.yourdomain.com, and the selector is chosen by whoever sends your mail. That is why there is no DKIM column in my table: you cannot enumerate selectors from outside, so the only honest way to check is to open the headers of a message your domain actually sent. I did not do that for all five, so I did not publish a column I had not verified. - DMARC tells receivers what to do when the first two disagree with the address in the From line, and where to send reports.
p=none is a smoke alarm with the battery taken out
This blog’s DMARC record is v=DMARC1; p=none and that is the whole record. Two things follow from those four words.
First, the policy instructs receiving servers to take no action when a message fails authentication. Someone can send mail claiming to be from this domain and DMARC will not ask anyone to stop them. Second — and this is the part I had wrong — p=none is usually recommended as a monitoring phase, but monitoring only happens if the record contains a reporting address. Mine does not. No rua tag, so no aggregate reports are being requested, so no data is being collected. I am in the observation stage of a process where I have arranged to observe nothing.
The fix is to add a reporting address, read what arrives for a few weeks, and only then consider tightening the policy. Tightening first is how people discover, the expensive way, that their invoicing system or their newsletter platform was sending as the domain all along.
Three other domains, three different ways of being wrong
The failures are not one failure repeated, which is what makes them worth writing down.
The SaaS domain has an SPF record and no mailbox. The include points at one of the three registrars I use, which means the record arrived with the domain as part of a default configuration rather than a decision. It is not harmful. It is also not doing anything, because there is no MX and nothing sends from there. Leftover records are their own small risk: in a year I will look at that line and wonder what was relying on it.
The static site has p=reject and no SPF I could find. This is the combination that makes me most uncomfortable. A reject policy asks receivers to bin anything that fails authentication — the strongest instruction DMARC can give — on a domain where my own lookup returned no sender policy at all. Whether mail from it actually authenticates depends on DKIM signing by the mail provider, which, as above, I cannot confirm from outside. It might be perfectly fine. I do not know that it is, and on a domain with a reject policy “I do not know” is not a comfortable place to sit.
The agency domain and the second blog have nothing at all. Two domains, live, with pages inviting people to get in touch. That is the one from the first paragraph, and it is the plainest failure of the five: an address exists in the HTML and nowhere in DNS.
What a shared hosting plan actually gives you
Mailboxes come bundled with most shared hosting — they are one of the things you are quietly paying for, along with everything else in what you are actually buying when you buy hosting — and that is how I ended up with mail on the same account as the websites. Checked on 20 September 2026, the numbers look like this on the plans I could read that day.
- Hostinger: Premium at $2.99/month on a 48-month term, renewing at $10.99, includes two mailboxes per website, free for the first year; Unlimited at $3.99 renewing at $16.99 includes unlimited mailboxes, also free for the first year (Hostinger web hosting page, checked 20 September 2026). Note where the “free for the first year” sits: on the mailboxes, not on the plan.
- IONOS: Essential includes one email account, Starter two, Plus four, Ultimate five, with first-year prices of $4, $6, $1 and $10 per month rising to $8, $10, $14 and $18 (IONOS web hosting page, checked 20 September 2026, US site).
- DonDominio: the entry plan at 39 €/year excluding VAT includes 15 mailboxes of 2 GB each, rising to 20, 30 and 50 accounts on the plans above it. The page publishes no renewal price and no minimum term (DonDominio hosting page, checked 20 September 2026).
Two honest caveats about this route. The mailbox count is a plan limit, not a promise about deliverability — a shared platform means a shared sending reputation, and I have no measurements of my own on that. And coupling mail to hosting means a hosting migration becomes a mail migration, which is a considerably worse evening. The broader entry-versus-renewal arithmetic across everything I pay for is in what I actually pay for hosting, domains and email, and the account itself in the Hostinger review.
Two minutes, four commands, any domain
# 1. Can this domain receive mail at all?
dig +short MX example.com
# 2. Who is allowed to send as it?
dig +short TXT example.com | grep -i spf1
# 3. What should receivers do with failures, and where do reports go?
dig +short TXT _dmarc.example.com
# 4. DKIM, if you know the selector your provider uses
dig +short TXT selector1._domainkey.example.com
# Windows without dig:
# nslookup -type=MX example.com
# nslookup -type=TXT _dmarc.example.comEmpty output is an answer. An empty MX line on a domain that publishes a contact address is the most useful thing this post can tell you to look for. If you are setting the records rather than reading them, the record-editing side of this — and how to make the change without downtime — is in the post on pointing a domain at your host without downtime.
What I am not covering
Google Workspace, Microsoft 365, Zoho, Proton and Fastmail do not appear in this post with prices or verdicts. My domains’ mail sits on hosting-provided mailboxes and one third-party provider, I did not open those pricing pages on 20 September 2026, and I have no basis for ranking products I do not run. The old version of this page did exactly that, in the confident voice of someone who had tried them all. I have not tried any of them.
I also have no deliverability data. Measuring whether mail lands in an inbox or a spam folder needs volume, seed accounts and time, and none of my domains send enough mail to produce a number worth publishing. Anyone quoting an inbox placement rate should be able to tell you how they measured it.
The rule I now follow
No address goes on a page until I have sent a message to it from an account on a completely different provider and watched it arrive. Not the webmail test, which proves that the platform can talk to itself. A real message from outside, through public DNS, with a reply sent back the other way so the sending path gets exercised too.
It takes ninety seconds and it is the only test that covers the whole chain. Everything in this post — the missing MX, the reporting address I never set, the policy on a domain I cannot fully verify — would have shown up the first time I tried it, on the day the contact page went live, instead of much later at a command prompt. The rest of the site can be checked by reading it. Email is the one part that only answers if you talk to it.