When Magento order confirmations, invoices, or password resets go missing or land in spam, the cause is almost always one of four things: a stuck or disabled cron, because Magento queues mail and sends it through cron; a broken or missing SMTP relay; sender-domain authentication problems with SPF, DKIM, or DMARC; or a template error that throws on render. The fix is to send through an authenticated SMTP service, configure SPF, DKIM, and DMARC in your DNS, keep cron healthy, and warm up a new sending domain gradually.
Transactional email is not marketing; it is part of the purchase. A shopper who does not get an order confirmation assumes the order failed, and a password reset that lands in spam locks a customer out. Deliverability problems quietly erode trust and generate support tickets, and they are almost always fixable with the right setup. This guide covers why Magento email fails and how to make it reliable.
Why Magento emails vanish or hit spam
There are two distinct failures, and they have different causes. The first is email that never arrives at all. The usual culprits are a cron that is not running, since Magento queues transactional email and relies on cron to send it, a misconfigured or missing SMTP relay, or a template with a syntax error that throws when Magento tries to render it. If order confirmations simply stop, check cron first, because a dead cron silently stops all queued mail.
The second failure is email that arrives but lands in spam. That is a reputation and authentication problem: missing or misaligned SPF, DKIM, and DMARC records, a poor sender reputation, a mismatch between the sending server and the from-domain, or spam-triggering content. The receiving mail server cannot verify the mail is genuinely from your domain, so it filters it. Both failures are common on stores that rely on default settings, and both are avoidable.
Stop using PHP mail: use an authenticated SMTP relay
The root of most deliverability trouble is sending through the server’s default PHP mail function. Mail sent that way is unauthenticated, often comes from an IP with no sending reputation, and is treated as suspicious by receiving servers. It is the single biggest reason Magento email lands in spam.
The fix is an authenticated SMTP relay: a dedicated email-sending service such as a transactional email provider, connected to Magento so all mail routes through it. The relay sends from reputable infrastructure, signs your mail, and gives you delivery reporting. You connect it either through a Magento SMTP extension or, on Magento 2.4.6 and later, through the native SMTP support that was added to simplify this without an extra module. Either way, routing transactional email through an authenticated relay rather than raw PHP mail is the foundational deliverability decision, and it is standard practice in any well-run Magento development setup.
The authentication trio: SPF, DKIM, and DMARC
These three DNS records are how receiving mail servers verify your email is legitimate. They are configured in your domain’s DNS, not inside Magento, which trips up teams who look for the settings in the admin.
| Record | What it does | Where it lives |
|---|---|---|
| SPF | Lists which servers are allowed to send mail for your domain | DNS TXT record |
| DKIM | Cryptographically signs your mail so it cannot be forged | DNS TXT record, key from your relay |
| DMARC | Tells receivers what to do if SPF or DKIM fails, and where to report | DNS TXT record |
SPF declares which servers may send on your behalf, so include your SMTP relay in it. DKIM adds a cryptographic signature using a key your relay provides, proving the mail was not tampered with. DMARC ties the two together, telling receiving servers how to handle mail that fails authentication and giving you reports on what is being sent in your name. Getting all three aligned, so the from-domain matches the authenticated domain, is what moves your mail from the spam folder to the inbox. A store with a relay but no DMARC alignment still struggles, so treat the three as a set.
Keep cron healthy, because email depends on it
Magento does not send transactional email the instant an event happens; it queues the message and lets cron send it. This is efficient, but it means email delivery is only as reliable as cron. If cron stops or falls behind, the email queue backs up and messages either arrive very late or not at all.
So the same cron discipline that keeps indexers healthy keeps email flowing. Confirm cron runs on a proper schedule and completes without errors, and monitor the email queue so a backup is caught quickly. When a store reports that emails stopped, a stalled cron is one of the first things to check, alongside the relay configuration. Email and background processing are more connected in Magento than most merchants realize.
Warming up a new sending domain
A brand-new sending domain or IP has no reputation, and receiving servers are cautious with unknown senders. If you suddenly send a high volume from a cold domain, much of it can be filtered. The answer is warmup: gradually increasing your sending volume over days or weeks so receiving servers build a positive reputation for your domain.
This matters most when you launch a new store, move to a new relay, or change your sending domain. Start with lower volume, keep engagement high by sending genuinely wanted transactional mail, and ramp up steadily. A good transactional relay provides warmup guidance and monitors your reputation. Skipping warmup on a fresh domain is a common reason a newly launched store sees poor deliverability in its first weeks, when it can least afford lost order confirmations.
Testing and monitoring deliverability
Do not assume email works; verify it. Place a test order as a customer and trigger a password reset, then confirm the emails actually arrive and land in the inbox, not spam. Use a deliverability testing tool to score your authentication setup and flag problems before customers hit them. And monitor ongoing delivery through your relay’s reporting, watching bounce rates and spam complaints, because a rising bounce rate or complaint rate is an early warning of a reputation problem you can fix before it tanks your inbox placement.
Keep transactional and marketing email apart
One structural decision protects your most important email: separate the sending of transactional mail from marketing mail. Transactional email, order confirmations, shipping notices, password resets, must reach the inbox every time. Marketing email, promotions and newsletters, naturally draws more spam complaints and unsubscribes, and those hurt sender reputation.
If both flow from the same domain and IP, a bad marketing send can damage the reputation that your order confirmations depend on, and suddenly customers stop receiving receipts because of a promotional campaign. The fix is to send transactional and marketing mail from separate subdomains, or separate relays, so their reputations are isolated. A promotional subdomain can take the occasional reputation hit without dragging down the transactional subdomain that carries your receipts. This separation is one of the highest-value deliverability decisions a growing store makes, and it is far easier to set up before a reputation problem than to untangle after one.
Common template and configuration mistakes
A few Magento-specific mistakes cause deliverability problems that look mysterious. The first is a template error: a broken variable or syntax issue in a transactional email template can throw when Magento renders it, so the email is never sent, with no obvious error on the storefront. After customizing any email template, send a real test to confirm it still renders and sends.
The second is a from-address that does not match your authenticated domain. If Magento sends as one address but your SPF and DKIM authenticate a different domain, receivers see a mismatch and filter the mail. Align the store’s sender addresses with the domain you authenticated. The third is leaving the general contact and sales sender emails at placeholder or example values after launch, which produces unprofessional mail and authentication mismatches. Audit every sender address the store uses, confirm each aligns with your authentication, and test each email type end to end before you rely on it.
Frequently asked questions
Why did my Magento order confirmation emails stop sending?
Most often a stuck or disabled cron, because Magento queues transactional email and sends it through cron. A dead cron silently stops all queued mail. Also check for a broken SMTP relay configuration or a template syntax error that throws on render. Start with cron, then the relay.
Why do my Magento emails go to spam?
Usually missing or misaligned SPF, DKIM, and DMARC records, or sending through unauthenticated PHP mail from an IP with no reputation. Receiving servers cannot verify the mail is genuinely from your domain, so they filter it. Send through an authenticated relay and align all three DNS records.
Where do I configure SPF, DKIM, and DMARC for Magento?
In your domain’s DNS settings, not inside Magento. They are TXT records: SPF lists allowed sending servers, DKIM adds a signature using a key from your relay, and DMARC sets the policy for failed authentication. Aligning all three so the from-domain matches is what fixes inbox placement.
Do I need an SMTP extension for Magento email?
You need an authenticated SMTP relay. You can connect one through a Magento SMTP extension, or on Magento 2.4.6 and later through the native SMTP support added to simplify setup without an extra module. Either way, route mail through a reputable relay rather than raw PHP mail.
What is email warmup and do I need it?
Warmup is gradually increasing sending volume from a new domain or IP so receiving servers build a positive reputation for it. You need it when launching a new store, changing relays, or changing your sending domain, because a cold domain sending high volume gets filtered. Ramp up steadily rather than starting at full volume.
Where this fits
Reliable Magento transactional email is four things working together: an authenticated SMTP relay instead of PHP mail, aligned SPF, DKIM, and DMARC records in DNS, healthy cron to send the queue, and warmup for a new sending domain. Get those right, test them with real orders, and monitor the reporting, and your order confirmations reach the inbox instead of the spam folder, where they belong.
Bemeir is the first US-based Hyva partner and a full Adobe Commerce agency, with a deep technology partner ecosystem across email, deliverability, and infrastructure tools. We configure reliable transactional email on Hyva and Magento builds, and we also work across Shopify, Shopware, and BigCommerce. Read more about Bemeir and how we keep Magento communications dependable.
External references: a guide to sending reliable Magento emails with SMTP and authentication, a walkthrough for configuring the Magento 2 email server, and a reference on Magento 2 email settings.
