Elementor Email Deliverability supports custom sending domains and provides the DNS records used by its routing service. Elementor instructs users to create the supplied CNAME records and keep proxy-capable records in DNS-only mode. A safe cutover also checks actual message headers, alignment, sender identity, reply routing, and recipient delivery.
Use this for Elementor sites moving transactional mail from the default service address to a branded sending domain, including forms, account email, and WooCommerce notifications.
Quick answer
Record the current mail path and TTLs, copy Elementor's exact CNAME host and target values, keep them DNS only, verify from multiple resolvers, and wait for Elementor validation. Then send a controlled matrix and inspect Authentication-Results, DKIM, SPF, DMARC alignment, From, Return-Path, Reply-To, links, logs, and inbox placement before declaring the cutover complete.
What to check first
- Inventory the current sender, From and Reply-To addresses, provider, SPF and DMARC records, message sources, recipient domains, and rollback method.
- Add only the DNS records Elementor provides, preserve existing mail records, use DNS-only mode where proxying exists, and lower TTL before the change when policy allows.
- Confirm authoritative and public DNS responses from more than one resolver, then complete Elementor domain verification without repeatedly replacing pending records.
- Send form, password-reset, order, and test messages to Gmail, Microsoft, Yahoo, and an organizational inbox while capturing headers and Elementor logs.
- Verify authentication and alignment, recipient display, replies, links, unsubscribe headers where relevant, suppression behavior, and rollback to the prior sender path.
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 |
| Baseline the current mail path | Inventory the current sender, From and Reply-To addresses, provider, SPF and DMARC records, message sources, recipient domains, and rollback method. | All required CNAME records resolve publicly to the expected targets. |
| Publish exact DNS-only records | Add only the DNS records Elementor provides, preserve existing mail records, use DNS-only mode where proxying exists, and lower TTL before the change when policy allows. | DKIM, SPF, and DMARC results match the intended visible sender domain. |
| Verify public DNS and Elementor | Confirm authoritative and public DNS responses from more than one resolver, then complete Elementor domain verification without repeatedly replacing pending records. | From, Reply-To, Return-Path, links, and source-specific messages are correct. |
| Inspect a recipient matrix | Send form, password-reset, order, and test messages to Gmail, Microsoft, Yahoo, and an organizational inbox while capturing headers and Elementor logs. | The recipient matrix and rollback test are stored with timestamps and owners. |
Why this usually happens
- A CNAME can exist in one resolver cache while other recipients still see the old answer.
- Proxying a verification record can hide the target expected by the mail service.
- SPF pass alone does not prove DKIM or DMARC alignment for the visible From domain.
- Changing the sending domain can expose stale Reply-To, form-recipient, or allowlist assumptions.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
dig +short CNAME em1.example.com
dig +short TXT _dmarc.example.com
dig +trace CNAME em1.example.com
# In received headers, record:
Authentication-Results: dkim=pass; spf=pass; dmarc=pass
From: forms@example.com
Reply-To: support@example.com
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.
- Baseline the current mail path
- Publish exact DNS-only records
- Verify public DNS and Elementor
- Inspect a recipient matrix
- Approve or roll back
Decision rule
Approve cutover only when Elementor verification and real recipient headers agree. If authentication, alignment, recipient identity, or critical delivery fails, return to the recorded prior path and correct one variable at a time.
What to tell the client or owner
Share the previous sender path, DNS records and TTLs, authoritative and public lookup results, Elementor verification time, message matrix, redacted headers, authentication results, inbox outcomes, reply tests, rollback result, and approver.
Production verification checklist
- All required CNAME records resolve publicly to the expected targets.
- DKIM, SPF, and DMARC results match the intended visible sender domain.
- From, Reply-To, Return-Path, links, and source-specific messages are correct.
- The recipient matrix and rollback test are stored with timestamps and owners.
Mistakes to avoid
- Do not proxy mail verification CNAMEs when Elementor requires DNS-only records.
- Do not overwrite unrelated MX, SPF, or service records.
- Do not approve from the Elementor green check alone.
- Do not test only one message type or one recipient provider.
Questions teams ask during testing
How long can Elementor custom-domain verification take?
Elementor's guide says the process can take up to 72 hours. Resolver TTLs and provider caches can produce different answers during that window.
Do I need to add separate manual DKIM or SPF records?
Use the exact records Elementor provides and verify the resulting headers. Elementor says its setup handles the required authentication through the supplied records, so avoid adding speculative duplicates.
When HandL WP should help
HandL WP can stage the DNS cutover, protect existing records, inspect authentication headers, test every transactional source, and keep form and order email working during the move.
If this is active on a production site, configure Elementor custom-domain email safely.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references