ganeshp, you posted your question because your intuition tells you that there's a simpler way. Your intuition is right. You're entangling your business rules (when to send mail) with your data (the database table), and that's not a good idea.
All the database really needs to know for selection purposes is the timestamp of the forms submission. The query can figure out and apply the business logic algorithmically. I'll explain how in a moment, but first let me make it more complicated:
1) Do the emails have to be sent PRECISELY 24/48 hours later? If "within an hour" is OK, then you can cut back on those cron processes a lot.
2) What happens if the system clock drifts ahead by a minute or two, then gets reset to the proper time? With your approach, somebody gets duplicate emails.
3) What happens if the system goes down for ten minutes and gets rebooted? With your approach, somebody misses an email.
I would have my table include an automatic timestamp "tstamp" and an integer "mail_sent" default 0 to record the number of nag notes.
That has several benefits. It lets you deal with the potential duplicate mail problem implied by my point 2, and the potential no-mail problem implied by my point 3. Very importantly, it lets the database optimize the query, especially if you index mail_sent. Comparing integers is a lot faster than examining timestamps.
To send the first reminder
SELECT * FROM mytable WHERE mail_sent = 0 AND tstamp < DATE_SUB(NOW(), INTERVAL 1 DAY);
(untested code but I think I have it right)
... then update mail_sent for each corresponding record upon successful mail().
For the second reminder
SELECT * FROM mytable WHERE mail_sent = 1 AND tstamp < DATE_SUB(NOW(), INTERVAL 2 DAY);
And so forth.
This approach works even if the server goes down for an hour or two, or jumps ahead in time because the clock was corrected. And it does not have to be adjusted if you back your cron process off to firing once every hour, or every four hours, or even daily.