Duplicate notifications do not necessarily mean the form was submitted twice. A single browser submission can trigger two mail actions, a retry can replay the same job, or two plugins can listen to the same event. Give the submission and notification stable IDs before disabling random hooks.
Count submissions separately from emails
Check stored entries/request IDs first. Two messages from one entry is a mail-action problem; two entries is a browser/server deduplication problem.
Inspect configured notification actions
Form builders can have multiple email actions or admin/user notifications pointing to the same recipient.
Check AJAX and browser retries
Double click, frontend timeout or JavaScript retry can replay the submission if the endpoint lacks an idempotency/dedup key.
Inspect queues and webhooks
Background jobs can be retried after a timeout even when the first delivery succeeded. Record job/event IDs and provider message IDs.
Look for duplicate hooks
Custom snippets, CRM connectors or SMTP plugins can attach a second notification to the same form event.
Implement deduplication at the right layer
Use submission/event identity with a bounded window. Do not suppress all repeated recipient+subject combinations because legitimate separate leads can look similar.
Use the end-to-end form trace and the privacy-safe diagnostic guide to keep correlation evidence without storing message content.
Build a duplicate-event ledger
For one duplicated notification, record submission ID, request count, stored-entry count, notification-action IDs, queue/job IDs and provider message IDs. Two provider IDs from one action suggest a transport retry; two action IDs suggest form configuration; two submission IDs point back to browser/server deduplication. The ledger directs the fix to the right layer.