Check out the transactional model: http://www.modularfilemaker.org/2013/04/transactions/
This way you can loop and open ALL the records you need before sending out the email. If one of the records can not be opened, you can back out of the transaction and nothing hapens.
Alternatively, you could keep the email notification data in a different table. That table would have a record for each record in the Persons table that gets emailed, with fields for when the email was sent and by whom. This way you can see a history of every time that person was emailed to, instead of just the last time (which is what you get with the "sent" field in the Persons table itself).
With that "history" table you also do not have to worry about the record in Persons being locked or not, you are not updating that record. And since you always create records in the history table there can not be record lock issues there either.
Or you can have a one to one relationship to another table with only the Person Key and the sent status field? Not ideal for tip top performance as you may be finding over a join but it is not the end of the world with cute use of go to related records.
If you are mega paranoid you can record the history in a second table and take the last value. So a person may have 3 records in the 'emailSent' table, with values of Unsent, Pending and Sent. If you have a creation timestamp field you can display the last over a sorted relationship. Other users struggle to lock records you just created
Thank you very much for your fast advice. I like the transactional model very much, but will stick to a solution that seems to be easier to implement for now. I created a One to One relationship to a new table as Damian suggested. As we don't filter hundreds of records things work still very fast. With this way of dealing with the problem people can click the "Send E-mail" button while other people are still working on the records, and the timestamp gets set correctly.
If it were up to me, I would do like wimdecorte suggests by keeping track of sent records in a related table that the other staff don't have access to so they can't lock records. Plus adding fields to a table by using another table and one-to-one relationships reduces the chances of record locks and increases performance since FileMaker pulls and stores whole records at a time and if you limit the number of fields in a table, this process goes faster.