The First Clubtide Email Went Straight to Spam: What I Learned at Launch

The first email I sent while launching clubtide.app did not reach the inbox. It went straight to Spam.

This was not a newsletter sent to thousands of people, and it was not a purchased list. It was the first important test of a new product. The message had left the application, the provider marked it as sent, and from a technical point of view the flow seemed to work.

The recipient simply could not see it.

I opened the Spam folder and found the email there. For the next few hours, the launch stopped being about product screens and became a lesson in DNS, authentication, and sender reputation.

“Sent” does not mean “delivered to the inbox”

In an application, it is easy to consider email finished when the provider returns a successful response. That response only confirms that the message was accepted for delivery. It does not guarantee that Gmail will place it in the inbox.

Between those two moments, the recipient’s email provider evaluates several signals:

who sent the message;
whether the domain is authorized to send it;
whether the message was altered in transit;
whether the domain in the From field aligns with authentication;
the reputation of the domain and sending IP;
sending volume and cadence;
how recipients react to previous messages;
the content and technical structure of the message.

A new domain has almost no history. It does not yet have a stable sending pattern or enough positive signals. That does not make the domain suspicious by default, but legitimacy alone does not earn automatic trust.

My first lesson from launching Clubtide was simple: email is part of the product, and its delivery must be tested like any other critical feature.

What Gmail actually requires

Since February 1, 2024, Gmail has explicit requirements for messages sent to personal @gmail.com and @googlemail.com accounts.

For all senders, Google requires at least SPF or DKIM authentication, valid forward and reverse DNS for sending servers, TLS, messages formatted according to RFC 5322, and a spam rate reported in Postmaster Tools below 0.3%.

The rules become stricter for senders who send around 5,000 or more messages in one day to personal Gmail accounts:

both SPF and DKIM must be configured;
DMARC must be published for the sending domain;
the domain in From must align with either SPF or DKIM;
marketing messages must support one-click unsubscribe;
the spam rate must remain below Google’s thresholds.

The threshold is calculated at the primary-domain level. Messages from different subdomains are added together. Once Gmail classifies a domain as a bulk sender, that status does not expire simply because its volume later falls.

However, the 5,000-message threshold does not explain by itself why my first email went to Spam. A small sender can have delivery problems long before reaching that volume. My practical conclusion was to configure SPF, DKIM, and DMARC from the beginning rather than waiting until Clubtide sent enough messages for every rule to become mandatory.

SPF, DKIM, and DMARC without the jargon

The three acronyms appear in almost every conversation about email deliverability, but they do different jobs.

SPF: who is allowed to send

SPF is a DNS record that lists the servers authorized to send email on behalf of a domain.

When I use an external provider, it must be included correctly in SPF. A common mistake is publishing several separate SPF records. A domain should have one valid SPF policy that includes every legitimate sending source.

DKIM: proof that the message is authentic

DKIM adds a cryptographic signature to the message. The receiving provider verifies it using a public key published in DNS.

In practical terms, DKIM shows that an authorized system signed the message and that the message was not altered after signing.

DMARC: what happens when identities do not align

DMARC connects the visible domain in From with the results of SPF and DKIM, then defines what the receiving server should do when verification fails.

An initial p=none policy allows monitoring without immediately asking providers to quarantine or reject messages. DMARC reports reveal who sends on behalf of the domain and can expose forgotten or incorrectly configured services. Once every legitimate source is known, the policy can be strengthened carefully.

What I checked after that first test

Instead of resending the same message and hoping for a different result, I treated the incident as a launch checklist.

1. Authentication in the original message

In Gmail, “Show original” displays the SPF, DKIM, and DMARC results. I want to see PASS, but I also want those results to align with the domain the user believes sent the message.

An isolated PASS does not tell the full story. SPF can pass for a provider’s technical domain while the visible address uses the product domain. DMARC checks that relationship.

2. DNS records

I checked whether the domain contained every record required by the email provider, without duplicates or partially copied values. DNS is where the product publicly declares which infrastructure can send on its behalf.

Paying for a good email platform does not configure the product’s DNS automatically. The provider may sign messages, but the required records still need to be published and verified on the domain.

3. The visible address and sending domain

The address in From, the domain used for DKIM, and the return-path domain need to be considered together. A setup that mixes the product domain with a provider’s default values may pass individual checks while sending weaker trust signals than a fully aligned configuration.

4. Message content and format

I looked at the email as a recipient, not only as a developer. Is the sender recognizable? Does the message clearly explain why it was sent? Is there a plain-text version? Do the links lead to predictable domains? Do the footer and contact details inspire confidence?

There is no single magic word that sends a message to Spam. Placement depends on the combination of identity, reputation, behavior, and content.

5. Initial sending volume

Google recommends increasing volume gradually. For a new domain, a sudden burst of messages is precisely the signal I do not want to create.

The first messages should go to real recipients who expect them and interact with them. Old lists, purchased addresses, and campaigns launched at full volume are a poor foundation for sender reputation.

Transactional messages and newsletters should not be mixed

Like any online product, Clubtide can send messages with very different purposes:

confirmations and notifications required for an account to work;
password resets;
important service updates;
newsletters and marketing campaigns.

An account confirmation does not serve the same purpose as a newsletter. If both use exactly the same flow, identity, and reputation, a poorly performing marketing campaign can also affect messages that users genuinely need to receive.

Separation can mean different subdomains, streams, or infrastructure depending on the provider and sending volume. It is not a workaround for poor practices—Google aggregates volume at the primary-domain level—but it provides better operational visibility and control.

One-click unsubscribe is required for promotional messages from bulk senders, not for strictly transactional email. Even so, every marketing message should provide a clear, simple way out. A person who cannot find the unsubscribe option will use the Spam button, and that action affects the domain’s reputation.

A 0.3% spam rate is a limit, not a target

The screenshot that prompted the original analysis mentioned a 0.30% threshold. That figure is correct as a critical limit, but I would not use it as an operational target.

Google recommends keeping the user-reported spam rate below 0.1% and avoiding ever reaching 0.3% or higher. At 1,000 delivered messages, a single spam report already represents 0.1%. The margin is tiny.

Postmaster Tools can show the spam rate, domain and IP reputation, authentication, and delivery errors. At very low volumes, some dashboards may not have enough data to report. No data is not the same as a perfect reputation.

The checklist I would use before the next launch

Before a new product sends its first real email, I would verify:

one SPF record containing every legitimate sending source;
active DKIM using the correct domain and a key accepted by Gmail;
published DMARC, initially in monitoring mode if necessary;
alignment between the domain in From and SPF or DKIM;
TLS and correctly formatted messages;
both HTML and plain-text versions;
a clear sender and reply address;
links that use recognizable domains;
one-click unsubscribe for promotional messages where required;
logical separation between transactional and marketing email;
tests to Gmail and other providers, not only internal addresses;
gradual increases in sending volume;
monitoring in Postmaster Tools once enough data is available.

Most importantly, I would open the test message. I would not stop at a “delivered” status in a dashboard.

What stayed with me from this experience

The first Clubtide email landing in Spam was not a spectacular failure, but it was exactly the kind of problem that can make a product look broken while it is trying to earn the trust of its first users.

When a confirmation email is missing, the user does not think, “There is probably a DNS record missing.” They think, “The application does not work,” and leave.

Email deliverability is therefore not only the provider’s responsibility or a detail to fix after launch. It is part of the product experience.

For Clubtide, that first message in Spam was a useful reminder: before scaling campaigns, I need to prove that the domain’s technical identity is correct, that people genuinely want the messages, and that every send deserves its place in the inbox.