When an email is not delivered, this is how you find out

A customer asks for a quote on Tuesday. You write it the same afternoon, attach the PDF, hit send, and then hear nothing for a week. Most owners read that silence as "they went with someone cheaper," and sometimes that is exactly what it is. But a fair share of the time the message never reached a human being at all — and the reason nobody catches it is that an email that is not delivered looks identical, from your side, to an email that was delivered and ignored. Same Sent folder, same tidy entry, same complete absence of any warning. This guide is about telling those two apart in about twenty minutes, and about the one failure that will never warn you no matter how long you wait.

How do I know if my email was actually delivered?

You don't, unless you go and look. Standard email carries no delivery receipt. Your server hands the message to their server, gets a short acknowledgement if that goes well, and stops caring. Everything after that — inbox, spam folder, quietly binned by a filter — happens on somebody else's machine, where you have no visibility at all.

This surprises people, and I understand why. Every other thing we send now has tracking. A parcel has a barcode. A bank transfer has a reference. An email has a protocol designed in the 1980s by people who assumed that if a message got through the front door, a human would eventually read it. Spam filtering arrived twenty years later and was bolted on behind that front door, which is precisely where the blind spot comes from.

Three ways an email fails, and only one of them tells you

Rejected, deferred, or accepted-and-filtered. A rejection bounces straight back with a machine-readable reason. A deferral sits in a queue and retries, so the bad news reaches you hours later, if at all. Acceptance followed by a spam filter produces nothing — the receiving server already said yes, and there is no taking that back.

Here is the whole picture in one table, including the row everybody forgets — the message that arrived perfectly and was simply never read.

The two grey rows are indistinguishable from your desk, and that is the entire problem. One of them means you have a technical fault costing you work. The other means you need to pick up the phone. Same evidence, opposite response — which is why guessing is the worst thing you can do here.

The vocabulary is worth ten seconds, because it is the same in every mail system on earth. RFC 3463, the standard that defines these codes, calls a 4.x.x result a persistent transient failure — one where "the message as sent is valid, but persistence of some temporary condition has caused abandonment or delay" — and a 5.x.x result a permanent failure, "one which is not likely to be resolved by resending the message in the current form." That last clause is the practical instruction: if you got a 5, hitting send again changes nothing.

How do I read a bounce message in thirty seconds?

Ignore the wall of text and find the three numbers separated by dots. The first digit is the verdict — 4 means try later, 5 means never. The two after it name the cause: 1.1 is a bad address, 2.2 is a full mailbox, 7.x is a policy or authentication refusal. Everything else in that email is noise.

These are the four you will actually meet, with Gmail's own wording, because Gmail is on the other end of most Canadian small-business mail whether the customer uses @gmail.com or a company domain sitting on Google Workspace.

The definitions behind those numbers are worth knowing because they are provider-independent. RFC 3463 defines X.1.1 as "the mailbox specified in the address does not exist," X.2.2 as a mailbox that "is full because the user has exceeded a per-mailbox administrative quota or physical capacity," and X.7.1 as "the sender is not authorized to send to the destination." Read that last one again slowly. A 5.7 bounce is not about the recipient at all. It is a stranger's mail server telling you that it does not believe you are who you say you are — and every bounce in that family should be treated as a fault on your side, not as a one-off.

Google publishes the full list on its Gmail SMTP errors and codes page, and it is genuinely the fastest way to identify a code you have never seen before. Search the page for your three numbers, read one line, move on.

A bounce is the version of this problem where somebody actually told you. The expensive one is the message your own server records as a success.

The failure that never bounces

A message can be accepted and then filed in a spam folder, and no bounce exists for that. The receiving server made its decision after saying yes, and once a server has accepted a message the conversation is over. Filtering happens afterwards, inside their system, and nothing in the protocol reaches back to tell you about it.

So the worst outcome for your business produces the cleanest-looking result on your screen. No red text. No warning triangle. A perfectly ordinary line in Sent, sitting there looking as successful as every message that did arrive. This is the failure mode I get called about most — usually months late, usually by someone who has spent that time believing their quotes were being read and rejected.

What decides which side of that line you fall on is authentication: whether the receiving server can verify that mail claiming to come from your domain really did. Google's email sender guidelines now list requirements for all senders, at any volume — "Set up SPF or DKIM email authentication for your sending domains," valid forward and reverse DNS, a TLS connection, and correctly formatted messages — with the extra DMARC and one-click-unsubscribe rules reserved for bulk senders above 5,000 messages a day. The consequence is stated plainly on the same page: "If you don't meet the requirements described in this article, your email might not be delivered as expected, or might be marked as spam."

Note the "or might be marked as spam." That is Google describing, in its own documentation, the outcome that generates no bounce. Nobody sending twelve emails a day thinks a rule about senders applies to them. It does, and it applies from the first message.

If your website's contact form is involved as well as your mailbox, the failure has a second front door and needs its own separate test — I've written the full diagnosis for that in why your contact form emails land in spam, and I would read that one alongside this if leads arrive through a form rather than by people typing your address.

Why your Sent folder is not proof of anything

