Most conversations about DPDPA email data erasure start with databases and files, not inboxes. Fields, tables, retention schedules, a clean little diagram showing personal data flowing in, being processed, and then deleted on schedule. It looks tidy on a slide. Then someone asks the question. What about tons of data stored in our emails?
Here is a scenario that comes up constantly with our clients, and honestly, with ourselves too. A recruiter’s inbox receives tens of thousands of job applications a year. Each one comes with a CV, which means a name, phone number, address, work history, sometimes a photo. Ninety-nine percent of these candidates are rejected within weeks. The purpose the data was collected for, evaluating them for a role, is served and closed. Under DPDPA, that data is now supposed to be erased.
Except it is sitting in an inbox, not a database. There is no API to call. No delete button that knows what “purpose served” means. Just thousands of emails, some still unread, some archived into folders three years deep.
If you have been putting off this question because it feels unsolvable, you are not alone. It is not unsolvable. It just needs a different toolkit than the one built for structured systems.
Stop treating the inbox as a filing cabinet
The instinct is to go mailbox by mailbox and manually clean up. Do not do this. It does not scale, it is not repeatable, and six months later the inbox looks exactly the same because new applications keep arriving the same unstructured way.
The real fix happens upstream. If CVs are landing directly in a recruiter’s personal inbox, that is the actual problem, not the eventual cleanup. Route applications through an ATS or an intake form instead. Set a mail rule that forwards anything landing in a personal inbox straight into the managed system and archives the original. Once that is in place, the volume of fresh personal data piling up in someone’s inbox stops growing. You are no longer bailing water while the tap is still running.
DPDPA Email Data Erasure: Let the platform do the work
If you are using email exchanges such as Microsoft or Google then the task becomes a bit easier. Both Microsoft 365 and Google Workspace let an admin apply retention and auto-purge rules at the folder or label level, across the whole organization, without touching a single mailbox by hand. You are not writing custom code or waiting on an API that does not exist. You are telling the mail platform: anything in the “Rejected Applications” label gets permanently deleted after twelve months, full stop.
This is the part that surprises people. The compliance mechanism is not clever engineering. It is a retention policy you set once, at the tenant level, that quietly does its job in the background.
Deal with the backlog separately from the new flow
A hundred thousand emails did not arrive yesterday, so they will not disappear with one rule either. This is where DPDPA email data erasure gets slow and unglamorous rather than technically hard. For the existing pile, use Discovery tools such as Atlas Privacy Manager, which can crawl through and identify emails containing CVs or personal information at the Exchange level, or general content search tools to bulk-search by keyword, folder, and date range, and purge in batches. Run it quarterly. Treat it as a standing HR task, not a one-time fire drill.
Now, the question everyone actually wants to ask
Here is where it gets personal, and where most compliance conversations go quiet. What if it is your own inbox? Not a recruiter’s, yours. A hundred thousand emails built up over a decade of running the business, and somewhere in the back of your mind is the thought that one day you might want to go back through them. Write a book. Trace how a deal actually unfolded. Remember what a client said in year two versus year six.
The honest answer is that not everything in your inbox is under the same obligation. DPDPA’s erasure duty is tied to personal data collected for a specific, closed purpose. A rejected candidate’s CV fits that cleanly. A decade of business correspondence, negotiation threads, and project history mostly does not. It is a business record, and the law gives you legitimate grounds to hold onto business records for exactly the reasons you would expect: legal claims, audit trails, ongoing relationships.
Where it stops being clean is the “future book or blog” reason. That is a personal motive, not a business one, and it does not give a company system license to indefinitely retain other people’s personal data just because you might find it useful someday. If that is genuinely why you want to keep things, the answer is not to bend the business justification to cover it. The answer is to separate the two.
Keep your working inbox as a live business system, governed by an actual retention policy, where data with no remaining legitimate purpose gets cleared on schedule. If there is material you want to preserve for personal reasons, take it out as a private, access-controlled personal archive, understood clearly as personal retention, not company processing. It is a more honest way of handling the tension than pretending every old email is still “business critical.”
One inbox, two different rules for DPDPA email data erasure
The last thing worth saying is that a founder’s inbox and a recruiter’s inbox are not the same animal, and treating them with one identical rule will fail one of them. A recruiter’s inbox is high volume, almost entirely third-party personal data, collected for one recurring and narrow purpose. Automated retention rules fit it well. A leadership inbox is a mix of strategy, relationships, and the occasional embedded personal detail. It needs a longer retention window and a human review pass, not a blanket auto-delete.
DPDPA was never going to be solved by one policy document. It gets solved the way most operational problems do, by matching the tool to the actual shape of the data. Structured systems get structured rules. Inboxes get platform-level retention and a clear line between what the business needs to keep and what one person wants to keep for themselves.
