Email that lands in India. Infrastructure that scales.
Drag-and-drop campaigns, AMP emails, automations and transactional SMTP on AWS Mumbai. GST invoices, DPDP consent, Indian mailbox tuning.
99.98%
delivery, server-accepted
Built for the way Indian teams actually work.
- 14 Indian language templates
- AMP cart recovery
- SMTP relay + REST API
DPDP-native from day one.
Consent at ingestion, purpose per workflow, deletion that reaches memory and logs. Sub-processors and DPA published.
Visit the Trust CenterOne bill. INR. GST invoice.
Included usage in every plan. Overage never costs more than pay-as-you-go. Spend cap on by default.
See pricingOne runtime. Every channel.
Multi-agent orchestration
Design, deploy and observe multi-agent systems for sales, support, collections and operations.
Explore14 Indian languages
Inbound and outbound calls in Hindi, Marathi, Tamil, Telugu and 10 more languages.
ExploreVisual automation
Trigger from WhatsApp, email, voice, forms or your API.
ExploreBring us one workflow. We’ll show you the agent.
45-minute audit, written roadmap, no commitment. Or start a 14-day trial with the full 25,000 contacts.
The short version
- LoopSend is the sending layer: SMTP relay and a REST API for product mail, plus a campaign builder for marketing mail, running on AWS Mumbai.
- Delivery and placement are different numbers. The 99.98% figure on the product card is mail accepted by the receiving server, not mail that reached the inbox tab.
- Authentication is not optional: SPF and DKIM must pass, DMARC must align, and a domain that fails alignment will land in spam regardless of copy quality.
- Gmail and Yahoo bulk sender rules apply once you send roughly 5,000 messages a day to their users, and they require one-click unsubscribe and a spam rate under 0.3%.
- Complaint rate, not open rate, is the number that decides whether a send continues. Spend cap and suppression logic are enforced server-side.
- Every invoice is in INR with 18% GST added, and the GSTIN you enter is printed on the tax invoice for input credit.
LoopSend is a sending layer, not a reputation guarantee
LoopSend is the name we use for the transactional half of the email product: an SMTP relay and a REST API that your application calls when it needs to deliver a password reset, an order confirmation, a GST invoice or a statement. The campaign half is the visual builder most teams recognise, with templates, automations and AMP blocks for cart recovery. Both halves run on the same authenticated domains and write to the same suppression ledger, which is the part that matters when a compliance review asks who was mailed and why.
It is worth being blunt about what this is not. LoopSend does not host your mailbox, does not read replies, does not rent or sell contact lists, and cannot promise that a message lands in the primary tab. It authenticates your domain, signs every message, throttles to the reputation your domain has actually earned, retries transient failures, records what the receiving server said, and stops sending when bounce or complaint rates cross a line you set. Those are engineering guarantees. Inbox placement is a negotiation with four large mailbox providers, and no vendor can unilaterally win it for you.
The single biggest decision at onboarding is shared or dedicated IP. Shared pools are cheaper and fine below roughly a hundred thousand messages a month, but your reputation is partly borrowed from other senders in the pool. A dedicated IP is isolated and predictable, and it starts with no reputation at all, which is why it needs warm-up. We will tell you which one fits your volume rather than defaulting to the higher-margin answer, and we will tell you when a dedicated IP would be a mistake.
SPF, DKIM, DMARC and BIMI, in the order that matters
SPF is a list of servers allowed to send for a domain, published as a TXT record. It breaks in predictable ways: more than ten DNS lookups, a stale include for a vendor you stopped using, or a relay that rewrites the envelope sender so the check runs against a domain you do not control. DKIM is stronger because it survives forwarding: the message carries a cryptographic signature over selected headers and the body, and the receiving server verifies it against a public key in DNS. SPF checks the envelope, DKIM checks the message, and you want both passing on every stream.
DMARC is the policy that ties them together. It tells the receiver what to do when a message claiming your domain fails alignment: do nothing, quarantine, or reject. Alignment is the subtle part. A message can pass SPF against a bounce domain and still fail DMARC because the visible From domain does not match. Start at p=none with reporting on, read the aggregate reports for two to four weeks, fix the senders that fail, then move to quarantine and finally reject. Jumping straight to reject before you know every sender on the domain is how invoice mail silently disappears.
BIMI is last because it depends on everything above. Your logo appears next to the message only if DMARC is at enforcement, the logo is a valid SVG Tiny PS file, and for Gmail and Apple Mail you hold a Verified Mark Certificate tied to a registered trademark. That certificate costs money and takes time, and Indian brands without a registered mark cannot get one yet. Treat BIMI as a finishing touch for brands that already have authentication clean. Without enforcement it does nothing at all.
The Gmail and Yahoo bulk sender rules, translated
Since February 2024, Gmail has applied a stricter set of requirements to bulk senders, which it defines as anyone sending about five thousand or more messages a day to Gmail accounts. Yahoo published a parallel policy. Authentication with SPF or DKIM became mandatory for all senders, not only bulk ones, and DMARC became mandatory for bulk. The practical effect in India is that a growing D2C brand crosses the threshold during a festive sale without changing anything about its process, and suddenly discovers rules it has technically been subject to for months.
The rule teams underestimate is one-click unsubscribe. Bulk senders must include the List-Unsubscribe and List-Unsubscribe-Post headers defined in RFC 8058, and must honour the request within two days. A visible unsubscribe link in the footer is not the same thing. Many Indian ESPs still ship only the footer link, which is why a list that looked compliant starts generating complaints and policy failures. Our builder adds both headers by default and the unsubscribe endpoint processes the request immediately, not at the next nightly sync.
The third rule is a spam rate ceiling. Google publishes a target of staying under 0.1% in Postmaster Tools, with 0.3% treated as the line you must not cross. That is a rate, not a count, so a small list can cross it with a handful of complaints. The number is measured from recipients who press the spam button, which means the fix is usually frequency and relevance rather than a technical change. If you are sending four campaigns a week to a list that expects one, no authentication record will save the send.
IP warm-up is a schedule, not a switch
A new dedicated IP has no history. Mailbox providers have no reason to trust it, so they watch how recipients behave: opens, replies, deletions, complaints, and whether volume arrives in a predictable shape. Warm-up is the process of earning that trust by sending modest, highly engaged volume first and increasing it only while complaints stay flat. The common failure is buying a dedicated IP on Monday and pushing the full festive campaign through it on Wednesday, then concluding that the vendor has a deliverability problem.
The schedule below is a sample, not a promise. Real ramps depend on list size, engagement quality and which providers you hit hardest. A workable shape starts at a few hundred messages a day and roughly doubles weekly, with the most engaged segment first: people who opened or clicked in the last thirty days. Gmail, Microsoft and Yahoo see different proportions, so a ramp that is smooth for one can spike for another. If complaint rate moves above your warning line, hold the volume where it is for a week rather than pushing through.
Warm-up also applies to shared pools, just invisibly. When we move a customer onto a new shared pool, the pool is warmed before it takes traffic, which is one reason onboarding takes a few days rather than an hour. If you already have a warmed domain elsewhere, keep it. Migrating domains for cosmetic reasons throws away the only asset that took months to build, and no amount of template quality compensates for a domain that receivers have never seen.
List hygiene: verify, tier, then sunset
Every list decays. People change jobs, abandon addresses, and type a domain wrong at checkout. An address that hard bounces once is gone; a second attempt costs money and reputation for nothing. Verification at capture removes syntax errors and known-bad domains, and periodic re-verification catches the addresses that died since. Verification is metered separately from sending at ₹0.35 per address, so it is worth doing deliberately rather than re-cleaning a list every month.
Tiering is the more useful habit. Split the list by recent engagement: opened or clicked in thirty days, sixty days, ninety days, and colder than that. Send the same campaign to the warm tier first, watch the response for a few hours, then decide whether the colder tiers get the message at all. Cold segments should receive a re-permission message rather than a discount, because the goal is to find out whether the person still wants mail, not to extract one more order from a dead address.
Sunsetting is the part teams resist. If someone has received ten messages and never opened one, the honest conclusion is that they do not read your email, and continuing to send lowers the engagement signal for everyone else. We support automatic sunset rules: after a defined window of no engagement across a defined number of sends, the contact moves to a dormant state, stops counting as a marketing contact, and gets one final re-permission message. Unsubscribed and suppressed contacts are free and unlimited, so hygiene is not a billing trick. It is the only way the engagement signal stays true.
Bounce and complaint thresholds that stop a send
Thresholds only work if something acts on them automatically. A dashboard that shows a 9% bounce rate after the send finished is a post-mortem, not a control. Our defaults are deliberately conservative: a warning at 2% hard bounce and a hard stop at 5%, with complaints measured in basis points because a complaint rate of even 0.3% is significant. The send pauses, the offending segment is quarantined, and an owner is notified with the addresses and reason codes attached.
Hard bounces should be near zero on a clean list, so a sudden rise usually means a bad import, a typo in a domain, or a purchased list somebody uploaded. Soft bounces are different: a full mailbox or a temporary greylist response should be retried with backoff, not treated as a dead address. The relay retries 4xx responses on a schedule and gives up after a defined window, then records the final state. This distinction matters because suppressing every soft bounce quietly deletes reachable people from your list.
Complaints are the signal to trust most, because they come from the recipient rather than from an algorithm. A complaint should immediately suppress the address across every stream, including transactional mail, and should trigger a review of the segment that produced it. If complaints cluster around one template or one acquisition source, the problem is upstream of the send. If they cluster around frequency, the calendar needs to change. We surface complaint rate by campaign, by segment and by source so the review has something to look at.
One suppression ledger for every stream
Suppression is the least glamorous part of email and the one most likely to cause a legal problem. In a stack with a campaign tool, a product database and a separate transactional relay, an unsubscribe often lives in only one of them. The contact unsubscribes from marketing, then receives a lifecycle message from the product team a week later, and the complaint that follows is entirely rational. One ledger, checked at send time by every stream, removes that failure mode.
Our ledger stores the address, the reason, the timestamp, the source and the scope. Reasons include unsubscribe, hard bounce, complaint, manual block, regulatory request and deletion request. Scope distinguishes a marketing suppression from a global one, because there are legitimate cases where a person wants order updates but not offers. The default for complaints and deletion requests is global. Checks happen synchronously at send time, not from a cached copy refreshed overnight, so a suppression added at 14:02 applies at 14:03.
The ledger also holds the consent state that DPDP requires you to prove: what notice the person saw, what purpose they agreed to, when, and through which channel. That record is exportable, which matters when someone exercises a right to a copy or to erasure. Erasure has to reach backups and logs on a defined schedule, and it has to reach the model memory used by any agent that reads the contact record. A suppression list that only covers the send path is not enough.
Campaigns and transactional mail are different products
Marketing mail and product mail look similar in a template editor and behave nothing alike in production. Marketing is discretionary: the recipient did not ask for it at that moment, so it needs consent, an unsubscribe path, engagement tiering and a bulk-friendly sending pattern. Transactional mail is expected: a password reset that arrives late is a support ticket, and a receipt that lands in spam is a finance problem. Mixing them on one subdomain means a marketing complaint drags down the deliverability of the receipts.
We recommend separate subdomains from day one, for example mail for campaigns and transactions or a dedicated product subdomain, each with its own DKIM key and its own DMARC reporting. The transactional stream gets a priority queue, aggressive retry on transient errors, and delivery webhooks so your application can show the real state to the user. The campaign stream gets throttling, wave sending and engagement-based segmenting. Both read the same suppression ledger, so a global block applies everywhere.
The cost model follows the same split. In-plan email overage is ₹0.03 per delivered email, and pay-as-you-go is ₹0.05, so overage never costs more than buying standalone capacity. Transactional volume counts against the same allowance, which surprises teams who assume receipts are free. Plan for receipts at the volume you actually generate: an order confirmation, a shipping update and a delivery note is three messages per order, not one.
Invoices, GST and the finance view
Email spend is a line item that finance reviews, so the paperwork has to be ordinary. Every payment produces a tax invoice in INR with 18% GST added to the plan price, your GSTIN printed when you supply it, the place of supply, and a sequential invoice number that survives an audit. Plans are quoted exclusive of tax because that is how Indian B2B buyers compare, and because a price that silently includes tax makes input credit impossible to reconcile. The pricing page and this page read from the same source, so the number you see is the number on the invoice.
For a company with multiple entities, billing details are per workspace rather than per user, and the invoice can be raised to a different legal entity than the one operating the account. Annual plans can be paid by NEFT or RTGS with a purchase order, which is still how most Indian enterprises procure. Monthly plans can use UPI, cards or netbanking. The invoice is generated at payment, not at month end, and a consolidated statement is available for finance teams that need one document per quarter.
Consumption is metered per delivered email, not per send attempt, so a message that the receiving server rejected is not billed. Verification is metered separately at ₹0.35 per address, because it is a different operation with a different cost. Spend cap is on by default: when the allowance is exhausted, the workspace either stops sending marketing mail, tops up automatically, or holds messages in a queue until you decide. Nobody should discover a five-figure overage from a bank statement, and the default settings exist to make that impossible.
Consent under DPDP for email
The Digital Personal Data Protection Act treats email marketing as processing personal data for a purpose the person must be told about. In practice that means a notice that says what you will send, how often, and how to stop, followed by an affirmative action that is not bundled into terms of service. A pre-ticked box is not consent. A business card dropped in a bowl at an exhibition is not consent for a newsletter. Purchase of a product is not consent for unrelated marketing, even though it often gets treated that way.
The Act does list legitimate uses that do not require consent, but they are narrow: state functions, medical emergencies, employment purposes and similar. Marketing is not one of them. That is the sentence to remember when a growth team asks whether they can email a scraped list because the addresses are public. Public availability is not a lawful basis, and the penalty exposure sits with the data fiduciary, which is your company, not the vendor.
Operationally, consent has to be captured, stored with its purpose and timestamp, honoured on withdrawal, and erased when the purpose ends. Our forms record the notice version and the source, the ledger enforces withdrawal across every stream, and erasure requests propagate to the contact record, the send logs and the agent memory within a stated window. If you already have consent records in a CRM or a spreadsheet, they can be imported, but we will flag any record that lacks a timestamp or a stated purpose rather than pretend it is compliant.
What to measure, and what the card number means
Four numbers matter and they answer different questions. Delivered tells you whether the receiving server accepted the message. Placed tells you whether it reached the inbox, and it is only measurable by approximation, using seed panels and provider reporting. Read tells you whether a human opened it, and Apple’s Mail Privacy Protection has made that number unreliable since 2021, because images are prefetched whether or not anyone looked. Clicked tells you whether the message did a job. If you report only one, report clicks.
The 99.98% delivery figure on the product card is the first number: messages accepted by the receiving provider, measured across sending on the platform. It is not inbox placement, and it is not unique to us. Any competent relay will show a similar figure on a clean list, because a hard bounce is counted before delivery. We publish it because buyers ask, but we would rather you judge the product on complaint rate, click rate and how quickly a bad send gets stopped.
Placement testing is available as a seed-based estimate: send a message to a panel of mailboxes across Gmail, Outlook, Yahoo and the major Indian providers, then read where it landed and which authentication checks passed. It is a sample, not a census, and it should be read as a directional signal. Treat any vendor promising guaranteed inbox placement as a vendor who has misunderstood the problem, because the decision belongs to Microsoft, Google and their filters, not to a sending platform.
What is live, what is planned
Live today: SMTP relay and REST API, campaigns with AMP blocks, automations, fourteen Indian language templates, shared and dedicated IP pools, SPF and DKIM automation, DMARC reporting ingestion, one-click unsubscribe headers, suppression ledger, bounce and complaint stop-loss, delivery webhooks, GST invoicing and spend cap. Warm-up is run by our team during onboarding rather than exposed as a self-serve button, because the failure mode of a self-serve ramp is somebody setting it to maximum.
Planned and not shipped: a self-serve DMARC aggregate report viewer with per-sender drill-down, and BIMI guidance tooling that checks logo format and certificate status. Both are designed and scheduled, and both are labelled planned rather than implied to exist. A hosted mailbox is not planned at all; if you need business email hosting, that is a different product category and we will point you at one rather than pretend the relay covers it.
The honest summary is that LoopSend competes on the unglamorous parts: one suppression ledger, stop-loss that acts, Indian billing, and a team that will tell you when your list is the problem. If you want a tool that promises a 40% open rate, this is not it. If you want receipts that arrive and campaigns that stop before they damage the domain, the rest of this site explains how the pieces fit together.
Frequently asked questions
Do I need a dedicated IP for email?
Only above roughly a hundred thousand messages a month, or when compliance requires isolation. Below that, a warmed shared pool usually performs better because it already has history. A dedicated IP starts with no reputation, so it needs four to six weeks of ramped sending before it matches a healthy shared pool, and a seasonal sender pays for idle capacity all year.
Is the 99.98% delivery figure the same as inbox placement?
No. It measures messages accepted by the receiving server, after hard bounces are excluded. A message can be accepted and still land in spam or the promotions tab. Placement is estimated with seed panels and provider reporting, and no sending platform controls the final decision. Read the figure as a statement about the relay, not about the health of your list.
Can LoopSend send to a list I bought?
No. Purchased lists breach the platform terms and are ineffective in practice, because the recipients never asked for the mail and complain at a rate that damages the domain. If a partner offers an introduction, their opt-in covers their messages and not yours, so the first campaign under your brand still needs its own notice and agreement.
What happens when I cross the plan allowance?
Overage is billed at ₹0.03 per delivered email, which is below the ₹0.05 pay-as-you-go rate, and only delivered mail counts. Spend cap is on by default, so you choose between a hard stop, a queued backlog or automatic top-up rather than receiving a surprise invoice. The billing screen names the meter that triggered the cap, so the budget owner sees the cause.
Why did my campaign stop mid-send?
Almost always a stop-loss threshold: hard bounce above 5%, complaint rate above 30 basis points, or a suppression spike. The send pauses, the segment is quarantined and the owner gets the addresses with reason codes. You can raise a threshold, but we log who changed it and why. Thresholds apply per workspace, so an experimental send can pause the main schedule too.
Do you support BIMI logos in Gmail?
Yes, if the domain is at DMARC enforcement, the logo is valid SVG Tiny PS, and you hold a Verified Mark Certificate for a registered trademark. We help publish the record, but the certificate is issued by a third party and requires a trademark, so many early-stage brands cannot use BIMI yet. Without a mark, a consistent sender name and a verified domain are the practical alternative.
How does GST work on email plans?
Prices are in INR and exclude 18% GST, which is added on the invoice. Supply your GSTIN and it appears on the tax invoice with the place of supply, so your finance team can claim input credit. Annual plans can be paid by NEFT against a purchase order. The pricing page quotes the same pre-tax figure, so a quote and an invoice reconcile without adjustment.
Can transactional and marketing mail share a domain?
They can, but we advise against it. A marketing complaint affects the reputation of everything on that domain, including password resets and invoices. Separate subdomains with separate DKIM keys keep the two reputations apart while both still read one suppression ledger. If you must share a domain today, at least split the streams by subdomain before the first large campaign.
What counts as consent under DPDP for email?
A clear notice of purpose, an affirmative action that is not bundled with other terms, and a record of when and how it was given. Publicly available addresses and a prior purchase are not consent for marketing. Withdrawal must be honoured across every stream, and erasure must reach logs and agent memory. A record without a timestamp or stated purpose is not proof.
Does opening an email still mean anything?
Less than it used to. Apple Mail Privacy Protection prefetches images, so a large share of opens are machine events rather than human ones. Use clicks, replies and conversions as primary signals, and read open rate as a rough trend rather than a per-contact fact. For deliverability, watch replies and clicks; for content quality, ask readers directly.