Why Your Emails Land in Spam

A message in a spam folder generates no notification, no bounce and no record. It simply is not read, and you find out weeks later when a client mentions they never got the confirmation. That is the first thing to understand about this problem: most of it is invisible by design. The second is that the dashboard Google points you at, the one carrying the number you are told to keep low, may show a guiding operation nothing at all, because it withholds data when daily volume is too low to protect the privacy of the people involved. So an operator has to work from the published rules and from the rejection codes rather than from a graph. Both are readable, and the codes are more precise than most people expect. Where email fits among everything else you send is set out under the getting-booked hub.

Why can you not see the problem?

Because two of the three outcomes look identical from your end.

A message that reached an inbox and a message filed as spam produce exactly the same result in your sent folder, which is a message in your sent folder.

Only the third outcome, an outright rejection, sends anything back, and rejections are the minority case.

That asymmetry is why operators discover the problem through a conversation rather than through a tool, usually about a month late.

It is also why the instinct to rewrite the message is unhelpful: you have no evidence that the message was the reason, or that anything went wrong at all.

The honest position is that you cannot observe your own delivery directly, and the two things you can observe are the rules and the codes.

Both are published, and working from them is more productive than working from a hunch.

The configuration side of this, meaning the records that decide whether a message is even eligible to be trusted, is covered in the deliverability piece.

Southern Sport, GA

What is the monitoring tool, and will it help?

Probably not, and the reason is worth knowing.

Google runs a free monitoring service for people who send to Gmail accounts, covering spam rate, reputation, authentication and delivery errors.

Setting it up means adding your sending domain, specifically the domain used to authenticate outgoing mail, and verifying it with a record at your domain provider.

Verification is usually immediate and may take up to ten minutes, and the service requires a Google or Workspace account to use at all.

Then comes the part nobody mentions: the help page states that data might be missing if the total number of messages for a given day is too low, and that this is to protect users' privacy.

Its recommendation is to check again when your sending volume increases enough to populate the dashboards.

For an operation mailing a few hundred past clients a handful of times a year, that is a polite way of saying the graphs will be empty.

Set it up anyway, because it costs an afternoon and it starts collecting for the day you need it.

The setup steps are published by Google in its Postmaster Tools help.

What does a rejection actually tell you?

More than any dashboard, because it is standardised.

When a message is refused, the server returns a status code with a defined structure rather than a sentence somebody wrote.

The specification defines it as three numerical fields separated by full stops: the first says whether delivery succeeded, the second indicates the probable source of any anomaly, and the third gives a precise error condition.

A leading five means a permanent failure, and the standard is explicit that these codes are for media and language independent status reporting rather than system specific diagnostics.

It also says servers should send only defined, registered codes, and that because the number space is large, published codes are not intended ever to be redefined or eliminated.

Which means the code in your bounce means the same thing this year as it did in 2003, and the same thing at every receiving service.

That is a rare piece of stability in a subject full of vendor opinion.

The structure is defined in RFC 3463, published by the RFC Editor.

Which codes matter to a guide?

The ones beginning five point seven.

The second field of seven covers security and policy, described as failures involving policies such as per-recipient or per-host filtering.

Within it, the code ending seven point one means delivery not authorised, message refused, and the registry describes it as the result of per-host or per-recipient filtering.

The specification adds a sentence worth reading twice: it does not discuss the merits of any such filtering, but provides a mechanism to report it.

In other words, the standard makes no claim that the filtering was correct. It only gives the receiving service a precise way to tell you it happened.

The one Google names in its own guidance is the code ending seven point twenty-six, which the registry defines as multiple authentication checks failed.

Its full definition is that the message failed more than one authentication check contrary to local policy requirements, and that the particular mechanisms that failed are not specified.

The registry is maintained by IANA as the SMTP enhanced status codes registry.

Pisgah Outdoors, NC

What does the spam rate actually measure?

People pressing a button, not a machine's opinion.

The number reported in that dashboard reflects recipients marking your messages as spam, which is a human action rather than a filter's verdict.

That distinction changes what you do about it, because the fix is a list problem rather than a writing problem.

The published requirement is to keep the reported rate below 0.3 percent, which the sender guidance lists among the requirements applying to every sender.

What a complaint costs you is not limited to the message that caused it, since repeated reports lower how your domain is treated over time.

Notice what this means in practice: one annoyed recipient on a list of three hundred can put a send over the line by themselves.

Which is why the advice below is about who is on the list rather than what the message said.

Where those addresses come from in the first place is described in the piece on collecting emails.

What does the guidance say about lists?

Five things, and all of them are about consent.

Send email only to recipients who want to get messages from you, which sounds obvious and rules out most bought or scraped lists.

Make sure recipients opt in to get messages from you, which rules out adding somebody because they once enquired.

Confirm each recipient's address before subscribing them, which is the step nobody does and which also removes typos.

Periodically send messages to confirm that recipients want to stay subscribed, which is a habit rather than a setting.

And consider unsubscribing recipients who do not open or read your messages, which feels backwards and is the single most effective thing on the list.

Alongside those sits making it easy to unsubscribe, which is both required elsewhere and the cheapest way to avoid a complaint.

A guide who applies all six ends up with a smaller list that performs better, which is the whole trade.

