[ACCEPTED]-Swift Mailer Delivery Status-swiftmailer
There are at least three layers of checks 38 that SwiftMailer supports, that will report 37 several types of delivery failures.
1) Always 36 check the return code from SwiftMailer's 35 send() or batchSend() commands for a non-zero 34 result. From the documentation:
//Send the message
$numSent = $mailer->send($message);
printf("Sent %d messages\n", $numSent);
/* Note that often that only the boolean equivalent of the
return value is of concern (zero indicates FALSE)
if ($mailer->send($message))
{
echo "Sent\n";
}
else
{
echo "Failed\n";
}
2) Use the failures-by-reference feature to know if specific 33 address(es) were rejected or couldn't complete:
//Pass a variable name to the send() method
if (!$mailer->send($message, $failures))
{
echo "Failures:";
print_r($failures);
}
/*
Failures:
Array (
0 => receiver@bad-domain.org,
1 => other-receiver@bad-domain.org
)
*/
3) In 32 a few situations you might want to enable return receipts as well, which 31 confirm that an email reader displayed the 30 message. They often are disabled or ignored 29 by users or their email apps, but if you 28 get a receipt, it is highly confirmatory. Note 27 also that this might occur many days after 26 sending so it's not a real-time synchronous 25 test like the two above.
$message->setReadReceiptTo('your@address.tld');
However, since there 24 are so many variables and layers of systems 23 involved in SMTP delivery, it is not generally 22 possible to be absolutely sure messages 21 were delivered. The best you can do is 20 make sure you're using the first two checks 19 above. If you're using YOUR own server 18 for the SMTP service, then you ALSO need 17 to be watching your logs and queues as Marc 16 B mentioned.
One other example that emphasizes 15 the need to get familiar with whatever underlying 14 email system you're using. I've just started 13 using the Swift_AWSTransport by John Hobbs 12 for Amazon Web Services SES. SES has the 11 ability to return an XML response with diagnostic 10 information for each message sent through 9 it. Though SwiftMailer doesn't inherently 8 understand how to use that XML response, I 7 have found it invaluable for troubleshooting 6 delivery. I mention it because I found 5 that in some cases, checks #1 and #2 above 4 will appear successful to SwiftMailer, yet 3 SES didn't like something about my message 2 formatting. I'm therefore looking into 1 parsing that XML as an additional check.
Rather old post, but as of Swiftmailer 4+ and 7 aside from getting the result
status from the 6 send
method call. If you're wanting to debug 5 your mailer and see what is happening during 4 the transport, you can use the Logger Plugins, or 3 even create your own Plugin.
https://swiftmailer.symfony.com/docs/plugins.html
$mailer = \Swift_Mailer::newInstance(
\Swift_SmtpTransport::newInstance('tls://smtp.gmail.com', 465)
);
$logger = new \Swift_Plugins_Loggers_ArrayLogger;
//$logger = new \Swift_Plugins_Loggers_EchoLogger; //echo messages in real-time
$mailer->registerPlugin(new \Swift_Plugins_LoggerPlugin($logger));
foreach ($recipients as $recipient) {
//...
$mailer->send(/*...*/);
}
echo $logger->dump(); //not needed if using EchoLogger plugin
Which will 2 output the transport message for each send
call, that 1 looks like
++ Starting Swift_SmtpTransport
<< 220 smtp.gmail.com ESMTP x12sm4143221vkc.19 - gsmtp
>> EHLO server.example.com
<< 250-smtp.gmail.com at your service, [192.168.1.1] 250-SIZE 35882577 250-8BITMIME 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8
>> AUTH LOGIN
<< 334 AbcDefGhIjKlMnop
>> AbcDefGhIjKlMnop==
<< 334 AbcDefGhIjKlMnop
>> AbcDefGhIjKlMnop==
<< 235 2.7.0 Accepted
++ Swift_SmtpTransport started
>> MAIL FROM:
<< 250 2.1.0 OK x12sm4143221vkc.19 - gsmtp
>> RCPT TO:<recipient@example.com>
<< 250 2.1.5 OK x12sm4143221vkc.19 - gsmtp
>> DATA
<< 354 Go ahead x12sm4143221vkc.19 - gsmtp
>> .
<< 250 2.0.0 OK 1468948643 x12sm4143221vkc.19 - gsmtp
Swiftmailer has nothing to do with the actual 11 delivery of the mail. It just hands things 10 over to whatever SMTP server you specified, and 9 it's that server that takes care of the 8 delivery. You need to check the SMTP server's 7 logs to see what happened to the mail. It 6 may get stuck in the outgoing queue because 5 the server's swamped. It may get stuck in 4 a queue because the receiving end is unreachable 3 or is using grey-listing, etc... Swiftmailer's 2 job ends once it gets acknowledgement from 1 the SMTP server that the mail's been queued.
More Related questions
We use cookies to improve the performance of the site. By staying on our site, you agree to the terms of use of cookies.