Use the right identities
A common failure is to place the visitor's Gmail, Outlook or company address in the message's From header. Your website is not authorised to send as that domain, so SPF, DKIM and DMARC can fail.
From: Website contact <forms@example.com>
Reply-To: Visitor <visitor@their-domain.example>Validate and safely encode all form fields before they are placed in message headers. Never allow line breaks from user input into an email header.
Authenticate the actual sending path
- Send through your normal mail provider or a deliberately configured transactional service.
- Enable DKIM signing for the visible From domain.
- Use an aligned custom Mail From where supported.
- Avoid unauthenticated local PHP mail or hosting-server mail unless that infrastructure is intentionally included and maintained.
Find the form in reports
Submit a controlled test, record the sending time and recipient, then inspect subsequent aggregate data for the website host or transactional provider. Confirm at least one authenticated identifier aligns with the form's visible From domain.
- Check password-reset, order, booking and monitoring notifications separately.
- Include staging and legacy websites in the inventory.
- Keep the human reply destination in Reply-To so normal replies still work.
Keep application security separate
DMARC authenticates domain identifiers; it does not make a web form safe. The public form still needs server-side validation, abuse controls, bounded inputs and safe HTML/plain-text email construction.