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 noreply@gmail.com.
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 userid-random-random@return.mydomain.com - 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:

1. Create a GA4 property at analytics.google.com
2. Get your Measurement ID from Admin → Data Streams → Web
3. 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:

1. Go to Google reCAPTCHA Admin
2. Register your domain
3. Get Site Key (goes in frontend) and Secret Key (stays on server)
4. 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:

1. Create a project in Google Cloud Console
2. Configure the OAuth consent screen
3. Create OAuth 2.0 credentials (Web application type)
4. Add authorized redirect URIs pointing to your Mumara installation
5. 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):

1. Users are allocated credits (e.g., 10,000 emails/month)
2. Each sent email deducts one credit
3. When credits reach zero, campaigns pause
4. 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:

1. Active campaigns pause immediately
2. User receives notification
3. 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