The DPDP Act makes your organisation the Data Fiduciary for every subscriber email address you hold. Consent, notice, retention and the location of that data all become your responsibility. neuMails keeps subscriber data on Indian infrastructure — or deploys inside your own data centre when it can't leave your network at all.
There is a lot of loose commentary about DPDP deadlines, much of it either alarmist or complacent. The accurate position is a phased one.
The Digital Personal Data Protection Act 2023 received assent in August 2023, and the Digital Personal Data Protection Rules were notified in November 2025, starting a staged rollout:
Through the transition period the expectation is guidance and warnings rather than penalty action. That is not a reason to defer: consent flows, vendor contracts, notice wording and retention policies take months to fix, and the areas under scrutiny — particularly legacy data collected before the framework — are precisely the ones that need lead time.
The Schedule to the Act sets penalty ceilings rather than fixed fines. The highest is up to ₹250 crore for failure to take reasonable security safeguards resulting in a breach, and up to ₹200 crore for failures relating to breach notification or Significant Data Fiduciary obligations.
An email address is personal data. That single fact places every list you hold inside the framework, and it changes four things about how email programmes are run.
Consent must be demonstrable. The Act requires consent that is free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and as easy to withdraw as it was to give. In email terms that rules out pre-ticked subscribe boxes, consent bundled into terms acceptance, and one blanket agreement covering unrelated purposes. It also means storing, per subscriber, when they consented, through which form, and what they were told they were signing up for.
Notice has to be meaningful. At the point of collection you must tell the person what data you are collecting, for what purpose, how to exercise their rights and how to complain. A privacy policy link at the foot of a form is weak evidence that notice was given.
Data principal rights become operational requests. Access, correction and erasure are not abstract. Someone can ask what you hold about them, and you need to answer — which means being able to find every record of one address across lists, segments, campaign history, suppression records and logs.
Retention needs a defined end. Personal data should be erased when the specified purpose is no longer served. An email list kept indefinitely because storage is cheap is the opposite of purpose limitation — and, separately, a list of people who stopped engaging four years ago is actively damaging your deliverability.
Worth noting: the compliance case and the deliverability case point in the same direction. Explicit consent, engaged recipients and a list you prune are what mailbox providers reward too. See the Gmail and Yahoo sender requirements for the technical side of the same discipline.
India does not operate a whitelist of approved destinations. Section 16 uses a negative-list model: transfers are permitted to any country the Central Government has not restricted.
So under DPDP alone, storing subscriber data on a US or EU platform is lawful today. The exposure is structural rather than immediate, and it takes three forms.
The list can change. A restriction notified with limited notice would leave you migrating a live email programme under time pressure — lists, templates, automations, sending domains and IP reputation, all at once.
Significant Data Fiduciaries face additional duties. Organisations designated as SDFs carry obligations beyond the baseline.
Evidence is harder at a distance. You remain accountable for what your processor does. Producing data-flow documentation, confirming sub-processors, or evidencing that one person's data was actually erased is considerably simpler when the infrastructure is in India and the vendor relationship is domestic.
And for regulated sectors, DPDP is not the binding constraint at all — sectoral rules are stricter and already in force.
This is the part most email vendors skip, and it is the part that decides procurement in BFSI.
DPDP sets a national baseline. Sectoral regulators set their own requirements independently, and several are considerably stricter and have been in force for years. For a regulated entity, satisfying DPDP does not discharge those obligations.
The Reserve Bank of India's directive on Storage of Payment System Data, issued in April 2018 with compliance required from October that year, requires payment system providers authorised under the Payment and Settlement Systems Act to store the entire data relating to payment systems they operate only in India.
The point that matters for an email platform is what "payment system data" covers. Per RBI's clarifications, the scope includes end-to-end transaction details and information collected, carried or processed as part of a payment message or instruction — explicitly including customer name, mobile number, email address, Aadhaar and PAN, beneficiary details, and payment credentials such as OTPs and PINs.
Read that against a typical email stack. If a regulated entity sends a transaction OTP or a payment confirmation by email, then the OTP, the recipient's email address and the transaction details in the message body are all within scope — and they are sitting in the sending platform's queue, database and delivery logs.
Where processing occurs abroad, RBI's clarifications require the data to be deleted from overseas systems and brought back to India within one business day or 24 hours, whichever is earlier. For a foreign leg of a cross-border transaction, storage abroad is permitted. Sharing payment system data with overseas regulators requires RBI's prior approval.
The practical consequence: an overseas email platform processing OTPs for an RBI-regulated entity is a question the entity's compliance team has to answer, and "our vendor has a region setting" is a weaker answer than "the infrastructure is in India."
IRDAI's Maintenance of Insurance Records regulations carry their own requirement that records be held within India. Payment aggregators and payment gateways operate under further RBI guidelines with technology and data conditions of their own. Other sectors carry comparable expectations through their respective regulators.
The pattern is consistent: sectoral rules predate DPDP, apply independently of it, and in regulated industries are usually the binding constraint on where your email data can sit.
Whether any of these directives applies to your organisation depends on your authorisation status and the nature of your processing. This is a description of the regulatory landscape, not advice on your position — confirm the specifics with your compliance team or regulatory counsel.
Locations reflect each provider's primary published processing regions and may change. Verify current arrangements directly with any vendor as part of your own due diligence.
"Data stays in India" and "data stays inside our network" are different requirements, and it's worth knowing which one you actually have.
India-hosted cloud covers most organisations. Subscriber lists, campaign content and delivery logs are processed and stored on AWS Mumbai (ap-south-1). Nothing crosses a border, the vendor relationship is domestic, GST invoicing applies, and data-flow documentation is available for your audits.
On-premise deployment is for organisations whose policy or regulator requires that personal data not leave infrastructure they control. The complete platform — campaigns, SMTP relay, API, analytics and logs — is deployed inside your own data centre. The database holding subscriber records sits on your storage, administered by your team.
If your compliance requirement is phrased as "must remain within our environment" rather than "must remain in India," a dedicated IP on a SaaS platform does not satisfy it, however it is marketed. Full detail on the on-premise email platform page.
In which country is subscriber data stored, processed and backed up? Backups are the part vendors most often omit.
Can Indian residency be written into the contract, or is it a configuration setting they can change?
Which sub-processors are involved and where do they operate? Your accountability extends down that chain.
If a data principal requests deletion, can they remove that individual everywhere and confirm it?
Is there data-flow documentation you can hand to an auditor, or only a marketing claim?
Note: this page is general information about how the DPDP framework and sectoral data rules intersect with email marketing operations. It is not legal advice, and neuMails is not a law firm. Your obligations depend on your sector, scale, authorisation status and processing activities — take qualified legal counsel on your specific position.
Migration support for lists, templates and automations — from Mailchimp, Brevo, SendGrid or anywhere else.
Talk to Our TeamYes. An email address is personal data, so any organisation processing subscriber addresses of people in India is a Data Fiduciary. The Act also covers processing carried out outside India where it targets people in India, so using an overseas platform does not remove the obligation.
The Rules were notified in November 2025 with a phased timeline. Data Protection Board provisions took effect immediately, consent manager provisions take effect on 13 November 2026, and substantive compliance obligations take effect on 13 May 2027. Guidance and warnings are expected through the transition, with full enforceability from May 2027.
The Schedule sets upper limits: up to ₹250 crore for failure to take reasonable security safeguards resulting in a breach, and up to ₹200 crore for breach-notification or Significant Data Fiduciary failures. These are ceilings, not fixed fines — the Board determines amounts against factors set out in the Act.
Under DPDP, currently yes — India uses a negative-list model under Section 16 rather than a whitelist. But sectoral rules can be stricter. RBI-regulated payment system providers face separate localisation requirements that apply regardless of the DPDP position.
It can. RBI's Storage of Payment System Data directive requires payment system providers to store payment system data only in India, and the covered data includes customer name, mobile number, email address, and payment credentials such as OTPs and PINs. Where a regulated entity sends OTPs or transaction messages by email, the platform handling them holds data within that scope. Whether the directive applies to your organisation depends on your authorisation status under the Payment and Settlement Systems Act — take regulatory advice on your specific position.
Free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and as easy to withdraw as to give. That rules out pre-ticked boxes, consent bundled with terms acceptance, and one agreement covering unrelated purposes. You also need a record of when and how each subscriber consented.
A purchased list has no valid consent record and cannot be relied on. For older lists, re-permission with a confirmation campaign and delete non-responders. Legacy data without demonstrable lawful basis is a known area of regulatory focus — and mailing it is also the fastest way to damage your sender reputation.
On AWS Mumbai (ap-south-1). Subscriber lists, campaign content and delivery logs remain on Indian servers. Where data must stay inside your own network boundary, the platform can be deployed on-premise in your data centre.
No. It addresses data location and vendor questions, but you remain the Data Fiduciary. You still need valid consent and records to prove it, clear notice, a rights-request mechanism, defined retention, reasonable security safeguards and a Grievance Officer. A compliant platform makes compliance easier to evidence; it does not confer it.