Why Your System Emails Vanish: A Founder's Field Guide to Email Deliverability for SMEs

Why deliverability fails silently

Most software failures are loud. The server returns a 500, an exception lands in your logs, a dashboard turns red. Email deliverability is the opposite: it fails quietly, downstream, and after your code has already declared success.

Here is the mechanism that makes it so dangerous. When your application calls an email provider's API and gets back a 200 OK with a message ID, your code has done its job correctly. The provider accepted the message. But acceptance by the provider is not delivery to the inbox. Between that 200 and the customer's eyes sit a chain of decisions you do not control: the receiving mail server (Gmail, Outlook, a corporate Exchange) inspects your authentication, weighs your sending reputation, scores the content, and then routes the message to the inbox, the spam folder, or a silent drop. None of those outcomes produces an error your application will see in real time.

We learned this the hard way. In our own platform, we once had member-facing system emails that the application logged as sent successfully — the API returned clean — while a meaningful slice of new members simply never received them. The code was not throwing. The provider was not bouncing in a way our handler caught. The mail was being accepted and then never landing where it needed to. From the inside, everything looked healthy. From the customer's side, the product was broken at the very first step: account verification.

The trap is structural: your success log and the customer's inbox are two different sources of truth, and only one of them matters.

This is why deliverability belongs in the category of trust engineering, not marketing. A signup confirmation is a handshake. If the handshake silently fails, the user does not conclude "the email is in spam" — they conclude "this company doesn't work." For an SME trying to earn first-time trust, that is the most expensive failure mode there is.

The authentication stack: SPF, DKIM, DMARC

Receiving mail servers cannot tell, on their own, whether an email claiming to come from you@yourcompany.com is genuinely from you or from someone spoofing your domain. Three DNS-based standards exist to answer that question. Together they are the foundation of every deliverability conversation, and getting any one of them wrong is the most common reason legitimate mail gets filtered.

SPF — who is allowed to send

SPF (Sender Policy Framework) is a TXT record you publish in your domain's DNS that lists which servers are authorized to send mail on behalf of your domain. When you use a provider like Resend, Postmark, SendGrid, or Amazon SES, you add their sending infrastructure to your SPF record. The receiving server checks: did this message come from an IP the domain owner authorized? If your provider's servers are not in your SPF record, you fail this check — and many receivers treat an SPF failure as a strong spam signal.

The most common SPF mistake is the ten-lookup limit. SPF allows a maximum of ten DNS lookups when evaluating a record. If you stack several email tools — one for transactional, one for marketing, one for your CRM — and each adds an include:, you can silently blow past ten lookups, at which point the entire record returns a permanent error and all your authentication degrades at once. We have seen this take down mail that worked fine for months, simply because a new tool was added.

DKIM — proof the message was not tampered with

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message, signed with a private key held by your provider. You publish the matching public key in DNS. The receiving server verifies the signature, which proves two things: the message genuinely came from your domain, and it was not altered in transit. DKIM is what lets a receiver trust the From domain even if the message was forwarded.

DMARC — the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the instruction layer. It tells receiving servers what to do when a message fails SPF and DKIM alignment, and — critically — it asks them to send you reports. A DMARC record looks like v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com. The p= policy can be none (monitor only), quarantine (send failures to spam), or reject (refuse them outright).

The single most useful piece of advice here: start at p=none and read the reports before you tighten. DMARC reports are the only way to discover every system that sends mail as your domain — including ones you forgot about, like your old helpdesk tool or a billing platform. Jumping straight to p=reject without first auditing your real senders is how companies accidentally block their own invoices. Tighten the policy only after the reports show clean alignment for everything legitimate.

The sandbox-domain trap we walked into

Here is a specific, first-hand failure that almost no documentation warns you about clearly enough, because it does exactly what you do not expect: it works perfectly in testing and fails silently in production.

Most modern email providers give you a default sandbox sending address out of the box — something like onboarding@resend.dev or a provider-branded subdomain — so you can send your first test email in minutes without configuring any DNS. This is wonderful for a demo. It is a landmine for a real product.

In our own system, transactional mail was going out from exactly this kind of provider sandbox address. During development it worked flawlessly: every test email arrived, because the test recipient was us — the verified account owner. That is the catch. The sandbox sender is frequently restricted to delivering only to the verified owner of the provider account. The moment real members — strangers, on Gmail and Outlook addresses we did not own — tried to receive their verification emails, the messages silently failed. Our logs were clean. The provider returned success. And new members got nothing.

The sandbox domain is a development convenience that becomes a production trust failure the instant your audience is anyone other than you.

The fix is not glamorous, but it is mandatory: send from a real subdomain you own and have fully authenticated. We moved our system mail to a dedicated sending subdomain — something like send.yourcompany.com — and verified it end to end with SPF and DKIM. Using a subdomain rather than your root domain is deliberate: it isolates the sending reputation of your transactional mail from your primary domain, so a future mistake on one does not poison the other.

The lesson generalizes beyond one provider. An API that returns 200 proves the provider accepted your request and that your auth credentials are valid. It does not prove the message reached a real stranger's inbox. Those are different claims, and the gap between them is exactly where silent deliverability failures live. The only way to close it is to test with a recipient on an external mailbox you do not own.

Reputation, warm-up, and shared IPs

