A bounce is the mail system telling you an email couldn't be delivered. Handling bounces well keeps your list clean, protects your sender reputation and stops you mailing people who can never receive your messages. Mailbox providers see repeated sending to dead addresses as a sign of poor list care, so this one matters!
This guide covers how to read bounce codes and how to make sure bounces get back into Mautic.
Most bounces include a three-part code like 5.1.1. The format comes from RFC 3463, and the first number tells you the most important thing.
| Code | What it means | What to do |
|---|---|---|
5.1.1 |
The mailbox doesn't exist | Stop mailing this address |
5.1.2 |
The domain can't receive email, often a typo like gmial.com |
Stop mailing this address |
4.2.2 |
Mailbox full | Retry, and stop if it keeps happening |
4.4.x |
Network or connection trouble | Usually sorts itself out |
5.7.1 |
Refused for policy reasons, often called a block bounce | Don't remove the contact, investigate why |
4.7.x or 5.7.x from Gmail |
Your email doesn't meet Gmail's sender requirements (Google, n.d.) | Fix authentication or unsubscribe headers |
Based on information from RFC 3463 and Google.
That 5.7.x row is the one that you need to investigate more deeply. A policy block is a 5, so it looks like a hard bounce, but it's about you, not the recipient. If one provider suddenly starts returning 5.7.1 for lots of contacts, removing them all hides the real problem. Read the text that comes with the code, as providers often include a link explaining the block. Check whether your domain or sending IP address is on a blocklist (MXToolbox has a free checker), and see How to meet Gmail, Yahoo and Microsoft sender requirements with Mautic.
Mautic marks bounced contacts as Do Not Contact for email, so they drop out of future sends. For that to happen, the bounce has to reach Mautic. There are two ways.
Most email services (Amazon SES, SendGrid, Mailgun, Brevo and others) can send bounce and complaint notifications back to Mautic automatically. Check the documentation for the Mautic transport or plugin you use, set up the callback or webhook URL it gives you at your email service, and turn on bounce and complaint events.
This is the most reliable option, because some services replace the return path with their own address, so bounce emails never reach your inbox. The Mautic documentation calls out Gmail and Amazon SES as examples.
Mautic can read a mailbox over IMAP and pick up bounce messages.
[email protected].php /path/to/mautic/bin/console mautic:email:fetch
Mautic uses an address like [email protected] as the return path, so when a bounce comes back it knows which email and contact it belongs to (Mautic, n.d.).
Send a Mautic email to an address you know doesn't exist on a domain you control, then wait a few minutes and check that contact in Mautic. It should be marked as Do Not Contact with a bounced reason. It's the only way to be sure the whole chain works!
5.7.1 from one provider points to a reputation or authentication problem there, not a list problem.How are you getting bounces back into Mautic, webhooks or a monitored inbox? I'd love to hear which setups have worked well for you, so we can share them with the wider community.
Google Email sender guidelines FAQ. Gmail Help. Available at https://support.google.com/mail/answer/14229414?hl=en-GB (Accessed 26 October 2026).
Mautic Emails (Mautic user documentation, 5.x). Available at https://docs.mautic.org/en/7.2/channels/emails.html (Accessed 26 October 2026).
Vaudreuil, G. (2003) Enhanced mail system status codes. RFC 3463. Internet Engineering Task Force. Available at https://datatracker.ietf.org/doc/html/rfc3463 (Accessed 26 October 2026).
Article Number: 248
Author: Oct 26, 2026
Last Updated: Oct 26, 2026
Author: Ruth Cheesley [[email protected]]
Online URL: https://kb.mautic.org/article/how-to-handle-email-bounces-in-mautic.html