Elementor Site Mailer documents a Not sent status that generally occurs when the account has surpassed its email quota. Forms, password resets, account notices, and order messages can continue creating WordPress events even while the mail layer does not send them, so restoring capacity is only the first incident step.
Use this for site owners and support teams when Elementor Email Deliverability shows Not sent messages, a quota warning, or a sudden gap between WordPress workflows and recipient inboxes.
Quick answer
Confirm plan and quota state, find the first Not sent timestamp, list every affected message source and business event, restore sending capacity, and test one new message. Then reconcile missed mail against form entries, orders, users, and provider logs. Resend only messages that are still useful and have a stable deduplication record.
What to check first
- Capture the plan, quota, current usage, first Not sent timestamp, last delivered timestamp, account state, and any recent subscription or ownership change.
- Export or record Not sent rows by source, recipient, subject, event ID, order or entry ID, timestamp, sensitivity, and whether the underlying workflow completed.
- Restore capacity through the approved plan or account path, refresh the status, and send a harmless test message before replaying customer mail.
- Classify password resets, confirmations, order emails, failed-payment notices, administrator alerts, and form messages by whether resend is still safe and useful.
- Replay in controlled batches with one deduplication key, monitor delivered and failed status, and notify business owners about messages that should not be resent automatically.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Confirm quota and incident window | Capture the plan, quota, current usage, first Not sent timestamp, last delivered timestamp, account state, and any recent subscription or ownership change. | A new test message reaches the intended inbox after capacity restoration. |
| Inventory affected workflows | Export or record Not sent rows by source, recipient, subject, event ID, order or entry ID, timestamp, sensitivity, and whether the underlying workflow completed. | Every Not sent row maps to a business event and resend decision. |
| Restore and test capacity | Restore capacity through the approved plan or account path, refresh the status, and send a harmless test message before replaying customer mail. | Replayed messages use a stable key and do not duplicate fulfilled actions. |
| Classify safe resends | Classify password resets, confirmations, order emails, failed-payment notices, administrator alerts, and form messages by whether resend is still safe and useful. | Quota alerts, ownership, thresholds, and the next response owner are documented. |
Why this usually happens
- Quota alerts may be missed or routed to an account owner who is not the site operator.
- WordPress can record a successful business event even when the external mail service declines the send.
- Blind resends can duplicate order, security, and confirmation messages after another channel already handled the case.
- The email log status can refresh on a delay, which complicates the boundary between pending and not sent.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
incident_start: 2026-07-22T08:14:00Z
last_delivered: 2026-07-22T08:13:42Z
not_sent_count: 42
sources: [elementor_form, password_reset, woocommerce]
capacity_restored: true
test_message_id: test_redacted
replay_batch_size: 10
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Confirm quota and incident window
- Inventory affected workflows
- Restore and test capacity
- Classify safe resends
- Replay in batches and monitor
Decision rule
Resend only when the message still serves a valid user need and the event has not already been fulfilled. Generate a fresh password-reset or expiring token instead of replaying an old security message.
What to tell the client or owner
Share plan and quota evidence, incident timestamps, affected counts by source, business-event reconciliation, capacity restoration, test message, replay criteria, batch results, unresolved rows, and alerting changes.
Production verification checklist
- A new test message reaches the intended inbox after capacity restoration.
- Every Not sent row maps to a business event and resend decision.
- Replayed messages use a stable key and do not duplicate fulfilled actions.
- Quota alerts, ownership, thresholds, and the next response owner are documented.
Mistakes to avoid
- Do not treat Not sent as a recipient-level bounce.
- Do not resend all rows with one bulk click before classifying message type.
- Do not replay stale reset links or time-sensitive instructions.
- Do not close the incident after upgrading the plan without reconciling missed messages.
Questions teams ask during testing
What is the difference between Failed and Not sent?
Elementor describes Failed as a delivery attempt that did not succeed, while Not sent generally means the service did not send the message, often because quota was exhausted.
Should form confirmations be resent automatically?
Only after confirming the form entry is legitimate, the recipient is correct, the message is still useful, and no duplicate confirmation or follow-up has already been sent.
When HandL WP should help
HandL WP can restore Elementor mail service, reconcile missed forms and order messages, design a safe replay, correct recipient or suppression problems, and add quota monitoring.
If this is active on a production site, recover missing Elementor transactional email.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references