Application Settings
The Application Settings page is your central hub for configuring how Mumara Campaigns behaves across your entire installation. From email delivery to security policies, these settings affect every user and every campaign in your system.
Navigate to Settings → Application Settings to access these options.
General Tab
The General tab contains fundamental settings that control how your Mumara installation operates at a system level.
Security Options
| Field | Description |
|---|---|
| Force secure URL | Enforces HTTPS connections on all internal links within Mumara Campaigns. Requires SSL to be installed on your server. Always enable in production - required for secure cookie handling and prevents mixed-content browser warnings. |
| Debug mode | Shows detailed PHP error messages and stack traces when something goes wrong. Only enable during troubleshooting. Never enable in production - it exposes sensitive information like file paths and database queries to users. |
| Development mode | Disables internal caching so template and configuration changes appear immediately. Only enable during development or theme customization - significantly slows down page loads. |
Application Settings
| Field | Description |
|---|---|
| Application URL | The base URL used for generating links in emails, redirects, and API responses. Automatically set during installation - only change if you migrate to a new domain. |
| Application Title | The name displayed across the platform, including in the browser tab, notifications, and email headers. Customize it to reflect your brand or organization's identity. |
| Server IP | The IP address of the server where Mumara Campaigns is installed. Automatically detected and displayed for informational purposes. |
| Timezone | The default timezone for scheduling campaigns, displaying timestamps, and calculating send times. Users can override this in their profile settings. |
Sending & Processing Limits
| Field | Description |
|---|---|
| Number of messages per connection | How many emails to send per SMTP connection before closing and reopening. Higher values (100-500) are faster, but some mail servers disconnect after too many messages. Start with 100 and increase if stable. |
| Delete campaign logs after (days) | How long to retain campaign delivery logs. Logs consume significant database space. Set based on how long you need detailed per-recipient delivery data for troubleshooting or compliance. Set to 0 to keep indefinitely. |
| Daily sending limit | Maximum emails sent per day across the entire system. Set to 0 or -1 for unlimited. Use this to match your ESP's rate limits and avoid account suspension. |
| Monthly sending limit | Maximum emails sent per month across the entire system. Set to 0 or -1 for unlimited. Global cap that overrides all user-level limits. |
| Maximum contacts limit | Total contacts allowed across all users. Set to 0 for unlimited. Use to prevent database overload on shared installations. |
| Support email | Email address displayed to users when they need help or encounter errors. This email appears in error messages and support links throughout the application. Use a monitored support address. |
| Chunk size | Number of records processed per batch during imports, exports, and bulk operations. 500-1000 is typical. Lower values use less memory but take longer. Increase if you have ample server RAM. |
| Delay between chunks | Seconds to wait between processing batches. 1-5 seconds is typical. Increase if you see timeouts or high server load during bulk operations. |
| Suppression processing chunk size | Number of suppression records processed per chunk. Ensures efficient handling of suppression email lists without overwhelming the server. |
Hooks Settings
Hooks (webhooks) notify external systems when events occur in Mumara - like a contact subscribing, an email bouncing, or a link being clicked.
| Field | Description |
|---|---|
| Enable hooks error logging | When enabled, logs failures when webhooks can't be delivered. Essential for debugging integration issues in production. |
| Return all variables in hooks | Returns all available data fields in webhook payloads. Useful for development but increases payload size and processing time. Caution: May affect performance in high-traffic environments. |
| Queue driver | How hook jobs are processed. See detailed explanation below. |
| How to process queues? | When using the Database driver, specifies how queued jobs are executed. See detailed explanation below. |
Queue driver
| Option | Description |
|---|---|
| Database | Stores and processes jobs using the database. Jobs are queued and processed separately from the web request - the user's action completes immediately while hooks fire in the background. More reliable and recommended for production. |
| Sync | Processes jobs immediately during the web request. If a webhook takes 5 seconds to respond, the user waits 5 seconds. Useful for debugging but never use in production - one slow webhook makes your entire application unresponsive. |
How to process queues?
When using the Database driver, you must specify how queued jobs are processed:
| Option | Description |
|---|---|
| Realtime | Queues are processed immediately when a hook event is triggered. Hooks fire within seconds. Good for low-volume installations where immediate webhook delivery matters. Downside: Creates more server processes, can overwhelm the server during high-volume sends. |
| Cronjob | Queues are processed automatically with the cron job at scheduled intervals. Hooks fire within 1-2 minutes. Good for most production installations - predictable resource usage. |
| Supervisor | A Supervisor process must be set up to manage the queues continuously. Hooks fire within seconds with better resource management than Realtime. Good for high-volume installations sending millions of emails. |
Supervisor Configuration Example:
[program:mumara-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/mumara/artisan queue:work database --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
numprocs=2
user=www-data
redirect_stderr=true
stdout_logfile=/var/log/mumara-worker.log
Miscellaneous Settings
| Field | Description |
|---|---|
| Disable help article buttons | Hides the "?" help icons throughout the interface. Enable if you're white-labeling and providing your own documentation. |
| Gravatar integration | Pulls user profile pictures from Gravatar based on their email addresses. When enabled, profile images are automatically displayed within the application. Disable if you need complete network isolation. |
| Enable user branding option | Allows users to upload their own logos and customize their branding. (Commercial ESP only) |
| Live events auto-refresh interval | Delay in seconds between requests for live event data on dashboards. Lower values (10-30) show updates faster but increase server load. 30-60 seconds is reasonable for most installations. |
| CTR Formula | How Click-Through Rate is calculated in statistics. Clicked/Opened is the industry standard (percentage of openers who clicked). Clicked/Sent or Clicked/Delivered can be useful for comparing raw engagement across campaigns with different open rates. |
Mail Tab
These settings control how Mumara sends system emails - password resets, notifications, alerts to administrators. This is separate from campaign sending, which uses Sending Nodes.
Mail Settings
| Field | Description |
|---|---|
| Mail Driver | Choose how system emails are sent. PHP Mail Function is simple but less reliable (emails often land in spam). SMTP is recommended for production - use a transactional email service like SendGrid, Mailgun, or Amazon SES for best deliverability. |
| Host | Your SMTP server address (e.g., smtp.sendgrid.net, email-smtp.us-east-1.amazonaws.com). Only shown when SMTP is selected. |
| Username | The username for SMTP authentication. For services like SendGrid, this is often "apikey". |
| Password | The password for SMTP authentication. For API-based services, this is typically your API key. |
| Port | The SMTP port number. 587 (TLS) is most common. 465 for SSL. 25 is unencrypted and often blocked by ISPs. |
| Encryption | Security protocol for the connection. Always use TLS or SSL in production - "None" transmits credentials in plain text. |
| Mail Encoding | Character encoding format. 8 Bit is standard for most use cases. Use Quoted-Printable or Base64 if you experience character encoding issues with special characters. |
| Sender Name | The name recipients see in their inbox (e.g., "Mumara Notifications" or your company name). |
| Sender Email | The "from" email address. Use an address on a domain you control with proper SPF/DKIM configured. Avoid generic addresses like [email protected]. |
| BCC Email | Optional. Every system email gets copied here. Leave empty unless you need to archive all outgoing system notifications. |
Add Global Header/Footer
When enabled, the header and footer defined below will be added to every outgoing email.
| Field | Description |
|---|---|
| Email header (HTML supported) | HTML content inserted at the top of every outgoing campaign email. Use for company branding, legal disclaimers, or consistent messaging across all campaigns. |
| Email footer (HTML supported) | HTML content inserted at the bottom of every outgoing campaign email. Common uses include company address, social links, or standard unsubscribe text. |
warning
Global headers and footers affect ALL campaigns for ALL users. For user-specific branding, use the template system or user branding features instead.
Compliance & Tracking Options
| Field | Description |
|---|---|
| Force unsubscribe link | When enabled, ensures every outgoing email includes an unsubscribe link, even if the sender forgets to add one. Required for CAN-SPAM and GDPR compliance. |
| Send system-generated emails to super admins | Copies system notifications (license alerts, critical errors, update notices) to all super admin accounts. Keeps administrators informed of important system events. |
| Insert Gmail Feedback-ID header | Adds Gmail's Feedback-ID header to outgoing emails. If you send significant volume, this helps Gmail correctly attribute spam complaints and feedback loop data to your sending infrastructure. |
| Enable unsubscribe form | Provides a public web page where anyone can enter their email address to unsubscribe. Some regulations require this as an alternative to in-email unsubscribe links. |
| Embed Message ID in tracking links | Adds the unique message identifier to tracking URLs. Useful for correlating clicks back to specific sent messages in your logs or external analytics. |
| Embed UTC timestamp in tracking links | Adds the send timestamp to tracking URLs. Helps with time-based analysis and debugging timezone-related issues. |
| Embed sender email in the tracking links | Includes the sender's email address in tracking URLs. Useful for advanced analytics segmentation. |
| Embed subject in the tracking links | Includes the email subject line in tracking URLs. Enables subject-line-based analytics in external tools. |
| Embed recipient email in the tracking links | Includes the recipient's email address in tracking URLs. Privacy note: This exposes the email address in the URL - consider GDPR and privacy implications before enabling. |
Domains Tab
Controls how sending domains, DKIM signing, tracking domains, and bounce handling behave across your installation. Many fields in this tab are only available with the Commercial ESP license.
Sending Domain Settings
DKIM & Tracking Defaults
| Field | Description |
|---|---|
| Default selector for DKIM | The prefix for DKIM DNS records (e.g., "key" creates key._domainkey.example.com). Standardizing the selector simplifies DNS documentation for your users. |
| Default prefix for tracking domain | Subdomain prefix used for click/open tracking (e.g., "click" creates click.example.com). Keep it simple and consistent. |
| Domain key size in bits | The cryptographic key strength for DKIM signatures. Options: 512, 1024, 2048 (recommended), 4096. 2048-bit is the modern standard. Some older DNS providers have character limits requiring 1024-bit. |
DNS Lookup Settings
When users add sending domains, Mumara verifies their DNS records using configurable methods:
| Field | Description |
|---|---|
| DNS lookup method used to fetch the current values | Method for initial DNS record verification. Dig is fast and accurate but requires the dig command on your server. Google Toolbox works anywhere but relies on an external service. (Commercial ESP adds: Mumara API Method 1, Mumara API Method 2) |
| DNS lookup method used to confirm and recheck the records | Method for subsequent verifications. You can use different methods - for example, Dig for initial fetch and Google Toolbox for rechecks to avoid local DNS caching issues. |
Domain Policies
| Field | Description |
|---|---|
| Allow users to add duplicate sending domains | When enabled, multiple users can add the same domain. Useful for agencies managing client domains or different departments using the same corporate domain. |
| Require domain ownership verification | When enabled, users must add a TXT record to prove domain ownership before sending. Essential for multi-user installations. |
When Require domain ownership verification is enabled, an additional option appears:
| Field | Description |
|---|---|
| Set existing sending domains | Choose how to handle domains already in the system: Requires Verification (mark existing domains as unverified), Doesn't Require Verification (mark as verified), or Do Nothing (keep current status). |
General Options
| Field | Description |
|---|---|
| Disable DNS recheck button for (minutes) | Cooldown period before users can recheck DNS records. Prevents excessive DNS queries. 5-15 minutes is reasonable. |
| PHP file name for tracking domain cloaking method | Filename used for the PHP cloaking tracking method (e.g., index.php). Only relevant when users choose the cloak option. |
| Use smart selection for tracking domain | Automatically selects the most appropriate tracking domain based on the sending domain being used. |
| Disable sending from unauthenticated domains | Blocks sending from domains without verified DKIM/SPF. Enable in production to enforce proper authentication. |
| Use Secure URL | Forces tracking links to use HTTPS. Always enable when SSL is configured to avoid mixed-content warnings. |
Commercial ESP-Only Features
The following settings are only available with the Commercial ESP license.
Fallback Return-Path
| Field | Description |
|---|---|
| Enable fallback Return-Path | When enabled, uses a system-wide Return-Path for bounce handling when users haven't configured custom bounce domains. |
When Enable fallback Return-Path is enabled, additional fields appear:
| Field | Description |
|---|---|
| Fallback domain | The domain used for the system-wide Return-Path address (e.g., bounces.yourdomain.com). |
| Bounce processing method | How bounces are processed: POP/IMAP (poll a mailbox for bounces) or Route to a bounce server (forward to an external bounce processor). |
When Route to a bounce server is selected, Mumara handles bounce processing through an external bounce server rather than polling a mailbox. This is the preferred method for high-volume senders as it provides real-time bounce processing and better scalability.
How it works:
When this option is enabled, each outgoing email gets a unique, auto-generated Return-Path address. The format looks like [email protected] - the random prefix ensures each email can be tracked back to the specific recipient and campaign when it bounces.
Users will see a Custom Bounce Domain option in their sending domain configuration. There, they set up a subdomain (like return.mydomain.com) and configure its DNS records to route bounces to your bounce processing server. If a user doesn't configure a custom bounce domain, the system uses the fallback Return-Path instead.
| Field | Description |
|---|---|
| Subdomain prefix for custom return-path | The suggested prefix when users create their custom bounce domain (e.g., "return" suggests return.userdomain.com). |
| Return-path domain | Your bounce processing server's domain. Users point their custom bounce domain's MX record here so bounced emails route to your server for processing. |
| SPF domain | The domain to authorize in SPF records. When users configure their custom bounce domain, the system checks if an SPF record already exists - if so, it automatically includes this domain in their existing SPF record. If no SPF record exists, the system generates a complete SPF record for them. This ensures proper email authentication without users needing to understand SPF syntax. |
Domain Eligibility Check
| Field | Description |
|---|---|
| Check Domain Eligibility | When enabled, verifies domains against reputation criteria before allowing them for sending. Helps prevent abuse. |
When Check Domain Eligibility is enabled, additional options appear:
| Field | Description |
|---|---|
| Check for Domain Age | When enabled, requires domains to be a minimum age before use. Prevents newly registered domains (often used for spam) from being added. |
When Check for Domain Age is enabled:
| Field | Description |
|---|---|
| Eligible Domain Age in Days | Minimum domain age required (e.g., 30 days). |
| Use default value | Use the system default age requirement. |
| Field | Description |
|---|---|
| Check for Blacklist | When enabled, checks domains against blacklist databases. |
When Check for Blacklist is enabled:
| Field | Description |
|---|---|
| API Key | API key for the blacklist checking service. Contact Mumara support if you don't have one. |
User Restrictions
These toggles hide options from users in multi-tenant installations to maintain consistency and prevent accidental misconfiguration:
| Field | Description |
|---|---|
| Disable default DKIM selector editing for sending domains | Forces all users to use your standardized DKIM selector. |
| Disable default prefix editing for tracking domains | Maintains consistent tracking subdomain naming. |
| Disable default prefix editing for custom bounce domain | Ensures uniform bounce domain configuration. |
| Disable downloading the DKIM Keys | Prevents users from downloading their private DKIM keys. |
| Disable regenerating the DKIM Keys | Prevents users from regenerating keys (which would invalidate DNS records). |
| Disable CNAME option for the tracking domain | Hides the CNAME tracking domain setup method. |
| Disable .htaccess option for the tracking domain | Hides the .htaccess tracking domain setup method. |
| Disable cloak option for the tracking domain | Hides the PHP cloaking tracking domain setup method. |
Tracking Domain Rotation
| Field | Description |
|---|---|
| Random selection of primary domain for tracking | Enables rotation between multiple primary tracking domains instead of using a single destination domain for all users. |
Why use tracking domain rotation?
In a typical setup, all users point their tracking subdomains (via CNAME or other methods) to a single primary destination domain on your server. This creates a single point of failure - if that primary domain gets blacklisted or experiences reputation issues, every user's tracking links are affected.
With rotation enabled, you can configure multiple primary destination domains. The system distributes users across these domains, so:
- Load is distributed across multiple domains rather than concentrating all traffic on one
- Risk is isolated - if one primary domain is blacklisted, only users assigned to that domain are impacted, not your entire user base
- Recovery is easier - you can rotate affected users to healthy domains while resolving issues with the problematic one
This is particularly valuable for Commercial ESP installations with many clients, where protecting the majority of users from a single domain's reputation problems is critical.
Fallback DKIM
| Field | Description |
|---|---|
| Enable fallback DKIM | When a user hasn't configured DKIM for their domain, emails are signed with your system-wide DKIM key. Ensures all outgoing emails are properly signed. |
When Enable fallback DKIM is enabled, the Fallback DKIM Settings section appears:
| Field | Description |
|---|---|
| Fallback DKIM selector | The selector for your fallback DKIM record. |
| Fallback DKIM domain | The domain used for fallback DKIM signing. |
| Key size in bits | DKIM key strength: 1024, 2048, or 4096 bits. |
| Public key | The public DKIM key to add to DNS. Click Regenerate keys to create new keys. |
| Private key | The private key used for signing (stored securely, never shared). |
After configuring, add the displayed TXT record to your DNS and click Verify to confirm the setup.
Contacts Tab
Controls contact management, import behavior, and data integrity settings.
Import Settings
| Field | Description |
|---|---|
| Rocket import chunk size | Rocket import uses direct database inserts for maximum speed. Higher values are faster but use more memory. 5000-10000 is typical for servers with 4GB+ RAM. Reduce if you experience memory errors during imports. |
| Contacts import default mode | Regular validates each contact (checks email format, deduplication) and is slower but safer. Rocket bypasses validation for speed - use only with clean, pre-validated data from trusted sources. |
| Update contacts counter upon deletion | Real-time keeps list counts accurate immediately but adds database overhead. Scheduled or Never improves performance for high-volume deletions - counts refresh during maintenance windows or stay static. |
| Allow users to select files from the server for importing | Lets users import files uploaded via FTP/SFTP directly from the server instead of browser upload. Essential for very large files (100MB+) that exceed PHP upload limits or cause browser timeouts. |
Contact Integrity & Compliance
| Field | Description |
|---|---|
| Disable users from importing contacts with confirmed status | Forces all imported contacts to have unconfirmed status, requiring them to opt-in before receiving campaigns. Protects against users importing purchased lists and falsely claiming they're opted-in. Essential for compliance-focused installations. |
| Disable sending emails to unconfirmed contacts | Blocks all campaign emails to contacts who haven't confirmed their subscription. Critical for enforcing double opt-in compliance. When enabled, only confirmed contacts receive broadcasts. |
| Force double opt-in for web forms | All web form signups require clicking a confirmation email link before being marked as confirmed. Required by GDPR in the EU and strongly recommended everywhere for list hygiene and compliance. |
| Disable email address modification for the contacts | Prevents changing a contact's email address after creation. Useful when email is used as a unique identifier for CRM integrations, or when you need audit trails showing the original subscribed address. |
Suppression Settings
| Field | Description |
|---|---|
| MD5 hashed email support for suppression | Accept MD5-hashed email addresses in suppression lists. Useful when receiving suppression data from partners, affiliates, or industry blacklists who won't share plain-text email addresses for privacy reasons. |
| Limit domain suppression count for users | Maximum number of domain-level suppressions (e.g., @competitor.com) a user can add. Prevents users from accidentally suppressing legitimate domains. Set to 0 for unlimited. (Commercial ESP) |
Campaigns Tab
Controls broadcast behavior, unsubscribe handling, sending node recovery, and statistics display.
Campaign Recovery
| Field | Description |
|---|---|
| Automatically resume auto-paused campaigns | When enabled, campaigns that were paused due to a broken SMTP connection automatically resume once the sending node connection is re-established. This only applies to connection failures, not limit-based pauses. Disable if you prefer manual control over campaign resumption after outages. |
| Restart stuck campaigns | When enabled, detects campaigns that have stopped progressing (usually due to a crashed PHP process or server restart) and automatically restarts them. |
| Restart stuck campaigns after | How long a campaign must be inactive before being considered "stuck" and automatically restarted. Set to 2-4 hours to avoid false positives during normal processing delays. |
Sending Node Recovery
When a sending node (SMTP connection) fails during a campaign, these settings control reconnection behavior:
| Field | Description |
|---|---|
| Recheck auto-disabled sending node connection interval | How often (in minutes) to test if a failed sending node is back online. 5-15 minutes is reasonable - too frequent wastes resources, too infrequent delays recovery. |
| Recheck auto-disabled sending node connection duration | How long (in hours) to keep retrying before giving up. After this duration, the node stays disabled until manually re-enabled. Set to 2-6 hours depending on your typical outage patterns. |
Unsubscribe Settings
| Field | Description |
|---|---|
| Enable unsubscribe confirmation prompt | Requires recipients to click "Yes, unsubscribe" on a confirmation page instead of unsubscribing instantly. Reduces accidental unsubscribes from email preview panes that auto-load images and prefetch links. |
| Turn on "Insert unsubscribe link" option by default when scheduling campaigns | Pre-checks the unsubscribe link option when users create new campaigns. Helps ensure CAN-SPAM/GDPR compliance even if users forget to add it manually. |
| Unsubscribe footer | When enabled, displays the unsubscribe content section below. |
| Unsubscribe Text | Plain text label for the unsubscribe link (e.g., "Unsubscribe from this list"). Used when HTML isn't rendered. |
| Unsubscribe Content (HTML supported) | Custom HTML content for the unsubscribe section. Replace the default "Click here to unsubscribe" with branded messaging. Supports personalization variables like {{contact.first_name}}. |
Sender Information
| Field | Description |
|---|---|
| Default sender information selection | Which sender profile to pre-select when users create new campaigns. Options include the first available sender, last used sender, or none (force manual selection). |
| Disable sender information selection from sending node when sending a broadcast preview | When enabled, test emails use the campaign's configured sender instead of inheriting from the sending node. Ensures preview emails accurately reflect final delivery. |
SMTP & Bounce Settings
| Field | Description |
|---|---|
| SMTP driver | The mail library used for sending campaigns. Symfony Mailer (recommended) is the modern, actively maintained library and the default choice. PHPMailer is a legacy option that will be removed in upcoming updates. Note: Swift Mailer has been deprecated and removed - if you were using it, switch to Symfony Mailer. |
| Default List-Unsubscribe email | Email address used in the List-Unsubscribe header when recipients haven't configured their own. Major email providers (Gmail, Outlook) use this to show a native "Unsubscribe" button. Use an address you monitor. |
| Limit bounce email retrieval | Number of days to look back when checking for new bounce emails. The system only scans emails within this window rather than the entire mailbox, keeping processing efficient. Default is 2 days, which works well for most installations with regular bounce processing. |
Statistics & Display Settings
| Field | Description |
|---|---|
| Ignore duplicate opens for | Time window (in minutes) during which multiple opens from the same recipient count as one. 30-60 minutes handles most email client preview behavior that can inflate open counts. |
| Enable broadcast filter on the dashboard for sending overview | Shows a filter dropdown on the dashboard to view specific campaign statistics. Useful when you have many concurrent campaigns. |
| Opened vs. unopened chart type on statistics pages | Choose between pie chart, bar chart, or other visualization styles for displaying open rate data on campaign statistics pages. |
| Metric calculation reference for statistics | Choose whether open/click rates are calculated against emails sent, delivered, or total audience size. "Delivered" is most accurate but requires ESP callback integration. (Commercial ESP) |
File Upload Settings
| Field | Description |
|---|---|
| Allowed Extensions | File extensions users can upload as email attachments (e.g., pdf, doc, docx, xls, xlsx). Restrict to prevent security issues - avoid executable formats like .exe, .bat, .js. |
Triggers Tab
Configure how the trigger (automation) processing engine operates. For detailed information about creating and managing triggers, see Triggers.
Trigger Timing
Instant contact-based triggers (contact added, field changed) execute in real-time. Delayed triggers and segment-based triggers are processed by cron - the maximum delay equals the cron interval.
Processing Settings
| Field | Description |
|---|---|
| Cronjob execution limit | Maximum number of trigger executions per cron job. Default is -1 (unlimited). Set a limit on shared servers to prevent resource exhaustion. |
| Records per execution | Number of records to process in each execution. Default is 20 to ensure optimal server performance. Increase for dedicated servers with more resources. |
Timeline Events (Timeline Addon)
These settings appear when the Timeline addon is installed.
| Field | Description |
|---|---|
| Timeline events processing driver | Toggle to configure how contact timeline events are processed. |
When enabled, a dropdown appears:
| Field | Description |
|---|---|
| Timeline events processing driver (dropdown) | Choose how timeline events are processed: Real-Time (immediate, higher resource usage), Laravel-Queue (queued via Laravel's job system), or Write File (batch writes to files, processed later). Real-Time keeps timelines current; the other options reduce server load during high activity. |
Automation Settings (Automations Addon)
These settings appear when the Automations addon is installed.
| Field | Description |
|---|---|
| Automation Status | Master switch for the automation system. When disabled, ALL automations stop executing. |
When enabled, additional options appear:
| Field | Description |
|---|---|
| Automatically resume system-paused Automations | When an automation encounters repeated errors, the system pauses it. Enable this to automatically retry paused automations. |
| Automation waiting pool driver | How contacts waiting for time-delayed actions are stored. Database is reliable and persists through restarts. |
| List selection type when creating an Automation | Toggle to configure how lists are selected when creating automations. |
When List selection type is enabled:
| Field | Description |
|---|---|
| Selection Type | Choose Single List (one list per automation) or Multiple List (select multiple lists). Multiple List is useful for automations that span several lists. |
Logs Tab
Configure logging behavior for troubleshooting and auditing.
Log Settings
| Field | Description |
|---|---|
| Delete user notification logs | Toggle to enable automatic deletion of in-app notification logs (the bell icon notifications). |
When enabled, an input field appears:
| Field | Description |
|---|---|
| Days | Number of days to retain notification logs before automatic deletion. These logs record notifications sent to users - useful for auditing but rarely needed long-term. |
| Field | Description |
|---|---|
| Reporting level | Controls how much detail is written to application logs. Select from the dropdown based on your needs. |
Reporting Level Options
| Level | Description |
|---|---|
| Debug | Logs everything - detailed function calls, variable states. Only use during active troubleshooting as it generates large log files. |
| Error | Logs failures that don't crash the system. Recommended for production - captures problems without excessive noise. |
| Critical | Logs serious failures like database connection issues. |
| Info | Logs normal operations - campaign started, import completed. |
| Notice | Logs significant events that aren't errors. |
| Warning | Logs potential problems - disk space low, rate limits approaching. |
| Alert | Logs events requiring immediate action. |
ESP Callback Logging
| Field | Description |
|---|---|
| Log ESP callbacks to files | Toggle to enable logging of ESP callback data (bounces, complaints, opens, clicks) to separate files. Useful for debugging delivery issues. |
When enabled:
| Field | Description |
|---|---|
| Number of files to keep | Maximum callback log files to retain before older files are deleted. Higher values preserve more history but use more disk space. |
Security Tab
Configure authentication behavior and session management.
Session Settings
| Field | Description |
|---|---|
| Automatically logout idle users | Toggle to enable automatic logout after inactivity. |
When enabled:
| Field | Description |
|---|---|
| Time | Select inactivity duration (in minutes) before automatic logout. Choose based on security requirements - shorter for sensitive environments, longer for convenience. |
| Field | Description |
|---|---|
| Display Remember Me option | Toggle to show or hide the "Remember Me" checkbox on the login page. Hide for shared computers or compliance-sensitive environments. |
Session Storage
| Field | Description |
|---|---|
| Active sessions storage driver | Choose where session data is stored: File-based (fast, but lost on server reboot) or Database (persists through reboots, works with load balancers). |
warning
Changing the driver will log out all currently connected users, including yourself.
Export Security
| Field | Description |
|---|---|
| Delete exported files after | Number of hours before exported files (contact lists, statistics, segments) are automatically deleted. Shorter retention is better for GDPR compliance. Users can always re-export if needed. |
Integrations Tab
Connect Mumara with external services to extend functionality.
Google Analytics
| Field | Description |
|---|---|
| Google Analytics | Toggle to enable or disable Google Analytics tracking within the Mumara interface. |
| Measurement ID | Your Google Analytics 4 Measurement ID (looks like G-XXXXXXXXXX). Found in your GA4 property settings under Data Streams. |
Google Analytics tracks how your team uses Mumara itself - which pages they visit, which features they use. This is NOT for tracking email recipients (that's handled by Mumara's built-in tracking).
Setup:
- Create a GA4 property at analytics.google.com
- Get your Measurement ID from Admin → Data Streams → Web
- Enter it in the Measurement ID field
Use cases:
- Understanding which features your team uses most
- Identifying UX issues (high bounce rates on certain pages)
- Tracking adoption after training
Google reCAPTCHA
| Field | Description |
|---|---|
| Google reCAPTCHA | Toggle to enable reCAPTCHA protection on login and public forms. When enabled, shows the Site Key and Secret Key fields. |
Protects your login page and public web forms from automated attacks (credential stuffing, spam signups).
Versions:
- v2 Checkbox - User clicks "I'm not a robot". Higher friction but clear to users.
- v2 Invisible - Analyzes behavior silently, only shows challenge if suspicious. Better UX.
- v3 - Scores every request 0.0-1.0 without user interaction. You decide threshold. Most seamless but requires tuning.
Setup:
- Go to Google reCAPTCHA Admin
- Register your domain
- Get Site Key (goes in frontend) and Secret Key (stays on server)
- Enter both in the respective fields
Gmail OAuth Email Relay
| Field | Description |
|---|---|
| Gmail OAuth email relay | Toggle to enable Gmail OAuth integration for sending emails through Gmail accounts. |
| Client Secret Credentials | The OAuth 2.0 credentials (Client ID and Client Secret) from your Google Cloud Console project. Used to authenticate users connecting their Gmail accounts as sending nodes. |
Allows users to configure Gmail accounts as sending nodes using OAuth instead of app passwords. More secure and doesn't require users to enable "less secure apps."
Setup Requirements:
- Create a project in Google Cloud Console
- Configure the OAuth consent screen
- Create OAuth 2.0 credentials (Web application type)
- Add authorized redirect URIs pointing to your Mumara installation
- Enter the Client ID and Client Secret here
This is for campaign sending, not system emails. Users configure their individual Gmail accounts per-sending-node after you enable this integration.
Mumara AI (Coming Soon)
| Field | Description |
|---|---|
| AI API Key | API key for Mumara AI-powered features. This integration is coming in a future update. |
Notifications Tab
Controls which system events generate in-app notifications (the bell icon in the top navigation). These are user-facing notifications, not admin alerts. Toggle each notification type on or off based on your users' needs.
Available Notifications
| Field | Description |
|---|---|
| Contact list has been imported | Notifies users when their contact import job completes (success or with errors). Essential for large imports that take time to process. |
| Contact list has been exported | Notifies users when their contact export file is ready for download. |
| Segment has been exported | Notifies users when their segment export completes and is available for download. |
| Segment has been created | Notifies users when a new segment finishes building (useful for complex segments that take time to calculate). |
| Campaign has been scheduled | Notifies users when their broadcast is successfully scheduled for future sending. Confirmation that the scheduling action worked. |
| Scheduled campaign has been started | Notifies users when their scheduled campaign begins sending. Useful for knowing when a future-dated campaign kicks off. |
| Campaign has been finished | Notifies users when their campaign completes (all emails sent or final status reached). Important for knowing when to check statistics. |
| Campaign auto-paused due to the monthly limit reached | Alerts users that their campaign was paused because the monthly sending limit was exceeded. Requires action to resume (wait for limit reset or request increase). |
| Campaign auto-paused due to the daily limit reached | Alerts users that their campaign was paused because the daily sending limit was exceeded. Campaign will auto-resume the next day if Automatically resume auto-paused campaigns is enabled. |
| Campaign system-paused due to the sending node failure | Alerts users that their campaign was paused because the SMTP sending node failed. Requires investigation - check sending node status and credentials. |
| Trigger has been auto-disabled | Alerts users when an automation trigger was automatically disabled due to repeated errors (bad webhook URL, invalid template, etc.). Requires troubleshooting before re-enabling. |
When to Disable Notifications
High-volume senders: Disable Scheduled campaign has been started and Campaign has been finished if you send dozens of campaigns daily - the notification bell becomes useless noise.
Automated workflows: If campaigns are triggered automatically via API or automations (not manually scheduled), Campaign has been scheduled notifications may not be useful.
Self-service platforms: If users manage their own lists, import/export notifications are helpful. If admins do imports for them, users don't need these notifications.
Notifications vs Emails
These are in-app notifications only (visible via the bell icon). For email alerts to administrators about system issues, see the Mail tab's Send system-generated emails to super admins option.
Performance Tab
Controls how tracking data (opens, clicks, bounces) is processed and how long historical data is retained. Critical settings for balancing real-time statistics against server performance.
Tracking Processing
| Field | Description |
|---|---|
| Open Tracking | How email open events are processed. Real-time writes opens to the database immediately - statistics show live data but creates higher server load. Cron queues opens to temporary files and processes them in batches - statistics are delayed by the cron interval but much better performance during high-volume sends. |
| Click Tracking | How link click events are processed. Same options as Open Tracking. Real-time for immediate statistics, Cron for better performance during large campaigns. |
| ESP callback processing method | How bounce notifications, spam complaints, and delivery confirmations from your ESP are processed. Real-time processes callbacks immediately when they arrive. Cron queues them for batch processing. During large sends, your ESP might send thousands of callbacks per minute - cron-based processing prevents database overload. |
When to Use Each Processing Method
Real-time Processing
- Event is written to database immediately
- Statistics dashboards show live data
- Higher server load during active campaigns
- Can cause database bottlenecks during high-volume sends
- Good for: Small-to-medium senders who value live statistics
Cron-based Processing
- Events are written to temporary files
- Cron job periodically imports files to database
- Statistics are delayed by cron interval (typically 1-5 minutes)
- Much lower load during sending - database writes are batched
- Good for: High-volume senders, resource-constrained servers
Data Retention
Old tracking data consumes database space and slows queries. These settings automatically purge data after a specified number of days. Set to 0 to keep data indefinitely (not recommended for high-volume installations).
| Field | Description |
|---|---|
| Delete scheduled campaigns after | Days before completed campaign records and all related data are purged. After deletion, you cannot view statistics for those campaigns. |
| Delete email open data | Days before individual open events (who opened, when, from where) are purged. Aggregate statistics remain but per-recipient detail is lost. |
| Delete link click data | Days before individual click events (who clicked, which link, when) are purged. Aggregate click counts remain but per-recipient detail is lost. |
| Delete email bounce data | Days before individual bounce records are purged. Contact suppression status remains (they stay bounced) but the historical record of when/why is lost. |
| Delete unsubscribe data | Days before individual unsubscribe events are purged. Contact unsubscribe status remains but the historical record of when/why is lost. |
Retention Strategy Recommendations
Aggressive (30-60 days):
- Database stays small and fast
- Queries run quickly
- Good for: High-volume senders, limited server resources
- Trade-off: Limited historical analysis
Moderate (90-180 days):
- Balance of history and performance
- Quarter-over-quarter comparisons possible
- Good for: Most installations
Extended (365+ days):
- Full year-over-year analysis
- Compliance requirements (some industries require 1-3 year retention)
- Requires: Larger database, faster hardware, regular optimization
- Consider: Archiving to separate database instead of keeping in production
tip
Before data is deleted, export any statistics you need for long-term records. Once purged, the data cannot be recovered.
Billing Tab (One Panel addon required)
Addon Required
This tab requires the One Panel addon, which provides WHMCS integration for running Mumara as a commercial email service. This addon is not commercially available and is used for internal Mumara hosting services.
When running Mumara as a commercial email service with WHMCS integration, the credit system lets you charge users based on email volume. This tab controls how credits and billing work.
Credit System Overview
With credits enabled (configured per-package):
- Users are allocated credits (e.g., 10,000 emails/month)
- Each sent email deducts one credit
- When credits reach zero, campaigns pause
- Credits reset on the billing cycle (monthly)
Credit Settings
| Field | Description |
|---|---|
| Negative credit handling | What happens when a user exceeds their credit allocation (if overuse is allowed in their package). Deduct from next allocation subtracts the overage from their next month's credits. Generate invoice creates a separate invoice for the overage amount. See detailed explanation below. |
| Negative credit invoice threshold | Minimum overage amount before generating an invoice. Prevents creating invoices for tiny amounts. Set to 0 to invoice any overage, or a higher value (e.g., $5 or $10) to accumulate small overages before invoicing. |
Negative Credit Handling Options
Users can optionally be allowed to send beyond their credit limit (configured per-package with "Allow overuse"). When they do, their balance goes negative. The Negative credit handling setting controls what happens next:
Deduct from Next Allocation
- User goes -500 credits this month
- Next month they're allocated 10,000 credits
- System deducts 500, leaving them with 9,500
- Simple, automatic, no invoicing needed
- Downside: User gets less than expected, may cause frustration
Generate Invoice
- User goes -500 credits this month
- System generates invoice for 500 credits worth
- Next month they get their full 10,000 allocation
- User pays overage separately
- Requires: Invoice handling infrastructure
- Better for: Professional ESP services with billing departments
Invoice Threshold Examples
| Threshold | Behavior |
|---|---|
| $0 | Invoice for any overage |
| $5 | Overage under $5 rolls to next month |
| $10 | Overage under $10 rolls to next month |
Example: User has $3 overage in January and $4 in February with $5 threshold. January rolls over, February triggers invoice for $7.
Credit-Related Campaign Behavior
When credits are exhausted:
- Active campaigns pause immediately
- User receives notification
- Campaign can resume when credits are added or reset
note
The Automatically resume auto-paused campaigns setting in the Campaigns tab only applies to SMTP connection failures, not credit-based pauses. When a campaign is paused due to insufficient credits, users must manually resume it after credits are replenished, or it will automatically resume at the next billing cycle when credits reset.
Saving Changes
Each tab saves independently - click Save at the bottom of the tab you're editing.
Some settings require additional steps to take effect:
| Setting Type | Action Required |
|---|---|
| Queue driver | Restart Supervisor workers if using Supervisor |
| Session driver | All users logged out immediately |
| Cache-related | Run php artisan cache:clear |
| Cron settings | Wait for next cron cycle |
Next Steps
- Cron Settings - Configure scheduled task intervals
- Branding - Customize application appearance
- API Keys - Manage API access tokens