So if your jobs weren’t set up, it makes sense that your emails weren’t being sent. As far as I know, test emails don’t go through jobs. Let’s see if that helps with your issue. Otherwise, since you’re using SMTP, my idea falls flat.
If you like the solution but are looking for a managed and more robust version (support, more modern builder, etc.), feel free to send me a PM
Since you’re connected to your SMTP, the email is likely stuck on that end. You should check whether the SMTP server received the command from Mautic. Beyond that, it’s hard to dig deeper without more information.
I understand,
Anyway, your lead is good.
In my SMTP delivery tracking, I have some emails marked as “unknown” for the recipient. Since my database isn’t large, I checked and confirmed that I have all the email addresses of my contacts.
I think the job configuration is correct. The issue really lies with the SMTP setup (we don’t use SMTP for ourselves or our clients, but rather the Mailjet transport with our dedicated IP pool through them).
To test the cronjob, simply run the crontask in a terminal.
For example: $ php ~/public_html/bin/console mautic:broadcast:send --batch=5 --limit=500
Important to note:
In the *nix world, when you see a $ at the beginning of a command, it means you should run it as a regular user, not as “root” (otherwise the line would start with a #). Crucially, do not include the $ or # in the command itself (they are already generated by your terminal). So, if the line in the terminal starts with a # and there is no “su” in the command, you will inevitably break the web application (Mautic).
Otherwise, if Mautic reports no errors, check the SMTP server*.
Things that can go wrong/get blocked:
Missing DMARC
Missing SPF
Missing DKIM
Each of these three concepts can indeed block delivery (not sending, but receiving). To find out, the simplest approach is to check the logs of the SMTP servers (sending server) and MX servers (receiving server).
Alternatively, you can run dig commands on the DNS zone to verify that the configuration is properly in place.
Another possible issue could be the SMTP server’s firewall and/or the Internet Service Provider blocking outbound port 25. For example, if you’re using CSF (ConfigServerFirewall) and the SMTP_BLOCK feature is enabled, only the mailer (mailman/exim) or root can send emails without authentication.
DMARC and DKIM are fine. However, I wasn’t able to configure a queue. Could that be the issue?
It seems to me that it’s due to sending too many emails simultaneously.
Sorry for the delay—I didn’t receive the notification about your follow-up.
Queuing is not required in the vast majority of cases. And an excessively high number of sends would simply result in an excessive number of processes (your server would crash).
What about SPF? (DMARC and DKIM are both secondary. SPF is the primary factor that leads to rejection upon receipt.)
At this point, you’ll need to continue your investigation at the SMTP server level. I say this because, according to Mautic, the sends to the relay were completed. And nothing seems to suggest otherwise.
It seems normal that Mautic indicates the emails have been delivered… In fact, your configuration is relatively simple (simplified here):
Mautic ==> MTA (Postfix/Kumo/other) ==> Recipient
What Mautic appears to be telling you is that the MTA on your server, which received the email, has accepted the message…
The simplest approach would be to start by checking your MTA logs. This will allow you to determine exactly what is blocking the process and whether the email was successfully presented!