DEV Community: Abhishek Rajpurohit

Why Your Emails Land in Spam: A Teardown for People Who Aren't Developers

Abhishek Rajpurohit — Wed, 21 Oct 2026 17:16:33 +0000

Originally published on my blog, where I keep it updated.

A founder messaged me last week with a familiar complaint: "I sent an invoice from our company email and the client said it landed straight in spam. We've never had this problem before."

Nothing about their email had changed. What changed was everything invisible around it — and that's the part almost nobody explains without fifteen acronyms in the first paragraph. So here's the teardown without those. No SPF, DKIM, or DMARC jargon until I've explained the idea it stands for in plain words first.

Think of email like physical mail, not a phone call

When you send a text message, it goes straight from your phone to theirs. Email doesn't work that way. It's more like posting a letter: it passes through several sorting offices (mail servers) before it reaches the recipient's mailbox. At every sorting office, someone glances at the envelope and asks one question — "is this really from who it says it's from?"

That question is the entire spam problem in a sentence. Spammers have always been able to write "From: yourbank@example.com" on an email the same way anyone can write a fake return address on a paper envelope. So mailbox providers (Gmail, Outlook, Yahoo) built a set of checks to verify the return address before they'll trust it. If your domain hasn't set those checks up, you look exactly like a spammer to the sorting office — even though every word in your email is genuine.

The three checks, explained without the acronyms

Check 1 — "Is this server allowed to send mail for this domain?"
Every domain can publish a public list of the mail servers allowed to send on its behalf — think of it as a company saying "only these three delivery trucks are authorized to drop off mail with our logo on it." When an email arrives, the receiving mailbox checks the sending server against that list. No list published, or the sending server isn't on it, and the email looks unauthorized on arrival.

Check 2 — "Was this message tampered with in transit?"
This one attaches an invisible, cryptographic seal to each outgoing email — like a wax seal on a letter that cracks visibly if anyone opens it before it arrives. The receiving server checks the seal against a key the domain has published. A missing or broken seal doesn't just mean the email might have been altered; the bigger problem is unsealed mail simply reads as lower-trust from the start.

Check 3 — "What should happen to mail that fails the first two checks?"
This is a policy the domain owner publishes, telling every mailbox provider in the world what to do with mail that fails checks 1 and 2: let it through anyway, mark it as suspicious, or reject it outright. Most small businesses have never set this policy at all — which means mailbox providers fall back to their own judgment, and their judgment skews toward "when in doubt, spam folder."

