If the signup email lands in spam, there was no signup: transactional email deliverability for vibe projects

The most expensive bug is the email the user never sees

Your vibe project is live. A user signs up, the verification email goes out — and then nothing. The user never receives it, cannot complete verification, cannot log in, cannot pay. You check the logs: your email provider says "sent," status delivered. You assume it is the user's mailbox; the user assumes your product is broken; the user leaves. The truth is usually this: the email was sent, but the receiving side classified it as spam, so it sits in the junk folder — or was rejected outright. Worse, you will never get a bug report about it, because users who "did not get the email" usually do not come back to tell you. They just churn quietly. Transactional email — verification, password reset, order confirmation, login alerts — is not an accessory to your product. It is the product: if the verification email does not arrive, the user has effectively not signed up; if the password reset does not arrive, the user is effectively locked out.

A boundary first, because nearby guides on this site are easy to confuse with this one. The notification-system guide covers in-product notifications and pushes — in-app messages, push reminders, notification preferences: "how does the user get reminded inside the product." This guide covers email deliverability itself — the journey from your server, through sender authentication, through receiver filtering, into the inbox rather than the junk folder. They meet at "user preferences," but the core problem differs: notifications answer "what to remind and when," deliverability answers "can the email be seen at all." This guide also does not cover marketing email — bulk sends, subscriptions, unsubscribe handling, open-rate optimization are a different discipline. Transactional email is one-to-one, triggered by user action, and must arrive; its deliverability bar is stricter and more important than marketing mail's.

The three gates: authentication, reputation, content

Gate one is authentication, which the receiver uses to decide "did you really send this?" Three protocols must all be in place; missing one costs you. SPF (Sender Policy Framework) is a DNS declaration of which servers may send mail for your domain — if you send through Resend, SendGrid, or Amazon SES but never list their servers in SPF, receivers will suspect forgery. DKIM (DomainKeys Identified Mail) signs every message with a private key held by your sending service, verified against a public key in your DNS — a signature that does not check out makes the message untrustworthy. DMARC is the policy layer on top: it tells receivers what to do when SPF or DKIM fail (report only, quarantine to junk, or reject outright) and where to send reports. The typical vibe-project state is: SPF set, DKIM missing, DMARC never heard of — and that "half-configured" state is more dangerous than nothing, because it lets you believe you are safe.

After configuring authentication, verify instead of assuming. Three free checks belong on your launch checklist: confirm with your provider's DNS checker that all three records have propagated (DNS changes take time; testing immediately after editing can mislead); send yourself a test message and check Gmail, Outlook, and QQ Mail separately — inbox or junk; and read your DMARC aggregate reports (delivered to the reporting address you set), which list which servers send mail as your domain and which sources fail authentication. Tighten DMARC in stages: start at p=none (report only, no action), watch reports for one to two weeks to confirm no legitimate sending source is missing, then move to p=quarantine, and finally p=reject. Jumping straight to p=reject means asking receivers to reject possibly legitimate mail before you have confirmed your sender inventory is complete.

Gate two is reputation: the receiver's judgment of "how has this sender behaved in the past." Reputation rests on the history of your sending domain and IP: high bounce rates, frequent spam complaints, and sudden volume spikes all drag it down. Here is a trap vibe projects walk into constantly: transactional and marketing mail sharing one domain, even one sending subdomain. One marketing blast that many users mark as spam damages the reputation that verification mail depends on — and that is how verification mail starts landing in junk. The fix is separation: transactional mail on its own subdomain (for example mail.yourapp.com or notify.yourapp.com), marketing mail on another, each with its own SPF, DKIM, and DMARC. Separation costs one DNS configuration; its payoff is that a marketing incident leaves signups and password resets untouched.

Gate three is content: the receiver's judgment of "does this message look like spam." The rule for transactional mail is "as simple as possible." Use your product name as the sender name, not a personal name and not a cold noreply address (noreply itself scores against you with some filters, and when users genuinely reply, nobody reads it). Make the subject say what the message does — "Please verify your email" classifies more reliably than "Welcome to something." Put one job, one link, and one button in the body; do not stuff a verification message with product recommendations, social links, or marketing beyond the unsubscribe. Keep link domains consistent with the sending domain — no short links, no redirect links; filters are highly sensitive to "a link to an unfamiliar short domain hiding in this message." Keep images minimal: image-only mail, text baked into images, and images hosted on third-party hosts are all classic spam traits. Transactional mail should be mostly text, with full, readable URLs.

From "sent" to "delivered": four metrics you must watch

