Magento email deliverability troubleshooting

Transactional email from a Magento or OpenMage store can arrive in spam, be rejected by the receiving provider or disappear before it reaches the customer. That can affect order confirmations, password resets, shipment updates and support replies at the moments when customers most need them.

The visible symptom does not identify the cause. A delivery problem may come from the store, its mail transport, DNS authentication, the sending service, domain or IP reputation, recipient policy, or a combination of these factors.

Common causes

• The store is not handing messages to its configured SMTP or API transport.
• A queue or cron process is delayed, stopped or repeatedly failing.
• The sending service rejects the request because credentials, sender identity, quota or region settings are wrong.
• The envelope sender, visible From domain and actual sending service do not align as expected.
• The domain has missing, duplicated or incorrect SPF, DKIM or DMARC records.
• The sending IP has no suitable reverse DNS (PTR), or the forward and reverse identity is inconsistent.
• The domain, IP or message stream has poor reputation because of complaints, unexpected volume or abuse.
• Unprotected Magento contact or registration forms are being used to generate unwanted mail. See Protect Magento Contact & Registration forms from SPAM for historical context.

Correct DNS authentication reduces avoidable failures, but it cannot guarantee inbox placement. Message content, recipient filtering, complaint history, volume patterns and sender reputation also influence delivery.

Evidence to collect first

Start with one recent affected message or rejection. Record:

• the domain used in the visible From address;
• the envelope sender or Return-Path domain;
• the sending service and, when known, its sending IP address;
• the receiving provider, such as Google Workspace or Microsoft 365;
• the complete SMTP rejection or bounce text;
• the message headers from a delivered or spam-folder copy; and
• whether the failure affects every transactional message or only one Magento template, store view or recipient provider.

Remove message bodies, personal content and unrelated recipient data before sharing headers or logs. Do not send passwords, API keys, DNS credentials or customer records through a public form.

Check the Magento delivery path

Before changing DNS, confirm that Magento created the message and handed it to the expected transport. Review the application and mail logs, cron or queue status, SMTP extension or API configuration, sender identities for each store view, and any provider quota or rejection events.

A successful application-level “sent” status may only mean that the next mail server accepted the message. It does not prove delivery to the recipient. Use the provider event log, SMTP response and received-message headers to follow the message beyond Magento.

Check the mail domain and sending infrastructure

A useful review normally covers:

1. MX records. Confirm where inbound mail for the domain is expected to go. MX records do not authorize outbound senders, but they help identify the domain’s mail-provider configuration and routing conflicts.
2. SPF. Verify that the envelope-sender domain publishes one valid SPF policy and that every legitimate sending service is represented without exceeding SPF evaluation limits.
3. DKIM. Confirm that the actual message is signed, then check the public key at the selector and signing domain shown by its DKIM-Signature header. Looking up a guessed selector cannot establish whether DKIM is configured.
4. DMARC. Inspect the policy at _dmarc.example.com and verify alignment between the visible From domain and a domain that passes SPF or DKIM. A valid p=none policy monitors mail; stricter enforcement should be introduced only after legitimate senders are known and aligned.
5. PTR and sending identity. For directly operated mail servers, review the sending IP’s reverse DNS, forward DNS and SMTP hostname. A hosted mail provider normally manages these records for its own sending infrastructure.
6. Transport security. Check the SMTP TLS negotiation and certificate errors reported for the actual delivery route. TLS protects transport; it does not replace SPF, DKIM or DMARC.
7. Reputation and abuse signals. Review provider feedback, complaints, unexpected sending volume and relevant blocklist evidence. A blocklist result should be interpreted in context rather than treated as a complete diagnosis.

Make changes safely and verify them

Inventory every legitimate sender before replacing an SPF or DMARC record. Marketing platforms, support systems, store servers, payment systems and staff mail may all send using the same organizational domain. Removing one of them from a policy can fix one path while breaking another.

Record the previous DNS values and lower TTLs only when the change plan requires it. After applying the correction, allow for DNS propagation, send a new message through the affected Magento path and inspect the new provider event, SMTP response and authentication results. Reusing an old message does not verify the new configuration.

For a guided check of public MX, SPF, DKIM and DMARC records, message headers and common rejection scenarios, we recommend MailFixIt. It provides a free diagnostic check and explains which findings require action before any DNS record is changed.