As I suspected from your question in post #12, that design is not completely normalized. By placing an arbitrary number of dates in the Remarks text box (any amount from no dates at all to more than two) you have in effect created a repeating group.
If that remarks field remains as a text string then you have the issue that you CAN'T do what you want when the second date gets added without splitting the field, parsing the new entry, and re-merging the field. You CANNOT validate a multi-date string-oriented field without a thorough knowledge of text parsing.
The simplest way with what you built would be to enter the date as a STRING separately and parse it for validation, after which you could concatenate multiple strings. Otherwise you would have the problem that with an arbitrary text string in that field, your user could in theory place the cursor ANYWHERE in the string and add stuff that violates the date formatting of prior entries.
Using a text field as a list of dates (to be validated) in Access is a perpetual nightmare of text parsing. You need to enter those dates in a separate child table that is one-to-many with the records you show in the form.
That is not all... those dates in that format, particularly once it becomes multiple dates in the same box, CANNOT be directly linked to anything else in the DB and, given date sorting issues, will not be easily testable for ordering.
Your form and this design show common Excel-style thinking. This is not a desirable design for Access databases because Access is not Excel. Further, as difficult as this would be in Access, the "validation" part in Excel would be at least as bad if not worse.
How do I incorporate multiple dates as shown in the attached DB?
The dates have to go in a child table, one date per row, because in that format, you can validate dates in fairly specific ways yet still have a list.