Your Sent folder records one event: your mail client successfully handed the message to your own outgoing server. That is the first hop of several, and it is the only one you can see. Whether hop two, three or four went anywhere is not recorded there and never has been.

Read receipts don't rescue this either. They are a request, not a mechanism — the recipient's software has to support them and the recipient has to agree, and most people click no or never see the prompt. Tracking pixels are worse: mail providers routinely pre-fetch or block remote images, so an "opened" flag can fire when nobody looked and stay dark when somebody read every word. If you are going to make a decision about a customer based on whether they saw something, phone them. That is not old-fashioned advice, it is the only channel in this list that returns a real answer.

The twenty-minute check I run on a client's email

Four steps, no tools to buy, and it works on any mailbox. Send yourself a test from the real business address to an outside account you control, check the spam folder before the inbox, open the raw headers and read the three authentication lines, then look up what your own domain is publishing. Most problems are visible by step three.

1. Send one real-looking email from your business address to an outside mailbox you own. Not a one-word test — write it the way you write a quote, with a subject line, a signature and an attachment if you normally send one. A bare "test" message behaves differently to a real one and will lie to you about the result.
2. Open the spam folder first, and search by your domain name rather than by the subject. Filters move things and thread things, but the sender never changes. If it is sitting in spam, congratulations — delivery works, and you now know the problem is authentication or reputation rather than routing, which is a much cheaper problem.
3. Read the headers. In Gmail this is the three-dot menu on the message, then Show original. Outlook calls it View message details or Properties → Internet headers. You are looking for three words near the top: spf=pass, dkim=pass, dmarc=pass. Anything that says fail, softfail or none is your answer, and you have found it in about four minutes without paying anybody.
4. Check what your domain publishes. Your DNS should have a TXT record beginning v=spf1 and, ideally, one at _dmarc.yourdomain.com beginning v=DMARC1. If SPF is missing entirely, that is the whole diagnosis. If SPF exists but does not list whoever actually sends your mail — a new mailbox provider, a newsletter tool, the website that sends your form notifications — that is the second most common cause I see.

One thing that check will not tell you: whether a mailbox that used to work has quietly stopped authenticating. Passwords get rotated, app passwords get revoked when someone enables two-step verification, and a form that has posted leads to your inbox for two years stops overnight without anyone noticing. On the sites I look after, that is watched rather than assumed — a scheduled probe opens the connection every week, authenticates against the mail server, and hangs up without sending a single message. It proves the credentials still work without generating one extra email in anyone's inbox, and it is part of what ongoing maintenance and support is actually for.

How do I get a warning next time, instead of finding out in March?

Publish a DMARC record with a reporting address. Once rua= is in place, other people's mail servers send you a summary of what they did with messages claiming to come from your domain — including whether those messages passed SPF and DKIM. It is the only free early warning that watches the failures which never bounce.

Under RFC 7489, rua is defined as the "addresses to which aggregate feedback is to be sent," and if you don't publish one, receivers "must not generate aggregate feedback reports" at all — so silence here is a choice you made by omission. The default interval is 86,400 seconds, meaning one report per receiving provider per day. The reports arrive as XML, which is unreadable to a human being and perfectly readable to any of the free DMARC report viewers, so budget one afternoon to set it up and roughly zero minutes a week thereafter.

That second row deserves the honesty, because plenty of advice tells small businesses to "just check Postmaster Tools" without mentioning that most of them will open an empty dashboard. Google's own documentation says so: "Data might be missing if the total number of messages for a given day is too low. This is to protect users' privacy," and it suggests checking again "when your email sending volume increases enough to populate the dashboards." If you send twenty emails a day, that tool is not for you yet. DMARC reports are, from message one.

And the last row is not a joke. The cheapest deliverability monitor a small business has is a habit: when a quote goes out, write the follow-up date in the same place you write everything else, and phone on that date. Every silent failure I have ever been called in to diagnose was found by a human being who noticed a silence, not by software.

What do I do when a customer says they never got my email?

Ask them to search their spam folder for your domain name, not for the subject line. If it is there, delivery works and authentication is your problem. If it is genuinely absent, resend from a completely different address, phone them, and then go and fix the domain before the next quote leaves — because the same fault is silently applying to everyone else.

In that order, and specifically not the other order. The instinct is to fix the technology first and get back to the customer once you understand what went wrong. That is backwards: the customer is time-sensitive and the DNS record is not. Send the quote from a Gmail address in the next ten minutes if you have to. It looks slightly less professional than your own domain and it is enormously more professional than a week of silence.

Once the immediate job is safe, be a little suspicious about scope. One bounced address is an address. Two customers in a month saying they never received anything is a pattern, and by the time two people bother to tell you, a larger number have simply moved on without mentioning it. That is the real cost of this and it never appears on any invoice.

If it turns out your mail and your website are sharing one cheap hosting box, that is worth untangling on its own merits — the reasoning, and what a proper mailbox costs in Canada, is set out in business email on your own domain. It is one of the few things in this trade where the correct answer is genuinely cheap.

Frequently asked questions