What that first message to a new subscriber should say is set out in the welcome sequence piece.

Does removing people really help?

It is the least intuitive advice and the most useful.

Everything about running a small business argues for keeping every address you have ever collected, on the theory that one of them might book.

The guidance argues the other way, suggesting you consider unsubscribing recipients who do not open or read your messages.

The reason is that a list of people who ignore you is a list of people statistically more likely to complain, and complaints are the metric that matters.

There is a second reason, which is that engagement is part of how a receiving service decides where to file your mail.

So a smaller list of people who want to hear from you improves delivery for everybody remaining, including the ones who would have booked.

The practical version is to drop anybody who has not opened anything in two seasons, after one message asking whether they want to stay.

That message is uncomfortable to send once and then never a problem again.

The seasonal send you are protecting is planned in the winter rebooking piece.

What content rules exist?

Fewer than you think, and they are about deception.

The published guidance asks that message headers and content be accurate rather than misleading or deceptive, and that subjects, headers and display names accurately represent the sender and the content.

It gives specific examples. Do not send messages with subject lines beginning with a reply or forward prefix unless they genuinely are replies or forwards.

Include only actual senders and recipients in the sender and recipient headers.

Do not use emoji or other non-standard characters to imitate graphic elements with intent to deceive or influence, and it names the specific case of putting them beside a display name to imply the name has been verified.

Do not use markup and styling to hide content, which it warns might cause messages to be marked as spam.

And links in the body should be visible and easy to understand, so recipients know what to expect when they click.

None of that constrains an honest message, which is the point: the content rules are a floor, not a craft standard.

Writing the subject well is a separate problem, handled in the subject lines piece.

Can you find out which messages get reported?

Yes, and almost nobody uses the mechanism.

Among the practices Google lists is one that sounds technical and is genuinely useful for a small sender.

Its wording: use the feedback identifier to identify the types of message that are most often marked as spam by recipients.

That identifier is a value your sending tool can attach to a category of message, so complaints can be attributed to a kind of send rather than to your domain as a whole.

The practical use for a guide is to tag the seasonal announcement, the reminder run and the winter offer separately.

Do that for one season and the question stops being whether your email has a problem and becomes which of three sends has one.

Not every inexpensive tool exposes the setting, which makes it a fair thing to ask about before choosing one.

Ask it alongside the reputation question, since a provider vague about both is describing how it operates.

How those tools compare is set out in the email tools piece.

How do you debug a message that vanished?

Six checks, in this order.

Confirm it was actually sent, from the tool that sent it, rather than assuming a scheduled send ran.

Look for a bounce and read the code in it, since a five point seven code names the reason precisely.

Post the identical message to a mailbox of your own hosted somewhere else entirely, then note which folder it reaches.

Check the authentication records for the sender that sent it, which is where most vanishing messages originate.

Ask the client to look in their spam folder and, if it is there, ask them to mark it as not spam, which helps that one recipient immediately.

Then check whether the send went to a list you have not cleaned in two years, which is the most likely underlying cause.

Only after all six is it reasonable to wonder whether the message itself was the problem, and it usually was not.

The automated sends most likely to fail silently are described in the automations piece.

Which habits cause the trouble?

Seven, starting with adding people who never asked.

Adding every address the business has ever touched, including enquiries that never became bookings.

Keeping addresses that have ignored several seasons of mail, on the theory that one might book.

Rewriting the message after a delivery problem, which addresses the least likely cause.

Ignoring bounce codes entirely, when they carry the only precise information available.

Assuming the monitoring dashboard will show you the answer, when it withholds data below a volume you do not reach.

Making the unsubscribe hard to find, which converts an opt-out into a complaint.

And sending from a shared address without ever asking the provider about its reputation.

Choosing between the two channels in the first place gets worked through in the text and email comparison.

What surprises operators here?

That the dashboard may show them nothing.

Being told to watch a number, then discovering the tool withholds it below a daily volume you never reach, is the moment most operators stop taking the advice literally.

The second surprise is that the spam rate counts human complaints rather than filter decisions, which relocates the whole problem to the list.

The third is that bounce codes are a registered, standardised vocabulary rather than each provider's own wording.

The fourth is that the standard explicitly declines to say whether the filtering that refused your message was justified.

The fifth is that the most effective recommendation in the published guidance is to remove people from your list.

Taken together, the subject is far more mechanical and far less mysterious than its reputation suggests.

The message that most often triggers this investigation is the reminder, covered in the trip reminder piece.

The debug, in order

Rules first, codes second, message last.

Set up the monitoring service even though it may show you nothing, because it begins collecting from the day you add it.

Read any bounce code you receive against the registry rather than guessing what it means.

Treat a five point seven code as a policy answer and a specific one as a precise answer, since the registry says exactly what each means.

Fix the list before the message: confirm addresses at signup, ask periodically, and remove people who never open anything.

Keep the unsubscribe obvious, because an easy opt-out costs nothing and a complaint costs the whole send.

Ask your sending provider about its shared address reputation, and treat a vague answer as an answer.

Check the content rules once, confirm your messages are not doing anything deceptive, then stop worrying about content.

And keep a note of when you last cleaned the list, since that date explains most of what happens afterwards.