If you send transactional or marketing email to customers in India, the Digital Personal Data Protection Act, 2023 (DPDP Act) applies to you -- regardless of which email provider you use. Here's a practical checklist, not a substitute for legal advice.
This is general information, not legal advice. Talk to counsel about how the DPDP Act applies to your specific business.
1. Know which role you're in
The DPDP Act distinguishes between a Data Fiduciary (the entity that decides why and how personal data is processed) and a Data Processor (the entity that processes it on the Fiduciary's behalf, under instruction). If you send transactional email to your own customers, you are the Data Fiduciary for that email traffic -- your email provider, including MailKaka, is a Data Processor. That means the underlying obligation to have a lawful basis for emailing your customers, and to honor their rights under the Act, sits with you, not your provider. Outsourcing the sending doesn't outsource the responsibility.
2. Have a lawful basis before you send
- Transactional email tied to a contract or service the customer signed up for generally has a clear basis.
- Marketing email typically needs affirmative consent, tracked and withdrawable.
- Don't rely on a provider's terms of service to establish your own lawful basis for you -- it can't.
- A cart-abandonment or re-engagement email is marketing, not transactional, even if it references a past order -- if you're treating it as implicitly consented-to because the customer once bought something, revisit that assumption.
3. Know who else touches the data
If you use a third-party email API, you're relying on their sub-processors too -- the cloud infrastructure they run on, any analytics or AI tooling they use, any third party that handles their billing. A provider that publishes exactly who those sub-processors are, and what each one does, makes your own due-diligence paperwork faster to complete. See MailKaka's own sub-processor table as an example of what to look for from any provider.
4. Honor data-subject requests -- including from people who aren't your account holders
The DPDP Act gives individuals rights (access, correction, erasure, grievance redressal) over their own personal data. If a recipient of your transactional email asks you to stop emailing them or to delete their data, that request goes to you as the Fiduciary, not to your email provider. Have a process for routing that request to whoever owns customer data decisions, not just to whoever manages the support inbox.
5. Appoint a Grievance Officer if the IT Rules, 2021 require it
Depending on your business, the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 may require a named Grievance Officer with published contact details. This is a separate requirement from the DPDP Act itself and applies based on what kind of intermediary your business is, not based on whether you send email -- check whether it applies to you specifically.
6. Keep a suppression list
Track bounces, complaints, and unsubscribes, and don't send to those addresses again. This is both good deliverability practice (see our SPF/DKIM/DMARC guide for why inbox providers care about complaint rates specifically) and part of respecting a recipient's withdrawal of consent under the Act.
7. Factor data residency into your vendor choice, even where it isn't strictly mandated
The DPDP Act doesn't require Indian email data to sit on Indian servers in every case -- but choosing infrastructure that does removes an entire category of cross-border-transfer question before it comes up, and matches what many enterprise customers' own procurement checklists already expect. See why AWS SES Mumbai matters for latency and compliance for the fuller version of that argument.
For the fully-worked example of how one company (this one) maps its own product to these obligations, see the MailKaka Privacy Policy.