Magento emails not sending? We get them delivered.

In most cases it’s one of four things: (1) the email sending cron group or message-queue consumers aren’t running, so async emails just queue up; (2) the mail transport is broken — PHP mail() blocked or an SMTP relay misconfigured; (3) a fatal in the email template stops the render; or (4) Sales Emails is switched off in config. We trace the path from sales_email config to the MTA and find the exact break point, usually within a few hours.

Fixed-price tiers at our canonical $25/hr rate:

• Quick Fix — $99 (~4h @ $25/hr): one well-defined email bug, 24–48h.
• Bug-Fix Sprint — $499 (~20h @ $25/hr): a batch of email bugs or one deep deliverability root-cause with regression tests.
• Emergency / Retainer — custom: 24/7 on-call, with a $2,499 stabilization sprint (~100h @ $25/hr) available.

You get the quote before any work starts — never billed silently.

When Asynchronous sending is enabled (Stores > Configuration > Sales > Sales Emails), Magento doesn’t send instantly — it queues messages and relies on the email sending cron group plus the consumers_runner / message-queue consumers to drain them. If cron isn’t running, or the sales.rule.* and email consumers aren’t alive, mail piles up forever. We restart the consumers, pin them with supervisor or systemd so they survive reboots, and verify cron is actually firing.

Those errors mean Magento can reach (or can’t reach) your SMTP relay but the login is being refused. Common causes: wrong port (use 587 with STARTTLS or 465 with SSL), an account password used where the provider requires an app password or API key (Gmail/Office 365), the host blocking outbound port 25/587, or a missing SMTP extension. We configure the SMTP module for your relay (SendGrid, Mailgun, Amazon SES, Postmark, Office 365), fix the TLS handshake, and send a test until we get a clean 250 OK.

Yes — landing in spam is almost always a missing or broken authentication record. We publish and verify SPF (authorise your sending host), DKIM (cryptographically sign the mail), and DMARC (tell receivers what to do with unaligned mail). We also check the sending IP/domain reputation and the From / Return-Path alignment. After the fix we run an inbox-placement test across Gmail, Outlook and Yahoo so you can see the difference.

This split usually means the issue is specific to one email type, not the transport. Likely causes: the order confirmation template is disabled or points at a deleted custom template, Sales Emails > Order is toggled off while invoice/shipment stay on, or the order template has a broken directive — an adjacent }}{{depend, a nested {{depend}}, or a {{var}} not in the whitelist — which makes that one template silently fail. We isolate the affected type, fix the template/config, and confirm a real order triggers all three emails.

Magento 2.4.x silently fails an email when a template has invalid directives: adjacent }}{{depend, a nested {{depend X}}...{{depend Y}}...{{/depend}}, or a {{var X}} that isn’t in the template’s @vars whitelist. The result is a blank email or the “we are sorry, an error has occurred” message. We pre-compute conditionals in PHP where needed, fix the directives, and re-test the render so the template produces correct, complete HTML.

Receivers reject mail when the From address, the envelope sender (Return-Path), and the authenticated sending domain don’t line up — or when you’re sending From a domain you’re not authorised to use. We set the General Contact / Sales Rep sender addresses to a domain you control, align the Return-Path with your relay, and make sure SPF authorises the actual sending host. Once the envelope matches the authenticated domain, the 550 rejections stop.

Whichever is safest for your setup. For email work we strongly prefer to reproduce and test on staging or with sandbox addresses so we never blast your real customers with test sends. If only live access is available, we test against catch-all/sandbox inboxes and disable customer-facing sends until the fix is confirmed. We never flip the live queue on until a clean test send and 250 OK are verified.

Yes — that’s the whole point of our process. Email and DNS changes are reversible and low-risk when done in the right order: we capture the current config first, test changes against sandbox addresses, publish DNS records with sensible TTLs, and only switch the live queue back on after a verified test send. Nothing about an email fix touches your catalog, checkout, or order data, so there’s no risk to live transactions.

Yes — this is common. An upgrade (or a security patch) can reset email transport config, change the queue/consumer setup, deprecate a template directive, or remove a custom SMTP module that wasn’t upgrade-safe. We compare the before/after config, restore or re-point the transport, re-validate the templates against the new version’s rules, and confirm the async queue and cron are wired correctly for the version you’re now on (2.4.4–2.4.9).

Yes. We don’t call it fixed until we’ve sent a successful test transactional email, watched a real order trigger its confirmation, drained any backlog in the queue, and verified a clean 250 OK at the relay plus SPF/DKIM/DMARC passing at the inbox. If the same bug comes back within the coverage window, we fix it at no extra charge. You also get a short written note on what broke and how to keep email healthy.