Magento — now Adobe Commerce on the enterprise side — is the most complex e-commerce platform in common use. Its flexibility is also its deliverability problem: there is no single "order email" setting. There is an order confirmation, an order-update, an invoice, a shipment, a shipment-update, a credit memo, a credit-memo-update, a new-account email, a password reset, a wishlist share, a "contact us" form notification, and more. Every one of these has its own template, sender identity and trigger path.
If any link in that chain points at a misconfigured SMTP, the silence is invisible. Customers do not tell you they did not get the shipment email. They just file chargebacks.
Use a single authenticated SMTP relay (Amazon SES, Postmark, SendGrid) through one of the community SMTP modules, set every store's trans_email/ident_* From addresses to your authenticated domain, and run a seed test per event type, not just on order confirmation.
Sales email events in Magento
Out of the box Magento 2 and Adobe Commerce 2.4.x ship these transactional events under Stores → Configuration → Sales → Sales Emails:
- Order — fired on checkout success. Almost always the only one merchants test.
- Order comments — fired when admin adds a comment and ticks "notify customer".
- Invoice / Invoice comments — invoice created (often simultaneously with order in auth-and-capture flows).
- Shipment / Shipment comments — tracking number attached. This is the email customers actually look for.
- Credit memo / Credit memo comments — refunds and partial refunds.
Each can be enabled or disabled separately, and each can use a different "sender" identity — General, Sales, Customer Support, Custom Email 1/2. That flexibility is the root cause of the typical breakage: an admin changes the Sales identity for a new campaign and forgets that Shipment emails were using the same identity.
SMTP modules: Mageplaza vs Mirasvit vs native
Magento 2.4.6+ ships a native SMTP configuration, but most real stores still run a community module because the native one lacks per-store routing and log capture. The two serious options:
Mageplaza SMTP
- Free and paid tiers, the free tier is enough for most stores.
- Per-store-view SMTP host, port, auth.
- Email log with HTML preview — critical for debugging.
- Retry policy is limited — if SES returns a transient error the module does not re-queue aggressively.
Mirasvit Email Tracking / SMTP
- Paid only, but enterprise-grade.
- Open and click tracking baked in.
- Queue + retry with exponential backoff.
- Integrates cleanly with the Adobe Commerce event system, so third-party events (e.g. custom loyalty modules) also flow through the same SMTP.
Native 2.4.6+ SMTP
Usable if the store runs on a single store view and you are happy to lose HTML log inspection. Configured under Stores → Configuration → Advanced → System → Mail Sending Settings.
Magento's default transport is mail(), which goes through the server's sendmail / Postfix. On shared hosting the originating IP is usually on several blocklists already, and there is no DKIM signing. Every serious store uses an authenticated relay.
DNS for Magento stores
DNS looks like any other authenticated sender, with one extra wrinkle: multi-store installations often use multiple sender domains. Each must be authenticated independently.
- Pick a relay (SES is cheapest at volume, Postmark has the best reputation for pure transactional streams).
- Add the relay's DKIM CNAMEs for every sender domain. If store A sends from
shopa.comand store B fromshopb.com, both domains need DKIM. - Update SPF to include the relay. Watch the 10-lookup ceiling.
- Publish DMARC at
_dmarc.yourstore.com. Start atp=none. - In Magento, set
trans_email/ident_sales/email,ident_support/emailand all the rest to an address on the authenticated domain. Mismatches between the From header and the DKIM d= domain cause DMARC failure.
Multi-store gotchas
Adobe Commerce stores almost always grow into multi-website, multi-store-view installations. Each scope has its own set of trans_email/ident_* values, and Magento silently inherits from the default scope if the store scope is empty.
The common failure: admin sets up DKIM for shopa.com, switches scope to Store B, leaves the sender email blank, and now Store B emails go out with sales@shopa.com as From but DKIM signed with shopb.com (because the relay signs with the login domain). DMARC fails silently. Gmail moves it to Spam. Nobody notices.
# Magento CLI audit: show every sender across every scope
bin/magento config:show --scope=websites --scope-code=base \
trans_email/ident_sales/email
bin/magento config:show --scope=websites --scope-code=base \
trans_email/ident_support/email
# Repeat for each ident_* path and each scopeSeed test per event type
The single biggest mistake Magento merchants make is testing only the order confirmation. Place a real test order, then:
- Create the invoice from admin — seed the invoice email.
- Create the shipment with a fake tracking number — seed the shipment email.
- Refund partially — seed the credit memo.
- Add an order comment with "notify" — seed the order comment email.
Four to five placements per event type across Gmail, Outlook, Yahoo and your customer-heavy mailbox providers. If shipment emails are landing in Spam but order confirmations are in Inbox, you have a template problem, not a DNS problem.
A native Magento app is in private beta — schedule placement tests from your admin and alert on drops.