Elementor documents that Site Mailer email status normally updates every 12 hours and provides a refresh icon for an immediate update. A support team can create duplicate sends or false incident escalations when it treats a stale Pending label as proof that no message was delivered.
Use this for Elementor Site Mailer support, form confirmations, WordPress transactional mail, WooCommerce messages, and client SLAs that require a delivery decision before the dashboard's normal refresh window.
Quick answer
Start a case clock at the send timestamp, preserve the Site Mailer row, and compare manual refresh, provider evidence, recipient inbox, spam placement, and source application logs. Resend only when the evidence shows the original was not accepted, or when a stable message key prevents duplicates.
What to check first
- Record subject, privacy-safe recipient, source, send time, current status, Site Mailer message identifier, quota state, plan state, and whether message content logging is enabled.
- Use the Site Mailer refresh control once and record the before and after status with timestamps.
- Check the recipient inbox, spam folder, mail gateway, provider event, bounce notice, and WordPress source log without repeatedly clicking resend.
- Classify Pending, Delivered, Failed, and Not sent according to the documented status meaning, including quota-related Not sent cases.
- Define the support response at 15 minutes, 1 hour, and 12 hours, with clear evidence required before resend or provider escalation.
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 |
|---|
| Start an evidence clock | Record subject, privacy-safe recipient, source, send time, current status, Site Mailer message identifier, quota state, plan state, and whether message content logging is enabled. | Site Mailer row, provider event, source application, and inbox are tied to the same message. |
| Refresh once | Use the Site Mailer refresh control once and record the before and after status with timestamps. | Support notes distinguish dashboard delay from delivery failure. |
| Compare provider and inbox | Check the recipient inbox, spam folder, mail gateway, provider event, bounce notice, and WordPress source log without repeatedly clicking resend. | Quota exhaustion, suppression, bounce, and recipient placement have separate actions. |
| Classify the status | Classify Pending, Delivered, Failed, and Not sent according to the documented status meaning, including quota-related Not sent cases. | No duplicate message is created by a premature resend. |
Why this usually happens
- Dashboard synchronization can lag the provider's actual message event.
- A recipient can receive a message before Site Mailer changes from Pending.
- Not sent can indicate quota exhaustion rather than a remote mailbox failure.
- Manual resend can create a duplicate while the original status is still catching up.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
case_id: ELM-MAIL-12H
sent_at: 2026-07-21T11:50:00Z
status_at_send: pending
manual_refresh_at: 2026-07-21T12:05:00Z
provider_event: accepted
inbox_result: delivered
resend_allowed: false
next_review_at: 2026-07-21T23:50:00Z
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.
- Start an evidence clock
- Refresh once
- Compare provider and inbox
- Classify the status
- Apply the support SLA
Decision rule
Do not resend solely because the dashboard is still Pending inside the documented refresh window. Use provider and inbox evidence, and assign a stable message key when a business-critical resend is approved.
What to tell the client or owner
Share the privacy-safe message details, send time, Site Mailer row, refresh time, quota state, provider event, recipient result, source log, resend decision, support milestones, and final status.
Production verification checklist
- Site Mailer row, provider event, source application, and inbox are tied to the same message.
- Support notes distinguish dashboard delay from delivery failure.
- Quota exhaustion, suppression, bounce, and recipient placement have separate actions.
- No duplicate message is created by a premature resend.
Mistakes to avoid
- Do not promise dashboard status will update immediately without using the refresh control.
- Do not expose stored email content in a support screenshot.
- Do not call Not sent a mailbox bounce without checking quota and suppression.
- Do not let every support agent use resend without an ownership rule.
Questions teams ask during testing
Does Delivered mean the recipient opened the email?
No. Delivered and Opened are separate fields. Delivery indicates the message reached its destination, while open tracking has its own limitations.
How long does Elementor keep Site Mailer logs?
Elementor's Site Mailer documentation says email logs are kept for 30 days. Export or preserve case evidence before that window closes when an investigation lasts longer.
When HandL WP should help
HandL WP can build a practical Elementor email support SLA that uses message evidence instead of repeated resends and stale dashboard assumptions.
If this is active on a production site, diagnose Elementor email status.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Not sent messages after quota exhaustion
When Elementor reports Not sent rather than Failed, follow the Elementor quota incident runbook to restore capacity, inventory missed business events, avoid duplicate resends, regenerate stale security links, and monitor recovery.
Helpful references