"Sent" in a provider dashboard is not delivery. Watch four metrics. First, bounce rate: hard bounces (nonexistent address or domain) above 2% are a warning that your signup flow collects invalid addresses — format validation at signup and a check against disposable-mail domains before sending verification blocks most of them. Second, spam complaint rate: users clicking "this is spam" above 0.1% is already a danger signal — and for transactional mail, complaints usually mean "I do not remember signing up" or "I got duplicates," both of which must be fixed in the product flow, not the message copy. Third, open and click rates: transactional open rates should be far above marketing rates, so a sudden drop in verification-mail opens should prompt a junk-folder investigation, not a conclusion that users lost interest. Fourth, delivery latency: if more than a minute passes between "user clicks signup" and "message appears in the inbox," users start doubting, clicking again, and re-registering — and duplicate sends further damage reputation, a vicious circle.

Beyond metrics, handle two kinds of silent failure. First, messages silently discarded by receivers: some receivers neither bounce nor junk suspicious mail but simply drop it — your provider shows delivered, the user sees nothing. The only defense is closed-loop verification: give users a "didn't get the email? resend" entry point, and track how often it is used — if users on one particular provider resend frequently, you have a provider-specific systemic problem to investigate separately. Second, bounce handling: hard-bounced addresses must be automatically removed from sending (for transactional mail, mark the user "email invalid" and stop re-sending verification), and soft bounces (mailbox full, temporary server failure) may be retried a few times with backoff — but unbounded retries only damage reputation further.

A launch checklist you can copy

Before launch, tick these in order. One, domain and authentication: a dedicated transactional subdomain exists; SPF includes the sending service you actually use; DKIM is enabled and signatures verify; DMARC is set to p=none with a reporting address. Two, sender identity: the sender name is your product name, the sending address sits under the transactional subdomain, and the reply address is monitored — at least an inbox someone reads and triages, not a noreply black hole. Three, content checks: send one test message of each transactional type (verification, password reset, order confirmation, login alert) to Gmail, Outlook, and QQ Mail and confirm all land in the inbox; each body carries one job and one primary link; no short links, no third-party-hosted images, no marketing stowaways. Four, flow checks: verification arrives within 60 seconds of signup; the resend entry point exists with rate limiting (for example, once per 60 seconds); password-reset links expire (for example, after one hour) and are single-use; changing an email address alerts the old address and requires re-verification of the new one.

After launch, review the four metrics weekly and the DMARC aggregate report monthly. Tighten DMARC on the p=none to p=quarantine to p=reject path, confirming at each step that no legitimate source is missing from the reports. When marketing mail launches, run the same checklist separately on a marketing subdomain — never reuse the transactional subdomain's configuration. One closing principle: transactional deliverability is not "sent and done"; it is done only when the user can see it, open it, and complete the action. Every percentage point of verification-mail deliverability is a percentage point of signup conversion, earned for real — which may make it the highest-return optimization in your vibe project, because it fixes not one feature but the entrance to all of them.

Troubleshooting: when the mail does not arrive, check these five places first

When a user says "I didn't get the verification email," do not start by doubting the user — work this list. First, your sending records: was the message actually sent, what status did the provider return, and did your own app logic block it (for example, a rule like "one verification email per address per 24 hours" catching legitimate users)? Second, the receiver's junk folder and category tabs: much mail is not missing but filed under "Promotions" or "Social" tabs the user rarely opens — ask the user to search for your product name across junk and all tabs. Third, authentication state: have SPF, DKIM, or DMARC expired, been deleted, or broken by a domain renewal, DNS migration, or provider switch? Your app will not error when that happens; mail will simply start landing in junk. Fourth, the provider pattern: is it only Gmail users, or all providers? A single-provider pattern points to that provider's filtering change; an all-provider pattern points to your own authentication or reputation. Fifth, content changes: did you recently edit the verification template, add an image, or change the link domain? Template changes are among the most common causes of sudden deliverability drops, and the easiest to overlook, because "we only changed a template" does not sound like something that breaks delivery.

When choosing a sending provider, ask five questions before committing. One, does it support the authentication setup you need, with a graphical setup for SPF, DKIM, and DMARC rather than hand-assembled DNS records? Two, does it offer a dedicated transactional channel, or do transactional and marketing mail share one queue — shared queues mean a marketing peak slows transactional delivery? Three, are bounces, complaints, opens, and clicks reported per message type, or only as blended totals — blended totals tell you nothing useful about transactional mail? Four, does it offer webhooks or an API so you learn in real time that a message bounced or was marked as spam, rather than discovering it in a weekly report? Five, is the free tier enough to carry you to revenue — transactional volume grows with users, and a free tier that cuts off at the moment of growth effectively blocks your signup entrance at the worst possible time? The provider with the best answers to those five questions is not necessarily the cheapest, but it is the one that costs you fewer midnight alerts.