Authentication gets you in the door. Reputation decides whether you stay. Even with perfect SPF, DKIM, and DMARC, a brand-new sending domain has no track record, and receiving servers treat unknown senders with suspicion.

Domain and IP reputation is built slowly through consistent, wanted mail. Receivers watch your bounce rate, your spam-complaint rate, how often recipients open and reply, and how steady your volume is. A new domain that suddenly blasts a thousand emails on day one looks exactly like a compromised account or a spammer — and gets throttled accordingly.

• Warm-up matters. If you are launching a new sending domain, ramp volume gradually over days rather than firing your entire list at once. Transactional mail naturally warms up well because it is triggered by genuine user actions and tends to get opened.
• Shared vs. dedicated IPs. On most providers' starter plans, you send from a shared IP pool — your reputation is mingled with other customers. This is fine and even helpful at low volume, because the pool already has a warm reputation. At higher volume, a dedicated IP gives you control but also full responsibility for warming and maintaining it.
• Bounce and complaint hygiene. Every hard bounce and every spam complaint damages reputation. Honor unsubscribes instantly, stop mailing addresses that hard-bounce, and never buy lists. One bad send can undo months of good standing.

For most SMEs, the practical takeaway is: stay on your provider's shared pool, keep your lists clean, and let transactional mail do the quiet work of building a trustworthy sending pattern. Do not reach for a dedicated IP until your volume genuinely justifies it.

Separate your transactional and marketing mail

This is the architectural decision that prevents the most pain, and it is worth stating plainly: your password resets and your newsletters should not share a sending reputation.

Transactional mail — verification links, receipts, password resets, security alerts — is mail the user explicitly asked for and urgently wants. It must reach the inbox every single time. Marketing mail — announcements, promotions, digests — is mail the user tolerates. It generates spam complaints and unsubscribes at rates transactional mail never does. If you send both from the same domain or IP, the complaints generated by a promotional campaign degrade the reputation that your password resets depend on.

The clean pattern is to use separate sending subdomains: something like send.yourcompany.com for transactional mail and news.yourcompany.com or mail.yourcompany.com for marketing. Each gets its own authentication and builds its own reputation. A rough week on the marketing subdomain then has zero effect on whether a customer can reset their password.

There is an operational dimension too. We run a multi-language platform, and a detail worth flagging for any international SME: many email providers' free tiers verify one sending domain only. If you operate distinct domains per market or per brand, check this limit before you architect, because discovering it after launch means either paying to upgrade or temporarily routing one market's mail through another's domain — a compromise, not a solution.

How to diagnose a deliverability problem

When mail is "going missing," resist the urge to guess. Deliverability is diagnosable; work the chain from your side outward.

1. Confirm acceptance vs. delivery. Check your provider's own dashboard — not just your application logs. Providers distinguish accepted, delivered, bounced, deferred, and spam complaint. Your app log only knows about acceptance. The provider's event log is the first source of truth that tells you whether the receiving server actually took the message.
2. Send to external mailboxes you control. Create test accounts on Gmail, Outlook, and Yahoo that are not the owner of your provider account. This is the single test that would have caught our sandbox-domain failure immediately. If mail arrives for you but not for an external Gmail address, you have a reputation or sender-restriction problem, not a code problem.
3. Check authentication on a received message. Open a delivered email's raw headers and look for spf=pass, dkim=pass, and dmarc=pass. Any fail or none there points straight at a misconfigured DNS record. Mail-testing services let you send to a probe address that returns a full authentication report.
4. Read your DMARC reports. If you set rua=, you are receiving aggregate reports that show every source sending as your domain and whether each passed alignment. This reveals shadow senders and broken configurations you would otherwise never find.
5. Inspect content as a last step. Once authentication and reputation are clean, look at the message itself: spammy phrasing, a single giant image with no text, broken links, or a mismatched From name can still trip content filters. But content is rarely the cause when authentication is wrong — fix the stack first.

The discipline here is the same one we apply to all trust infrastructure: verify against the source of truth the customer experiences, not the one your code reports. The application's success log is comforting and frequently irrelevant.

The pre-launch deliverability checklist

Before you ship any product that sends mail to real strangers, walk this list. None of it is exotic; all of it is the difference between a verification email that lands and one that vanishes.

• Send from a domain you own, never a provider sandbox address. Use a dedicated subdomain for system mail (e.g. send.yourcompany.com).
• Publish SPF and include your provider — and verify you are under the ten-lookup limit if you use multiple tools.
• Enable DKIM through your provider and confirm the public key is live in DNS.
• Publish DMARC at p=none with a rua= report address, read the reports, and only then tighten toward quarantine or reject.
• Separate transactional from marketing mail onto different subdomains so promotional complaints never threaten your password resets.
• Test delivery to external mailboxes (Gmail, Outlook, Yahoo) that are not your provider-account owner — before launch, and again after any DNS change.
• Watch the provider's delivery dashboard, not just your app logs, and set alerts on bounce and complaint rates.
• Keep lists clean: suppress hard bounces, honor unsubscribes instantly, never buy a list.

Deliverability is unglamorous infrastructure, which is exactly why so many SMEs skip it until a customer complains that they "never got the email." By then you have lost the trust at the precise moment you were trying to earn it. Treat your transactional mail as a promise you are making, and engineer it to keep that promise every time.