How EspoCRM handles bounced email in campaigns
A marketing lead who sends a campaign and sees hard bounces needs to know two things before the next send: what EspoCRM records about each failed address, and whether the target list will keep mailing it. The campaign log is where delivery outcomes for a send appear, and target lists are where the audience is maintained, so those are the places to check first. The planning decision is whether your team will rely on EspoCRM's handling of bounced messages as it is configured, or add a review step on top of it. That choice determines who cleans lists, how often they do it, and what evidence sales or marketing leadership can see.
This page separates what the EspoCRM documentation describes from what you must confirm in your own version and mail setup. No bounce-specific figures were supplied for this topic, so this page gives no thresholds, retry counts or timing for when an address is marked invalid. Confirm every threshold and mechanic with your version's documentation and by testing a controlled list of addresses on a non-production instance. Also confirm how bounce notices reach EspoCRM, since that depends on the sending account, the mailbox that receives returned messages and how your sending domain is authenticated.
Bounce processing also depends on background jobs. The EspoCRM server configuration documentation states that cron or a scheduled task is required for background jobs, so updates to campaign results rely on that schedule running reliably. If the schedule stops or runs late, outcomes may appear after the send looks complete. Plan a check that compares the campaign log against the target list after each send, and add monitoring for the scheduled job. Agree on this check with your operations team before go-live so that someone owns it after launch.
Bounce handling options and when each fits
This table compares four ways to handle bounced email in EspoCRM campaigns, showing the effort each adds, who usually owns it and the risk it leaves open. Read each row against your own sending volume and staffing, and treat the built-in option as something to test in your instance before relying on it. Most teams combine two or more options.
| Option | Effort it adds | Who owns it | Risk it leaves open |
|---|---|---|---|
| Built-in detection and invalid marking | Low once confirmed, but needs a test send to a known-bad address and a check that the address is flagged | CRM administrator who configured mail and campaigns | Bounces may not reach EspoCRM if mailbox or return-path settings are wrong, so confirm this in your version first |
| Manual review of the campaign log | Recurring review after each send, growing with list size | Campaign owner | Bounces found late or skipped, so the same bad addresses get mailed again in the next campaign |
| Pre-send list cleaning with exclusion lists or reports | Upfront work on every campaign, plus upkeep of the reports and exclusion lists | Marketing operations, with the CRM administrator for report logic | Addresses that go bad between sends stay on the list until the next clean, and exclusions only cover what someone has added |
| Routing bounces to a monitored group mailbox | Group account setup, a named monitoring owner and a routine for acting on each message | Owner of the shared mailbox, often operations or IT | An unwatched mailbox means bounces go unactioned, and the notice format from your sending provider may not parse cleanly |
| Checking the sending provider's own suppression data | Periodic comparison between provider records and EspoCRM, if the provider offers it | Email platform administrator | Two sources can disagree, and the provider may not hold the same records EspoCRM does, so confirm what it keeps |
Hard bounces, soft bounces and complaints need different rules
Permanent failures, often called hard bounces, mean the receiving server rejected the address for good, usually because the mailbox does not exist or the domain no longer receives mail. The usual intended treatment is to suppress the address from future sends, record the reason, and flag the contact or lead for review.
- Unknown mailbox: mark the address invalid on the record and remove it from active target lists so later campaigns skip it.
- Invalid domain: review the domain before acting on it, since a single failed domain may reflect a data entry problem rather than a closed company.
- Bounce reason: keep the failure text and date on the record so that the reason is visible to the next person who edits the contact.
- Re-import risk: a CSV import that updates existing records could overwrite a suppression flag, so confirm which fields an import can change.
Confirm with the vendor docs and a test send to a known-bad address which of these steps EspoCRM performs automatically and which need a manual action.
Temporary failures, often called soft bounces, mean delivery failed for a reason that may clear on its own, such as a full mailbox, a receiving server outage, a rate limit, or a greylisting response. The usual intended treatment is to retry later and to suppress only after repeated failures, because one soft bounce says little about the address.
- Full mailbox: retry later, since the recipient may free space within days.
- Server outage: distinguish an outage on the recipient side from a problem with your own sending account, which may affect every address in the send.
- Retry count: agree a retry limit and a point at which the address moves to review, and write it down before the first campaign.
- Background processing: retries depend on scheduled jobs, and EspoCRM's server configuration requires cron or a scheduled task for background jobs, so a stalled cron means no retries happen.
Confirm with the vendor docs or a test send how many retries EspoCRM attempts, how long it waits between them, and whether it marks an address after a set number of soft bounces.
A spam complaint means a recipient marked your message as spam in their mail client, and the mailbox provider may report that back to the sender. The usual intended treatment is immediate suppression of that address, followed by a review of how the address entered the list and whether the consent behind it still holds.
- Immediate suppression: stop all marketing sends to the address at once, since further mail increases the damage to your sender reputation.
- Source review: check whether the address came from a form, an import, a purchased list or an old event, and record the answer on the contact.
- Complaint signals: confirm whether EspoCRM receives complaint feedback from mailbox providers or whether you need a separate feedback loop.
- Reputation monitoring: complaint trends are usually watched outside the CRM, so assign an owner for checking sending-domain reputation.
Confirm with the vendor docs whether EspoCRM can detect and suppress complaints without manual steps, and ask your provider which complaint signals they expose to you.
Out-of-office messages and automatic replies are not delivery failures. The address is working, the recipient is away or has set up an automated response, so these messages should not lead to suppression. The intended treatment is to ignore them for list hygiene while still logging them, so that teams can see the response and avoid sending a reply that creates a loop.
- Not a bounce: an out-of-office reply should not mark the contact invalid or remove it from a list.
- Loop prevention: auto-responses sent to auto-responses can keep two mailboxes busy, so check how group mailboxes handle messages that carry automatic-reply headers.
- Logging: keep auto-replies visible on the activity timeline, so a return date or a handover note is not lost.
- Classification: separate true bounce notifications from human or automatic replies in your review process, since they arrive in similar formats.
Confirm with the vendor docs and a test send from a mailbox with an out-of-office rule how EspoCRM classifies these messages and whether a campaign reply is recorded against the contact.
Why list hygiene shapes sender reputation
Repeated sends to invalid addresses damage the reputation of the sending domain and IP address at receiving providers. When a campaign from EspoCRM hits many addresses that no longer exist or never did, the receiving servers see a pattern: the sender is not maintaining its audience. Mailbox providers use bounce rates as one signal when they decide whether to deliver, filter or reject future messages from that domain and sending address. Each campaign that repeats the same bad addresses adds to that signal, so the damage grows with every send. The exact thresholds are set by each provider and change over time, so ask your mail provider and your deliverability specialist for current requirements before you set any internal limit.
Complaints usually weigh more heavily than bounces. A recipient who marks a message as spam tells the provider that the mail was unwanted, and that signal can affect delivery for the whole domain, not just one address. Invalid addresses often generate both problems, because stale lists tend to contain people who have left an organization or no longer recognize the sender. In EspoCRM, the bounce record for an address is only useful if the team acts on it. Confirm with your provider whether complaint feedback loops are available for your sending setup, and decide who receives those reports and how quickly they are reviewed.
A suppression process keeps the CRM list usable for later campaigns. The practical goal is that an address which has bounced is recorded, marked as invalid on the contact or lead, and excluded from future target lists by default, so it does not return to a campaign by accident. Record the rule in your campaign procedure: who reviews the bounce log, which bounce types lead to suppression, and when an address may be restored after the owner corrects it. Without this step, target lists grow stale, every new campaign inherits old failures, and the sending reputation you rely on for newsletters and transactional mail erodes over time.
Setting up bounce detection and invalid-address handling
This sequence confirms that bounces reach a place someone reviews, that background jobs can process them, and that addresses flagged as invalid stay out of later sends. The result is a documented, tested loop between sending, bounce review and the target lists.
Confirm the sending account and SMTP settings
The administrator opens the outbound email account used for campaigns and checks the SMTP host, port, encryption, sender address and authentication against the mail provider's current documentation. Send a single test message to an internal mailbox from the account to confirm it leaves the server without errors. Done means the test message arrives with the expected sender name and address, and the campaign's sending account is recorded in your runbook.
Decide where bounces return
Choose the path bounce notices take: a monitored group mailbox, such as a shared operations address that is linked to EspoCRM, or a scheduled review of the campaign log by a named person. Ask your mail provider whether bounce notices go to the envelope sender (return path) and whether that address can be routed to a mailbox your team reads. Done means you can point to one address or one review step that every bounce is expected to reach, written down with its owner.
Confirm background jobs run on schedule
Ask the administrator to confirm that cron or the scheduled task runner executes the EspoCRM jobs on the server, as the server configuration documentation requires for background processing. Check that the job runner is active and that jobs complete without errors in the application logs. Done means a scheduled job runs on its expected interval and the output is visible in the logs, so bounce processing and sending both have a reliable trigger.
Run a controlled test send to seeded addresses
Create a small target list of internal and test addresses, including at least one deliberately invalid address on a domain you control or a mailbox you know will reject mail. Send a test campaign from the configured account using a template that identifies it as a test. Done means the list contains a known set of deliverable and undeliverable recipients, and the send has been recorded in the campaign log before you move on to the next step.
Check the campaign log and address records
After the test send and the scheduled processing window have passed, review the campaign log for the sent, failed and bounced entries. Open the record for the invalid address and confirm whether it was marked invalid or flagged, and whether the bounce reason was captured. Done means you can show, for each seeded address, what was sent, what bounced and which record now carries the invalid status.
Confirm the target list excludes flagged addresses
Rebuild or reuse the same target list and run a second test send to the seeded set. Confirm that the invalid address is excluded from the recipient count and does not appear in the send log. Done means the flagged address was skipped on the next send, and the recipient count matches the number of deliverable seeded addresses.
Document the owner and review cadence
Write a short runbook entry that names the owner of bounce review, the mailbox or log used, the escalation path for a sudden rise in bounces, and the review cadence your organization chooses. Include the sending account, the cron or scheduled task dependency and the test addresses used. Done means the runbook is approved by the campaign owner and the administrator, and the next scheduled review is on a calendar.
Questions teams ask before handling bounces in EspoCRM
What drives the effort of bounce handling in EspoCRM?
The main drivers are how many mailboxes and sending accounts you run, how many campaigns go out each month, and how much your lists already contain bad addresses. Effort also grows with the number of rules you need for different bounce types, such as hard bounces versus temporary delays, and with how many people must review invalid addresses before they are suppressed. Ask any partner to split the quote into configuration of detection and logging, rules for marking addresses invalid, testing with real bounce messages from your provider, and handover to your operations staff. Each of these items should be listed separately so you can see what is one-time work and what your team maintains afterwards.
Can our team configure bounce handling in EspoCRM alone?
A technically capable administrator can often configure the basic settings, but the outcome depends on how your mail flows are set up. Bounce messages reach EspoCRM only through the mailboxes and sending accounts you have connected, so a team without experience of IMAP, SMTP and mail server logs may spend time on problems that are not visible inside the CRM. Confirm internally who owns the mail accounts, who can read bounce messages and who will review suppressed addresses each week. If those roles are unclear, a short scoped engagement to design the process and test it is usually easier than trial and error in live campaigns.
What does bounce handling need from our mail provider and IT team?
Bounce handling depends on your mail provider delivering the right information back to your sending systems. Your IT team should confirm which account sends campaign mail, which mailbox receives bounce notifications, and whether the provider uses return-path or bounce-address settings that EspoCRM can read. Ask your provider which sender authentication records are in place for your domain and who can change them. Your IT team also needs to approve outbound sending limits and any firewall or DNS changes. Write these requirements down before the build starts, because changing a sending domain or provider later affects every list and template.
How long does a bounce handling setup usually take?
The duration depends on the number of sending accounts, the state of your current lists, and how quickly your provider and IT team can respond to requests. A single sending account with clean lists is a much smaller task than several regional accounts with years of unmanaged contacts. Ask for a timeline in the written scope that separates discovery, configuration, test sends against your provider, and a review period. Fixed-scope engagements agree deliverables and dates before work starts, so you can check whether the plan depends on items you control, such as access approvals or DNS changes.
Does personal data in bounce messages need special care?
Yes. Bounce messages often contain the original recipient address, the subject line and sometimes parts of the message body, so they are personal data in most privacy regimes. Decide how long bounce messages are kept, who can read them, and whether they are stored as emails linked to contact records or only as summarized status fields. Limit access through EspoCRM roles and teams, and confirm with your privacy or legal team which retention period applies. Review the security guidance in EspoCRM's documentation on access control and restrict admin accounts that can view raw mail.
How do cron and background jobs affect bounce results?
Bounce processing in EspoCRM depends on scheduled jobs running on the server. EspoCRM's server configuration requires cron or a scheduled task for background jobs, so if cron is misconfigured or stopped, bounce messages may sit unprocessed while campaigns continue to send. This can result in repeated attempts to invalid addresses and a worse sender reputation. Check that the scheduled job runs on the schedule you expect, that failures are logged, and that someone receives an alert when the queue stops. Include cron monitoring in the operations runbook so the team knows what to check first when campaign results look wrong.
When should we bring in a partner for bounce handling?
Consider a partner when campaigns are business-critical, when several sending accounts or providers are involved, or when your team cannot test bounce detection without disrupting live sends. A partner is also useful when the setup must pass a review by your security or compliance function, since the documentation, test evidence and handover need to be clear. Ask any provider for a written scope, a list of deliverables, the testing approach, and what your team must do after handover, including who reviews suppressed addresses. Keep in mind that DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
Protecting personal data and access in bounce records
Bounce records look harmless, but they carry recipient addresses, message content and campaign history. The controls below decide who can see that data, how long it stays, and whether it leaves the system as an export. Treat the bounce log, target lists and the mail account as one data set when you set roles, teams and retention.
Restrict campaign logs and target lists
A bounce entry can show the recipient address, the campaign name and the returned message text, which may quote the original email. Limit who can read campaign logs and target lists through roles and teams, so that marketing users see only the campaigns and audiences they own. Check the effective permissions with a test user from each team before the first live send, because a broad read permission on one entity exposes the related bounce data.
Keep admin accounts out of daily review
Reviewing bounces is routine work and does not need administrator rights. Assign a dedicated role that can read campaign results and mark addresses, and keep administrator accounts for configuration and recovery only. The EspoCRM security guidance recommends avoiding admin accounts for daily work, so a compromised workstation session does not expose system-wide settings or mail credentials.
Apply the password and session policy
Bounce review happens inside the CRM session, often on laptops that leave the office. Apply the password policy, require two-factor authentication where your identity setup allows it, and set a limited auth token lifetime so an idle session does not stay open. Confirm with your identity team how two-factor authentication interacts with OIDC sign-in, since EspoCRM's own 2FA is not compatible with OIDC.
Keep mail credentials out of shared notes
Bounce handling depends on a mail account that the CRM uses to receive returned messages, and its password or token must not be copied into runbooks, tickets or shared spreadsheets. Store the credentials only in the EspoCRM mail account settings, limit who can open those settings, and rotate the credential through the same settings page. Ask your team where existing copies live before go-live, since old notes are a common source of exposure.
Plan retention for bounce logs
Bounce logs accumulate with every campaign and may outlive the business reason for keeping them. Decide how long returned-message records stay in the CRM, who approves deletion, and how deletions are recorded for your privacy obligations. Confirm with your compliance lead whether bounce history must be kept for suppression purposes, and document the retention rule before the first campaign so it is applied consistently.
Control exports of invalid addresses
A filtered list of invalid addresses is useful for cleanup but is also a personal data set that can leave the CRM in a spreadsheet. Decide which roles can export lists and campaign results, and whether exports are logged. Confirm with your administrator how the export permission is set for each role, and make sure a list of invalid addresses is treated with the same handling rules as the live audience it came from.
How DeployOpen scopes and delivers EspoCRM email setup
DeployOpen starts from your campaign volumes, sending accounts and list sources, then agrees in writing how bounce detection, invalid-address handling and sender reputation checks will work in your EspoCRM instance. The build runs in infrastructure you control, and the handover leaves your team with settings, runbooks and a support path they can use without us.
How we scope
- Inventory every sending account, campaign type and target list that will receive bounce handling changes.
- Confirm with your mail provider which bounce and complaint notifications it can return to EspoCRM.
- Agree in writing which addresses are marked invalid, who may reactivate them and how exceptions are approved.
How we build
- Configure and test bounce capture on a staging instance using sample bounced messages before any live send.
- Check that the EspoCRM cron job or scheduled task runs reliably, since background processing depends on it.
- Test list cleanup and campaign exclusion rules against representative target lists before production use.
How we hand over
- Document each bounce setting, the fields used to flag invalid addresses and the expected log entries.
- Provide a short runbook for reviewing bounce logs, reactivating addresses and escalating sender reputation issues.
- Walk your campaign and operations staff through the workflow and record the acceptance tests that passed.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask us to confirm which deliverables cover changes to your provider settings or EspoCRM version upgrades.
