An error message should tell someone what blocks submission and how to correct the field. « Invalid input » or a red border without words is insufficient, especially for people using a keyboard or screen reader.
Give an instruction tied to the field
Write « Enter an email address containing @ » instead of « Error 42 ». Place the message beside the field and associate it with that field in the interface. The W3C recommends clear notifications, combining overall feedback after submission with specific guidance near the relevant control.
Explain known rules beforehand
State required formats and information before entry: identifier length, date format or maximum file size. Do not reveal a known constraint only after several failed attempts. Examples should match what is really accepted and avoid asking for data unnecessary to the task.
Preserve answers and guide recovery
After server or validation errors, keep completed fields when possible. Show a summary of issues near the start and local instructions beside each affected field. Move focus to a logical point for correction, then let the person review changes before another submission.
Distinguish correction, outage and success
A mistyped field is not a service outage. If submission fails technically, say so without pretending the enquiry arrived, and offer another contact route when possible. Conversely, a successful submission needs an explicit confirmation and an explanation of what happens next.
Test realistic errors
Try a blank field, a plausible but rejected format, an oversized file and a lost connection. Test by keyboard, on a phone and with assistive technology when available. The contact form guide helps reduce the number of fields before you write their error messages.