The email your software sends is worth nothing if it lands in spam.
A one-time password that arrives four minutes late is a customer who has already rung your office. An invoice sitting in the Promotions tab is a payment that waits a week.
Sending email from an application is easy. Having it arrive is a separate job, and most of that job is about your domain rather than your code.
An email API is a service your application calls to send a message, instead of running a mail server yourself. The provider keeps the sending reputation, handles the retries, and reports what happened to each message: delivered, bounced, opened, marked as spam. Brevo, Amazon SES, Postmark and SendGrid all do that same basic job.
Where it earns its place.
The email your software actually sends
- One-time passwords and password resets
- Order confirmations and invoices with the PDF attached
- Appointment and payment reminders
- Reports that go out on a schedule to people at a desk
- Alerts to your own team when a job fails at night
- The welcome message that carries somebody’s first login
Why it lands in spam
Almost always the domain, not the wording. Three records decide most of it, and they are set once.
- SPF, saying which servers may send as your domain
- DKIM, signing the message so it cannot be altered on the way
- DMARC, telling the receiver what to do when the first two fail
- A separate sending subdomain, so a campaign cannot damage your invoice delivery
- A reply-to address a human being actually reads
We set these up with whoever holds your DNS. Until they are right, nothing else on this page matters.
Transactional and marketing are different jobs
Mixing them is the commonest reason a business quietly loses its delivery and never works out why.
- Transactional mail goes to one person because they did something
- Marketing mail goes to a list, and needs consent and an unsubscribe link
- Complaints against a campaign follow the domain that sends your invoices
- Different subdomains, and often different providers
- The campaign tool belongs with your marketing team, not inside the application
What we build around the sending
- Trigger
- Template
- Send
- Track
- Retry
- Templates your team can edit without waiting for a release
- A queue, so a slow provider never holds up the screen somebody is on
- Retries with a limit, and a record when it finally fails
- Webhooks writing bounces and complaints back onto the customer record
- A suppression list, so an address that keeps bouncing is left alone
- A copy of what was sent, for the day somebody says they never got it
When email is the wrong channel
Worth saying out loud in India. Email here is a habit more than a decision.
- A one-time password that has to arrive in seconds
- A delivery update somebody reads standing in a queue
- Anything aimed at a customer who only opens WhatsApp
- An alert at midnight, which belongs in a phone notification and a phone call
Email stays right for the things people keep: the invoice, the statement, the report, the message with an attachment.
When this is the right choice.
- Your software sends invoices, receipts or statements with attachments
- You need a record of what was sent and whether it arrived
- Sign-in, verification or password resets by email
- Scheduled reports going to people who read them at a desk
- Customers who correspond by email, as institutional and B2B buyers do
When it is not.
- Marketing campaigns, which belong in a platform built for lists, consent and unsubscribes
- Anything urgent for a customer who will see WhatsApp first and email on Sunday
- A domain whose DNS nobody can change, until that access is sorted out
- A bought or scraped list, which no provider will keep you on for long
- One or two messages a week that a person can perfectly well send themselves
Questions we are asked about it.
Why do our emails go to spam?
The wording is rarely the problem. Usually it is SPF, DKIM or DMARC missing or wrong, a new domain with no sending history, or a campaign that drew complaints from the same domain. We check the records first.
Which provider do you use?
Brevo and Amazon SES cover most of what we build, with Postmark where transactional delivery has to be as good as it gets. The right choice depends on volume, where your customers are, and what your team wants to manage.
Can our team edit the wording?
Yes, and they should. Templates sit where operations or marketing can change the words without a release. The parts a developer owns are the ones carrying data, such as the invoice table.
Do we need SMS as well?
For one-time passwords and anything time-sensitive in India, usually yes. Email is for the record, SMS and WhatsApp are for the moment. Most systems we build use both, for different messages.
What happens when an email bounces?
The provider tells us through a webhook, we mark it against the customer, and repeated failures stop further sending to that address. Your staff see a bad address on the record instead of wondering why nobody replies.
Can you move us off sending from our own server?
Yes, and it is usually a small piece of work. The application changes how it sends, the DNS records are corrected, and old mail stays where it is. Most of the effort goes into the domain, not the code.
Services that use it.
Not sure Email APIs is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private