Magento Order Emails Not Sending or in Spam: The Complete Fix

Magento order emails going to spam or not sending: the four real causes

Magento order emails fail for one of four reasons: cron is not running, so queued mail never dispatches; the store is sending through Magento's unauthenticated default transport (sendmail, auth set to none), which carries no authentication and no sending reputation you control; SPF, DKIM and DMARC records are missing from the sending domain; or the sender address does not match the domain those records cover. Work through those four in that order and almost every "emails not sending" or "emails going to spam" case is fixed.

Few Magento problems cost sales as quietly as broken email. Orders complete, but the confirmation never arrives — or arrives in the junk folder — and the first you hear of it is a "did my order go through?" phone call. Password resets fail silently, quote replies vanish, and every missing message chips away at trust in your store. The good news is that the causes are a short, well-understood list, and every one of them is fixable without touching a line of code.

First, work out which problem you have

The symptom tells you where to start. Before changing anything, place a test order with an address you control and check both the inbox and the spam folder.

Symptom	Most likely cause	Where to look first
No emails arrive at all — inbox or spam	Cron is not running, so queued mail never dispatches	Run bin/magento cron:run; check the cron_schedule table
Emails arrive but land in junk	Unauthenticated sending via the default local transport, or missing SPF/DKIM/DMARC	Gmail's "Show original" — read the SPF, DKIM and DMARC results
Some recipients get mail, others never do	Individual providers rejecting unauthenticated mail outright	Your mail log, if you have one; bounce messages if you do not
Mail worked, then stopped after a host or domain change	Sender address no longer matches the authenticated domain	Stores → Configuration → General → Store Email Addresses

Cause 1: emails are queued but cron is not running

Magento can send sales emails asynchronously: the message is queued at checkout and a cron job dispatches it shortly afterwards. The setting lives at Stores → Configuration → Sales → Sales Emails → Asynchronous sending, and it is the sensible choice on a busy store because it keeps checkout fast — but it means no cron, no email. Nothing errors; the queue simply grows in silence.

Check that cron is actually installed and running. On the server, crontab -l should show Magento's cron entries; bin/magento cron:run executes a pass manually; and the cron_schedule database table shows every job with its status and timestamps. A wall of pending rows that never turn to success is the giveaway. If you want that visibility in the admin rather than the database — every scheduled job, its status and its history — that is exactly what our Cron Manager module adds.

Cause 2: unauthenticated local sending — no authentication, no reputation

Out of the box, Magento hands mail to the local sendmail transport with authentication set to none (older guides say PHP mail(); the deliverability outcome is the same), which passes it to whatever mail transfer agent your web server happens to have. That server has no sending reputation you control, often no reverse DNS, and no authentication — so receiving servers treat it with suspicion. Even when everything "works", deliverability is poor and gets worse as volume grows. This is the single most common reason order emails go to spam.

Magento 2.4 does include a basic SMTP transport under Stores → Configuration → Advanced → System → Mail Sending Settings — host, port and credentials — but it stops there: no OAuth 2.0, no provider presets, no test button, and no log of what was sent. The full fix is to route all transactional mail through a real provider over authenticated SMTP, with a record of every send. Our SMTP for Magento 2 module does that: 19 provider presets, OAuth 2.0 (XOAUTH2) for Google Workspace and Microsoft 365, encrypted credentials, a test-email button, and a full log so "did it send?" has an answer you can look up. The trade-offs between the default path and a proper relay are covered in Magento SMTP vs PHP mail(): Why Your Emails Need a Relay.

Cause 3: missing SPF, DKIM and DMARC

Since 2024, Gmail and Yahoo enforce authentication for bulk senders — and treat unauthenticated mail harshly for everyone. Three DNS records tell the world your mail is legitimate:

• SPF — lists the servers allowed to send for your domain. One TXT record; your provider's documentation gives you the exact include.
• DKIM — cryptographically signs each message so receivers can verify it was not altered and genuinely came from you. Your provider generates the key; you publish it as DNS records.
• DMARC — tells receivers what to do when SPF or DKIM fail, and sends you reports on who is sending as your domain. Even a relaxed policy is better than none.

Publish all three; SPF alone is no longer enough. To verify them, send yourself a test order confirmation and open Gmail's "Show original" — it prints a plain PASS or FAIL for each of SPF, DKIM and DMARC at the top of the page. All three should pass before you consider the job done.

Cause 4: the sender address does not match your domain

Authentication only counts when the pieces line up. Sending "from" an address your domain's SPF and DKIM do not cover — a free mailbox, or a leftover address from an old host — fails authentication instantly, however correct the rest of the setup is.

Check Stores → Configuration → General → Store Email Addresses: the general contact, sales representative and customer support addresses should all use the domain your DNS records authenticate, and that same domain should match the account your SMTP provider is configured for. Sender domain, SMTP account and DNS records — all three must agree.

The checklist that fixes most stores

1. Confirm cron is installed and running — crontab -l, then bin/magento cron:run, then check cron_schedule for jobs stuck at pending.
2. Check Stores → Configuration → Sales → Sales Emails — if Asynchronous sending is enabled, queued mail depends entirely on cron.
3. Stop relying on the unauthenticated local transport — route all transactional mail through a reputable provider over authenticated SMTP.
4. Publish SPF, DKIM and DMARC for your sending domain, using the exact records your provider documents.
5. Align every address in Stores → Configuration → General → Store Email Addresses with that domain.
6. Flush configuration cache after changes — bin/magento cache:flush.
7. Place a test order and read the headers — Gmail's "Show original" shows the SPF, DKIM and DMARC results in plain text.
8. Keep an email log so future failures are visible, not silent.

Form and registration spam poisons your reputation too

The same searches that surface delivery problems often surface the opposite one — bots hammering customer registration and contact forms. That is not just an admin nuisance: when your store dutifully emails every fake signup, your own sending reputation takes the damage, and the spam folder becomes more likely for the emails that matter. Native Magento offers CAPTCHA on its built-in forms; if you need storefront forms with stronger, layered protection, our Custom Forms module includes spam defence designed for exactly this.

FAQ

Why are my Magento 2 order emails not sending at all?

Most commonly, cron is not running, so queued emails never dispatch — check bin/magento cron:run and the cron_schedule table first. The second most common cause is a broken or host-blocked server mail path. Fix cron first, then move to authenticated SMTP.

Why do my Magento order emails go to spam?

Unauthenticated sending from a web server with no reputation of its own, combined with missing SPF, DKIM and DMARC records. Authenticated SMTP through a reputable provider, plus correct DNS records, resolves the structural causes.

Does Magento 2.4 have built-in SMTP settings?

Partially. Stores → Configuration → Advanced → System → Mail Sending Settings covers a basic SMTP transport — host, port and credentials — but has no OAuth 2.0, no provider presets, no test-send button and no log, which is why most stores add a dedicated SMTP module.

How do I test whether the fix worked?

Place a real test order to a mailbox you control, then open the message headers — Gmail's "Show original" reports SPF, DKIM and DMARC as PASS or FAIL. All three passing, on a message that arrived in the inbox, is the finish line.

Does this apply to headless Magento stores?

Yes. Transactional email is generated server-side by Magento regardless of frontend, so the same causes and fixes apply to Luma and headless builds alike. It targets Magento Open Source 2.4.9 on PHP 8.4 and 8.5.

While you are tidying order communications, the order number itself is worth a look — confirmation emails lead with it, and a formatted number reads better than a raw increment ID; see Magento 2 Custom Order Number. Both modules mentioned here are available individually with a one-off licence, and are included in the AgenticEcom Suite.