That's it. Three checks, three plain questions: who's allowed to send, was it tampered with, and what happens if something fails. (Their real names are SPF, DKIM, and DMARC, in case you ever need to say them to a developer — but you don't need the names to understand the problem.)

What the actual teardown looked like

I ran the founder's domain through a checker and found the pattern that shows up in maybe eight out of ten "why is my email going to spam" cases:

Check 1 existed but was incomplete — the list of authorized senders only included their old email provider from two migrations ago. Their current provider wasn't on it, so every email they sent was technically unauthorized.
Check 2 wasn't configured at all — no cryptographic seal, so every email arrived looking unsealed by default.
Check 3 didn't exist — no policy at all, meaning mailbox providers were making a judgment call on every single message with zero guidance from the domain.

None of this was caused by anything the founder did wrong in the moment. It accumulated silently over two provider migrations and about three years, the way a lot of infrastructure debt does — nobody breaks it on purpose, it just never gets revisited after the initial setup.

Why this matters more than it looks like it should

A broken authorization setup doesn't just cost you the one email that landed in spam. Mailbox providers build a running trust score for every sending domain, based on how consistently your mail passes these checks. Every failed check nudges that score down a little. Enough failed checks, and all your mail — including the messages that would otherwise have sailed straight into someone's primary inbox — starts getting treated with suspicion. It's less "one bad email" and more "a slowly declining credit score for your domain."

The fix, once you know what's actually broken, is usually a few DNS records — genuinely a 20-minute task for whoever manages your domain, not a re-architecture. The hard part was never the fix. It was knowing which of the three checks was actually the problem, since the symptom (mail in spam) looks identical no matter which one failed.

Check your own domain

I built Email Health Checker for exactly this — it runs all three checks against any domain and explains what's missing in plain English, not a wall of DNS record syntax. It's free, takes about ten seconds, and doesn't require you to know what SPF, DKIM, or DMARC stand for before you can act on the result.

If you've ever had someone tell you "your email went to my spam folder" and had no idea why, that's the ten seconds worth spending.

If you'd rather own the whole mail stack, I wrote up why I built my own email server from scratch.

Evolution API vs OpenWA vs Meta Cloud API: Which WhatsApp API Should You Use?

Abhishek Rajpurohit — Wed, 21 Oct 2026 17:11:08 +0000

Originally published on my blog, where I keep it updated.

"Evolution API" is one of the fastest-rising WhatsApp searches in India this year. Most people find it the same way I found OpenWA: they want WhatsApp automation without a ₹3,000/month BSP subscription. Before you pick one, you need to know how each one actually talks to WhatsApp, because that decides whether your number survives.

I run OpenWA with n8n for my own alerts, and I've set up Evolution API and Meta's Cloud API for clients. This is the comparison I wish I'd had.

The one thing that matters: how it connects

There are only two ways software can send WhatsApp messages:

Pretend to be WhatsApp Web. Scan a QR code and the tool runs a WhatsApp Web session for you. Free, works with any normal or Business app number, but it's against WhatsApp's terms and Meta can ban the number.
Use Meta's official WhatsApp Business Platform (Cloud API). Verified business, approved templates, pay per template message. No ban risk from the method itself.

Every WhatsApp tool you'll see is one of these underneath, even if its landing page doesn't say so.

	OpenWA	Evolution API	Meta Cloud API
How it connects	WhatsApp Web via whatsapp-web.js (runs a headless browser)	WhatsApp Web via Baileys (WebSocket, no browser) or the official Cloud API	Official Meta API
Cost per message	₹0	₹0 on Baileys; Meta's rates on Cloud API	₹0.86 marketing, ₹0.115 utility (+18% GST)
Ban risk	Yes	Yes on Baileys; no on Cloud API	No (unless you spam)
Template approval	Not needed	Not needed on Baileys	Required for messages outside the 24-hour window
Needs	Docker (SQLite built in)	Docker + PostgreSQL/MySQL, Redis recommended	Meta Business account, verified number
Licence	Open source	Apache 2.0 plus extra conditions (see below)	Proprietary, Meta's terms
Built-in integrations	REST API + webhooks	Chatwoot, Typebot, Dify, OpenAI, RabbitMQ, Kafka, SQS, S3/MinIO	Webhooks, any BSP

OpenWA

OpenWA is an open-source WhatsApp gateway built on NestJS and whatsapp-web.js. You run it in Docker, scan a QR code, and get a REST API plus webhooks.

Good

Simplest to start: one compose command, no external database
Perfect for personal automation: server alerts, reminders to yourself, a family group bot
Works well with n8n. I have a full API reference with n8n workflows

Not so good

Runs a real headless Chromium, so it uses more RAM than Baileys-based tools (plan for 1 GB+ per session)
One session per instance in a typical setup
Breaks when WhatsApp Web changes, until the library catches up

Setup guide: Self-host a free WhatsApp API with n8n and OpenWA.

Evolution API

Evolution API started as a fork of CodeChat on top of the Baileys library and is now maintained by the Evolution Foundation (about 10k GitHub stars). It's the most complete self-hosted option.

Good

Two engines in one: start on Baileys (free), switch an instance to the official Cloud API later without rewriting your integration
Multi-instance: many numbers from one server, each with its own API key
Native Chatwoot integration: a free shared inbox for your support team. This is the main reason Indian SMBs pick it
Baileys talks to WhatsApp over WebSockets with no browser, so it's lighter per session than OpenWA
Typebot, Dify and OpenAI hooks for chatbots without writing glue code

Not so good

More moving parts: PostgreSQL or MySQL, plus Redis for caching
Baileys mode has the same ban risk as any WhatsApp Web bridge
Docs and community are mostly Portuguese-first (the project is Brazilian), though the English docs are fine for setup

The licence clause to read before you sell it

Evolution API is Apache 2.0 with extra conditions. From the LICENSE file:

If you use its frontend components, you can't remove or change the Evolution API logo and copyright in the console.
If you use Evolution API in any project, including closed-source software, you must show a clear notice that Evolution API is being used, visible to system administrators in the docs or settings page.

If you don't meet these, you may need a commercial licence. For an agency building a white-label WhatsApp CRM for Indian clients, this matters. Email the maintainers before you build a product on it.

Meta Cloud API (direct)

The official route. You create an app in Meta for Developers, verify your business, register a number, and get approved templates. Meta hosts it; you just call the API and receive webhooks.

Good

No ban risk from the connection method
No BSP subscription if you integrate directly (n8n's WhatsApp Business Cloud node does this)
Green-tick eligibility, catalogs, flows, Click-to-WhatsApp ads with a free 72-hour window
Replies inside the 24-hour customer service window are free

Not so good

Business verification takes days, and some Indian sole proprietors struggle with the documents
Templates need approval, and Meta re-categorises "utility" messages that read like promotions as marketing (about 7.5× the price)
The number can't be used in the normal WhatsApp app at the same time (coexistence options exist but have limits)

The full rupee breakdown is in WhatsApp Business API pricing in India.

Which one should you use?

Your situation	Use
Personal alerts, home-lab notifications, your own number	OpenWA
Small team needs a shared WhatsApp inbox (Chatwoot), low volume, accepts some risk	Evolution API (Baileys)
Same as above, but you'll go official once it works	Evolution API, then switch the instance to Cloud API
Messaging customers at scale, broadcasts, OTPs, anything your business depends on	Meta Cloud API
Marketing broadcasts to cold lists	None. You'll get banned on a bridge and penalised on the official API

My rule: if losing the number would hurt the business, use the official API. The bridges are great for internal and personal use, and for proving an idea before paying Meta.

How to lower ban risk on a bridge

None of these make it safe, but they help:

Use a number that's been active for months, not a new SIM
Message people who saved your number or messaged you first
Don't send identical text to hundreds of people. Space messages out
Keep the phone online and the linked session stable. Don't re-scan QR codes daily
Never use your main business number for testing

For workflow ideas that stay on the safe side (alerts, replies, internal groups), see WhatsApp n8n workflow varieties.

Quick install comparison

OpenWA: one compose file, zero config.

git clone https://github.com/rmyndharis/OpenWA.git
cd OpenWA
docker compose -f docker-compose.dev.yml up -d

Evolution API: app + Postgres + Redis, best with compose. The official repo ships a docker-compose.yaml. Clone it, set AUTHENTICATION_API_KEY and the database URL in .env, then:

git clone https://github.com/evolution-foundation/evolution-api.git
cd evolution-api
cp .env.example .env   # set AUTHENTICATION_API_KEY, DATABASE_CONNECTION_URI
docker compose up -d

Meta Cloud API: nothing to install. Create the app at developers.facebook.com, add the WhatsApp product, and copy the phone number ID and access token into n8n.

Need help picking a route, or moving a bridge-based bot onto the official API without downtime? Get in touch.

WhatsApp Business API Pricing in India (2026): Per-Message ₹ Rates, GST and Real Cost Math

Abhishek Rajpurohit — Wed, 21 Oct 2026 17:10:51 +0000

Originally published on my blog, where I keep it updated.

"How much does the WhatsApp API cost in India?" is one of the most common questions I get from clients — and "whatsapp business api pricing india" is a rising search on Google Trends. Most answers online are BSP sales pages that blend Meta's charges with their own fees. This post separates the two.

Last checked: 11 October 2026. Meta can change rates on 1 January, 1 April, 1 July and 1 October each year, so re-check the official rate cards before you budget.

How Meta charges (since July 2025)

Meta bills per delivered template message, not per conversation. The price depends on two things:

The template category — marketing, utility, or authentication
The recipient's country code — +91 numbers use the India rate

Anything that isn't a template (your normal replies inside a chat) is a service message.

India rates in ₹

Meta publishes the INR rate card as a downloadable file rather than on the page. The figures below are the India rates as reported by multiple BSPs from Meta's card, before GST:

Category	Per message (₹, excl. GST)	Typical use
Marketing	0.8631	Offers, broadcasts, cart reminders
Utility	0.1150	Order updates, invoices, delivery alerts
Authentication	0.1150	OTPs to Indian numbers
Authentication-international	2.4971	OTPs sent to +91 numbers by businesses registered outside India

Meta raised India's marketing rate on 1 January 2026, and the authentication-international rate on 1 April 2026. India was not part of the 1 October 2026 rate changes.

Volume discounts

Only utility and authentication get cheaper with volume, up to 30% off at very high monthly counts (millions of messages). Marketing has no volume tier. Tiers are counted per month across all WhatsApp Business Accounts in your Meta business portfolio. For most Indian SMBs sending a few thousand messages a month, assume list price.

What's free

Per Meta's own pricing pages:

Service messages are free. When a customer messages you, a 24-hour customer service window opens and your replies cost nothing.
Utility templates sent inside an open service window are free. Send the order confirmation while the customer is still chatting and it costs ₹0.
Click-to-WhatsApp ads and Facebook Page CTA buttons open a 72-hour free window for any message type, if you reply within 24 hours. (Mobile app users only — not WhatsApp Web/Desktop.)

Some BSP blogs claim a 1,000-per-month cap on free service messages starting 1 October 2026. I could not find this on Meta's developer docs or the WhatsApp Business pricing page as of today, so treat it as unconfirmed until it shows up there.

The three costs nobody adds up

Your real bill is:

Meta message charges
+ 18% GST on Meta charges
+ BSP platform fee (if you use one)

Meta charges — the table above.
GST — 18% on top. A ₹0.8631 marketing message actually costs about ₹1.02.
BSP fee — WATI, Interakt, AiSensy, Zoko and others charge a monthly subscription and sometimes a per-message markup. Compare their per-message price to Meta's rate: anything above ₹0.8631 for marketing is markup.

You can skip the BSP by using Meta's Cloud API directly — no subscription, you pay Meta only. You'll need a developer (or n8n) to send messages and handle webhooks.

Worked examples (monthly, Meta charges only)

A D2C brand sending 10,000 marketing broadcasts

10,000 × ₹0.8631 = ₹8,631
+ 18% GST        = ₹10,184.58

A clinic sending 10,000 appointment reminders (utility, outside the service window)

10,000 × ₹0.1150 = ₹1,150
+ 18% GST        = ₹1,357

If half of those reminders go out while patients are already chatting with you, those are free — the bill halves.

An app sending 5,000 login OTPs (authentication, Indian business)

5,000 × ₹0.1150 = ₹575
+ 18% GST       = ₹678.50

Same OTPs from a business registered outside India: 5,000 × ₹2.4971 = ₹12,485.50 before GST — over 20× more.

How to cut the bill

Categorise templates honestly. Meta reclassifies "utility" templates that read like promotions as marketing — about 7.5× the price.
Send utility messages inside the service window whenever the flow allows it.
Use Click-to-WhatsApp ads for acquisition — the 72-hour free window covers the whole first conversation.
Don't broadcast to cold lists. Low engagement hurts your quality rating and can cap your sending limits.
Move to INR billing. Meta launched INR billing for India in January 2026, and eligible accounts must migrate by 31 December 2026 — after that, Meta stops delivering messages from their non-INR accounts.

Official API vs unofficial bridges

Unofficial tools that drive WhatsApp Web (like OpenWA) cost ₹0 per message, but they break WhatsApp's terms and risk a permanent number ban. They're fine for personal automation and internal alerts — I run one, see my OpenWA + n8n guide — but customer-facing messaging at scale belongs on the official API.

Quick answer

Marketing: ~₹1.02 per message incl. GST
Utility / OTP: ~₹0.14 per message incl. GST
Replies to customers: free
Platform fee: ₹0 with Meta Cloud API directly, or whatever your BSP charges

Need WhatsApp automation wired into your CRM, Razorpay or n8n without a monthly BSP bill? Let's talk.