How mass email campaigns from EspoCRM work and when teams need them
EspoCRM's campaign functionality sends newsletters and campaign emails to people who already exist as records in the CRM, so each send stays tied to the accounts, contacts, leads or users it reached. It fits teams that already run customer relationships in EspoCRM and want mailings to follow those same records instead of exporting lists to a separate marketing tool. Four objects make up the setup: a campaign (the send itself, with its audience, schedule and status), a *target list* (the audience, built from CRM records), a *template* (the message content and placeholders), and a *sending account* (the mailbox or mail configuration the messages leave from). Each one needs an owner before the first send.
The open-source edition is licensed under AGPL-3.0 and can be downloaded and self-hosted at no license cost, according to the EspoCRM pricing page. The cost of running it still sits with you: servers, the mail infrastructure that delivers the messages, backups and staff time to maintain templates and lists. The decision that matters most early is whether bulk campaigns go through a dedicated sending account or through a mailbox that also carries one-to-one customer correspondence. Ask your team to confirm how the chosen sending setup handles volume and throttling before any list is loaded.
Multi-step automation, such as drip-style sequences triggered by record changes, is not part of the campaign basics. EspoCRM places this kind of workflow in the Advanced Pack, an official add-on that also provides reports and Business Process Management, and the Advanced Pack page describes it as included in all EspoCRM Cloud plans. For a self-hosted deployment, plan that add-on as a separate decision and confirm its current licensing and compatibility with your EspoCRM version. Single newsletters and one-off campaigns can be planned without it, but the audience and consent rules should be settled either way.
Which campaign configuration options fit which sending situation
This table compares the main campaign configuration choices in EspoCRM: sending account, audience source and test strategy. Read each row for the situation it fits, the trade-off it carries and what to confirm before the first live send. The main takeaway is that sending volume and reputation depend on your mail provider and server settings, so confirm those limits before you plan a large send.
| Configuration choice | When it fits | Trade-off to weigh |
|---|---|---|
| Shared group sending account | Newsletters or announcements sent on behalf of a team, such as marketing@, where replies should reach a shared inbox | Replies and bounces land in one place, which helps traceability, but one account carries the sending reputation of every campaign and needs careful rate planning |
| Personal sending account | Small, individually addressed outreach where the sender's name should be the visible owner of the message | Recipients see a named person, but campaign volume is tied to one user's mailbox and replies are harder for a team to pick up |
| Static target list | A fixed audience that has been reviewed, such as a signed-off newsletter list or a one-time event invitation | Easy to audit and reuse, but the list goes stale unless someone removes bounces, unsubscribes and changed contacts before each send |
| Target list synced from a report | Recurring audiences defined by criteria, such as customers in a region or leads created in the last month | Membership follows the data automatically, but the report filters must be checked, since a wrong filter sends to the wrong people |
| Test send to internal addresses | Checking layout, merge fields, links and sender details before any live send | Low risk and quick to repeat, but internal inboxes may not reveal spam filtering or rendering issues in external mail clients |
| Full send to the whole audience | After test sends pass and the list has been reviewed for consent and exclusions | Reaches the real audience, but mistakes cannot be recalled, so the review step carries the most weight |
| Sending rate and batch settings | Any campaign above a small audience, where pacing matters to the mail provider | Ask your server and mail provider to confirm current sending limits and rate settings before scheduling. DeployOpen does not set these figures for you. |
Setting up a first campaign in EspoCRM
This sequence takes a first mass email campaign from a verified mail server to a logged launch, with a check at each step so problems surface on a test list rather than in front of subscribers. The result is a campaign you have sent to internal addresses, reviewed in the campaign log, and are ready to release to the full audience.
Confirm mail delivery and cron on the server
Your administrator confirms that the server can send mail and that the scheduled job runner is active. EspoCRM relies on cron or a scheduled task for background jobs, and campaign sending is processed through that queue, so a server without a working cron entry will accept a campaign but never dispatch it. Check the server configuration documentation for the cron requirement that applies to your installation. The step is done when a test job runs on schedule and the server's outbound mail path has been tested with a message that arrives in an internal inbox.
Configure the sending account and SMTP
An administrator creates the outbound email account in EspoCRM, enters the SMTP host, port, encryption and credentials, and sets the from address and name that subscribers will see. Confirm with your mail provider which sending domain, return path and authentication method they require, and check that SPF, DKIM and DMARC records already cover that domain, because these records affect whether messages reach the inbox. The step is complete when a plain test message sent from this account arrives with the expected sender name and passes your provider's authentication checks.
Build and test the email template
A marketing user creates the email template with the subject line, body and any merge fields, such as the recipient's first name or account name, that the campaign will fill from each record. Keep the template simple at this stage and include the unsubscribe or opt-out wording your consent process requires. Save a rendered preview against a sample contact to check that every merge field resolves and that no placeholder text appears. The step is done when the preview shows correct values for a known record and no unresolved tokens.
Prepare and check the target list
The campaign owner builds the target list from accounts, contacts, leads or users and removes records that should not receive the message, using an exclusion list where needed. Open a sample of entries and confirm that email addresses are populated, that duplicates are removed and that the list matches the intended audience. Note the total count so it can be compared with the number of messages dispatched later. The step is complete when the list contains only the intended recipients and the count matches the segment you defined.
Create the campaign and run a test send
The campaign owner creates the campaign, links the sending account, template and target list, and runs a test send to a small set of internal addresses that represent different mail clients and merge scenarios. Ask recipients to report the sender name, subject, merge field values, links and how the message renders on desktop and mobile. Compare the received copies with the rendered preview. The step is done when every internal recipient confirms correct content, working links and a functioning opt-out path.
Launch the campaign and monitor dispatch
After the test results are signed off, the campaign owner launches the campaign to the full target list and watches the queue through the job process, since background sending depends on cron running. Confirm that the number of queued jobs decreases over time and that messages are not failing with authentication or connection errors in the logs. The step is complete when dispatch reaches the expected count without repeated errors. If the queue stalls, check the scheduled job runner before sending again to avoid duplicate messages.
Review the campaign log
After dispatch, the campaign owner reviews the campaign log, which records sent, failed and opened or clicked activity where tracking is enabled, and compares the totals with the target list count. Investigate failed entries, note bounced addresses for list cleanup and record any issues for the next campaign. Confirm your privacy and consent obligations for tracking before enabling open or click tracking on future sends. The step is done when every recipient is accounted for in the log and follow-up actions are assigned to named owners.
Security and consent controls to plan before sending
Campaign sending is one of the highest-risk actions in a CRM, because a single compromised or misconfigured account can email thousands of contacts under your organization's name. The controls below limit who can send, how they sign in, and where they sign in from, while consent and opt-out handling stay with your legal and privacy team.
Enforce password policy and 2FA
Require a password policy and two-factor authentication for every user who can create, approve or launch a campaign. EspoCRM's security documentation recommends both, and a campaign sender account is an attractive target because it can reach a large contact list. Check that the policy applies to users with sending rights, not only to administrators. If you sign users in through OpenID Connect, note that EspoCRM's own 2FA is not compatible with that flow, so the identity provider must enforce the second factor.
Keep campaign work off admin accounts
Use a standard user account for building lists, templates and campaigns, and reserve administrator accounts for configuration. EspoCRM's security guidance recommends avoiding admin accounts for daily work, and an administrator who clicks a phishing link during a campaign review exposes the whole instance. Also consider disabling password recovery for admin accounts, so that a compromised mailbox cannot reset administrator access.
Restrict access by IP address
Limit the networks from which campaign users can sign in, such as the office network or a VPN range, if your team works from known locations. This reduces the value of stolen credentials from outside those ranges. Confirm how IP restrictions interact with remote workers, mobile access and any API integrations that send from a fixed address, and test the rule with a non-admin user before enforcing it for everyone.
Limit who can create and launch campaigns
Set roles so that only a small group can create campaigns, attach target lists and launch sends, while other users can view reports. Separate the people who draft content from those who approve and send, where your process requires it. Review role assignments on a schedule, since staff changes often leave former users with sending rights. Confirm which entity and action permissions your version exposes for campaigns and mass emails before you publish the role matrix.
Shorten session and token lifetime
Limit how long authentication tokens remain valid, so that a session left open on a shared workstation cannot send mail for days. EspoCRM's security documentation lists token lifetime as a control to set. Pair this with a sensible idle timeout for users who handle campaign data. Ask your DeployOpen or internal engineers to confirm the exact configuration keys in your installed version before writing the setting into your baseline.
Assign consent and opt-out ownership
Consent records, opt-out handling and the lawful basis for each mailing are the organization's responsibility, not a configuration task for the CRM. Decide with your legal and privacy team which contacts may receive marketing email, how unsubscribe requests are recorded, and how fast suppression must take effect. Then confirm that the campaign setup honors those decisions, such as excluding opted-out contacts from target lists. DeployOpen can configure and test what you decide, but the policy itself belongs to your organization.
Running campaigns day to day: cron, logs and sender reputation
Background sending in EspoCRM depends on cron or a scheduled task, as the server configuration documentation requires for background jobs. If the scheduler stalls, a campaign looks stalled, even when the campaign itself is configured correctly. Before a campaign goes out, confirm that the cron entry runs on the production host, that it runs as the web server user, and that someone is alerted when it stops. Check the scheduler first whenever queued messages do not move. Treat it as an infrastructure dependency with an owner, not as a campaign setting. The exact cron schedule and job handling should be confirmed against the version you run, because the cron setup is documented per release in the EspoCRM server configuration docs.
After each send, review the campaign log in the campaign record and look for failed sends, not just the total sent count. Repeated failures for one mail account often point to an authentication or SMTP problem on that sending account, while failures spread across many addresses usually point to list quality. Record who reviews the log, how often, and what threshold pauses the next send. Keep the list clean by acting on every bounce and unsubscribe before the next campaign uses the same target list. The bounce handling process itself is covered on its own page, so the job here is to make sure someone reads the results.
Sender reputation depends on the mail provider receiving your messages and on how your sending domain is authenticated, including the SPF, DKIM and DMARC records your team publishes. EspoCRM does not set these records for you, and the effect of a poor send history varies by provider and by the volume and complaint rate you generate. Ask your mail provider and your DNS owner to confirm the authentication records for each sending domain, and ask the provider what complaint and bounce levels they expect from bulk senders. Keep a short written record of which campaigns went to which lists, so that a sudden drop in delivery can be traced to a specific send.
Questions teams ask before sending their first campaign
What does it cost to run mass email campaigns in EspoCRM?
The EspoCRM open-source edition is free to download and self-host, according to the EspoCRM pricing page, and it is licensed under AGPL-3.0. Your recurring costs sit outside the license: the servers or cloud accounts that run EspoCRM, the database, backups, and your mail provider's sending fees. If you choose the hosted EspoCRM Cloud service instead, the pricing page lists per-user monthly plans, and the Advanced Pack is included in every cloud plan. Ask any partner for a quote that separates one-time setup work from recurring infrastructure, mail provider and support costs.
How long does a campaign setup take, and what drives the timeline?
The duration depends mostly on the state of your data and the number of sending paths you need. Cleaning and importing contact lists, agreeing on which audiences may receive which messages, designing templates, and configuring one or more sending accounts usually take the most time. Test sends, a review of how bounces and unsubscribes are handled, and a controlled first send to a small list add further steps. A fixed-scope written plan from DeployOpen would state the timeline for your environment before work starts.
What must our team provide before a campaign implementation starts?
Plan to supply the following before work begins:
- Contact and target list data, with a clear owner for consent and opt-out status
- Brand templates, sender names and the approved wording for footers and unsubscribe text
- Access to the sending domain's DNS so authentication records can be checked and set
- Credentials or administrative access to the mail provider or SMTP service that will send the mail
- A named business owner who approves the audiences and the first test send
Confirm with your mail provider which sending limits and authentication methods apply to your account.
Can an internal administrator set up EspoCRM campaigns alone?
Yes, a competent internal administrator can configure campaigns alone if they have time, access to the server and mail provider, and a clear understanding of consent rules. The harder parts are usually outside EspoCRM: domain authentication, managing bounces, and keeping audiences compliant. Use separate administrator and daily-work accounts, as the EspoCRM security documentation recommends, and test each sending account before a live send. A partner is most useful when the team lacks time, has several sending accounts, or needs an independent review before going live.
What happens when a campaign send fails partway through?
Failed or interrupted sends depend on the background job processing that EspoCRM runs through cron or a scheduled task, so confirm that scheduled job is running before any campaign. Check the campaign log to see which recipients were processed and which were not, and review the mail server and sending account settings for authentication or limit errors. Do not resend to the full list without reviewing the log, because duplicate sends damage trust and sender reputation. Your runbook should state who can pause a campaign and how the remaining recipients are resumed.
How do bounces and unsubscribes affect future campaigns?
Bounces and unsubscribes should be fed back into your lists so that addresses that cannot receive mail or have opted out are excluded from later sends. Confirm how your EspoCRM version detects and records bounced messages, and who reviews them. Repeated sends to invalid addresses can hurt your sender reputation with mail providers, which affects delivery for all your messages, not only campaigns. Set a review step after each send so that the cleanup is a routine task.
Which EspoCRM campaign data should we back up before the first send?
Back up the database and the file storage of the EspoCRM instance before the first live campaign, so you can recover target lists, templates and the campaign log if something changes. Confirm your restore procedure with a test on a separate copy. The installation script includes a command.sh utility for backups, restores and upgrades, according to the EspoCRM installation documentation, but you should still verify that backups are complete and restorable in your own environment.
Limits to confirm in your environment
Campaign capacity in EspoCRM depends on the version you run, the extensions you add and the mail provider you send through. The cards below list the limits and prerequisites to verify against the EspoCRM documentation and your provider before you plan volumes or schedules.
Sending rate and batch behavior
Confirm how fast campaigns dispatch and how the queue is processed. Background jobs depend on cron or a scheduled task being configured on the server, so a stalled scheduler can look like a stalled campaign. Ask how batches are sized, how many messages go out per job run, and what happens to a batch that fails partway through. Then check the send rate your mail provider allows for your account, since that limit applies regardless of what EspoCRM is configured to do.
Maximum recipients per campaign
Find out whether the documentation sets a ceiling on recipients per campaign or per target list, and whether large lists behave differently from small ones. Test with a list at your realistic upper volume before a live send, and record how long dispatch takes. Your mail provider may also cap daily or per-hour recipients, which can split one campaign across several days.
Core compared with the Advanced Pack
Confirm which automated sequences the core campaign feature supports and which need the Advanced Pack. Drip campaigns, scheduled follow-ups and rule-based sends are the usual points of difference. The Advanced Pack is included in EspoCRM Cloud plans, while self-hosted installations must license and install it separately, so check the cost and the upgrade path for each option before you design the sequence.
Supported template features
Test which merge fields, personalization variables, HTML layout options and image handling the template editor accepts. Some newsletter designs depend on features that a given version or editor mode does not render consistently across mail clients. Send a test to several clients, including webmail and mobile, and confirm that unsubscribe links and footer content appear as your legal and consent process requires.
SPF, DKIM and DMARC at the sending domain
Verify that the domain used in the sending account publishes valid SPF records, that DKIM signing is enabled by your mail provider, and that a DMARC policy is in place with reporting addresses. Campaign mail sent without aligned authentication is more likely to land in spam or be rejected, regardless of list quality. Ask your mail provider which records they require and confirm them with a test message before the first production campaign.
Sending account and log retention
Confirm which mailbox or SMTP account a campaign uses, whether different campaigns can use different sending accounts, and how the campaign log records each send, failure and bounce. Check how long log entries and bounce data are kept in your installation, because your retention and audit obligations may require a longer period than the default. Ask how logs are backed up with the rest of the database.
When a partner helps with campaign setup and when your team can run it
A small team with an admin who knows email can usually configure a first campaign in EspoCRM without outside help. The work is mostly settings and discipline: create a campaign, attach a target list, choose a template, pick a sending account, send a test to internal addresses, and check the campaign log afterward. If the people doing this understand how their mail server authenticates messages and how their own unsubscribe handling works, an internal team can run a single newsletter well. Outside help adds the most value once the setup goes beyond one list and one mailbox.
Three situations tend to justify a partner. The first is list data spread across systems, where contacts sit in a website form tool, a spreadsheet, a billing platform and EspoCRM, with different identifiers and conflicting opt-in states. Deciding which source wins, how duplicates merge and which records are safe to mail is data design, and it is easier to settle before the first send. The second is consent evidence. Your team should confirm what records of consent it must keep, where they live as fields or related records in EspoCRM, and who can change them. That design affects target lists, templates and the campaign log, and a reviewer may ask to see it. The third is coexistence with existing marketing tools, where a campaign must stay consistent with an external email platform, a webhook or an automation chain already in use.
If your team is weighing these options, ask a prospective partner to name the campaign components it would configure, the data sources it would map, and the consent fields it would propose, then compare that list with what your admin can already do. Confirm with your own environment whether your mail provider's sending limits, bounce handling and authentication settings match the campaign volume you expect. A written scope lets you see which parts are one-time design work and which parts your team will maintain after the first send.
How DeployOpen scopes and delivers campaign setup
This sequence moves a team from a rough campaign idea to a tested, documented EspoCRM mailing setup that the team can run without outside help. Each step ends with a written output or a check that someone signed off on.
Agree scope and deliverables in writing
Before any configuration begins, DeployOpen and your team agree the scope in writing: which campaign types you will send, which entities feed target lists, which sending accounts are in use, and which deliverables you will receive. Your marketing lead and an EspoCRM administrator confirm the list. Timelines are fixed in the same document. The step is complete when the signed scope exists and the quote that follows from it has been accepted. Ask for the scope to name every deliverable so later disagreements have a reference point.
Review target data and consent assumptions
DeployOpen reviews the contact and lead records that will receive mail, checking how consent and opt-out status are recorded today, which fields hold email addresses, and how duplicates and invalid addresses are handled. Your legal or privacy owner states the lawful basis your organization relies on for each audience, because that decision belongs to you, not the implementer. The output is a short written note listing which records are eligible, which fields drive exclusions, and any gaps to fix before import. Do not start list building until this note is approved.
Configure sending accounts and deliverability settings
DeployOpen configures the outbound email accounts the campaigns will use, including SMTP details, sender names, reply-to addresses and any personal or group account permissions. Credentials are stored under your secrets controls, and access is limited to the roles that need it. Confirm with your mail provider the sending limits, authentication records and bounce handling that apply to your domain, since these come from your provider and domain setup, not from EspoCRM. The step closes when a test message from each account arrives with the expected sender details.
Build templates and target lists
DeployOpen builds the email templates in the agreed structure, sets merge fields, and creates the target lists and exclusion lists defined in the scope. Each list is documented with its source, filter logic and refresh method. Your team reviews the rendered templates on sample records to confirm that merge fields resolve and that unsubscribed contacts are excluded. The output is a template set and a list inventory signed off by your marketing owner.
Run supervised test sends
DeployOpen runs test sends to seed addresses your team controls, across the mail clients your audience uses, while a named reviewer watches the results. The test covers rendering, links, unsubscribe behavior, sender identity and campaign log entries. Any defect goes back into the template or configuration and is retested. The step is complete when the reviewer signs a test record listing each check and its result.
Hand over runbooks and train operators
DeployOpen delivers runbooks that describe how to create a campaign, select a target list, schedule or launch a send, read the campaign log, handle bounces and roll back a template change. Your administrators and marketing operators are walked through the runbooks on your own instance. The handover is complete when your operators run a supervised send of their own and the runbooks match what they did. Keep the runbooks under version control with your EspoCRM configuration.
Arrange ongoing support if needed
Changes after handover, such as new templates, new sending accounts, EspoCRM upgrades or recurring campaign reviews, can be covered by a retainer agreed separately in writing. Ask for the retainer terms to state response expectations, included activities and how changes are priced. The output is either a signed retainer or a documented decision that your team will run campaigns independently. Quotes for every option follow from the written scope, so the cost of each choice is visible before you commit.
