White-Label Customization Guide for AcelleMail

What this is for#

AcelleMail's Extended License allows full re-branding — every "AcelleMail" reference can be replaced with your brand name, every screen recoloured, every customer email sent from your domain. The Regular License doesn't allow this.

This guide walks every customisation point in the order you'd typically apply them, ending with the upgrade-safe pattern for deeper Blade/CSS overrides.

Before you start: make a clone of your install (rsync to a staging server) and run customisations against the clone first. Some changes are subtle enough that you'll want to compare side-by-side with the original to confirm nothing broke.

Prerequisite: the SaaS setup guide is the typical context for white-labelling. You can also white-label a single-tenant install if you want a custom internal tool.

Step 1 — Branding settings (covers ~80% of the work)#

These four settings cascade to every screen + every system email:

In Admin → Settings → General → Branding:

Save → reload the admin to confirm. Then log in as a test customer to verify the customer-facing screens picked up the changes (some are cached for 5 min).

Logo tips:

• Use SVG when possible — scales perfectly at every resolution.
• For PNG, export at 2× the displayed size (e.g. 400×120 for a 200×60 slot) to look crisp on retina displays.
• Light variant: needed if your primary logo is a dark color and your email templates use a dark header.
• Test the favicon at small size — letterforms that look fine at 200px can be illegible at 32×32.

Step 2 — System emails (transactional)#

The system-email templates control what your customers see when AcelleMail sends them welcome / password-reset / verification / billing emails. These are seen by every paying customer in their first 5 minutes — they're the highest-leverage white-label work.

In Admin → System Emails:

For each template:

• Subject line: write in your brand voice; mention your app name explicitly
• Body: use the WYSIWYG to set header logo + footer
• Test by sending to yourself. Most issues are visible only in the rendered email, not the editor preview.

The system emails support these merge tags (insert at appropriate spots):

{NAME}              — customer's name
{EMAIL}             — customer's email
{APP_NAME}          — your branded app name (from Step 1)
{ADMIN_EMAIL}       — your admin email
{LOGIN_URL}         — link to login page
{VERIFICATION_URL}  — for the verification email
{RESET_URL}         — for the password-reset email
{PLAN_NAME}         — current plan name
{CANCEL_URL}        — link to cancel subscription

Step 3 — Custom domain (per-tenant or app-wide)#

There are two distinct custom-domain features in AcelleMail. Don't mix them up:

3a. Your white-label app domain (you operate)#

Your SaaS app should live on your domain, not app.acellemail.com. If you've followed the Ubuntu install guide, your domain is already configured (the server_name in the nginx vhost). Verify it shows correctly in every email — Acelle uses APP_URL from .env for absolute links:

grep -E '^APP_URL' /var/www/acellemail/.env
# Should show: APP_URL=https://your-brand.com

If wrong, edit it and run php artisan config:clear.

3b. Per-customer custom domain (their customers)#

Each paying customer can set up their own custom tracking domain (e.g. click.theircompany.com) — so tracking links in their campaigns show their brand, not yours. Enabled per plan via the custom_domain_enabled option (see SaaS setup Step 3).

The customer-facing flow:

1. Customer enters their desired subdomain in Settings → Custom Tracking Domain
2. AcelleMail tells them: "Add a CNAME from click.theircompany.com to track.your-brand.com"
3. Customer does it at their DNS provider; clicks Verify
4. AcelleMail attempts to provision a Let's Encrypt TLS cert (auto, via certbot)
5. On success, their campaign tracking links use click.theircompany.com

Operational caveats:

• Let's Encrypt rate-limits — at scale (100s of new custom domains/day) you may need a DNS-challenge setup or a wildcard. For Pro tier, single-domain HTTP-challenge is usually fine.
• If certbot fails (DNS not propagated, port 80 blocked), the customer sees a "Verifying..." spinner indefinitely. Add a status page or admin notification for this.

Step 4 — Custom CSS (visual polish beyond Branding)#

The Branding settings cover most visual customisation, but Acelle's Blade templates also support a custom CSS file for finer control.

Drop a custom.css file in /var/www/acellemail/public/css/custom.css. AcelleMail automatically loads it on every page (search app.blade.php for the <link> include). Target Acelle's existing classes:

/* Tighter navbar */
.navbar-main { padding: 8px 16px; }

/* Custom button shape */
.btn-primary { border-radius: 24px; }

/* Hide "Powered by AcelleMail" text in footer (Extended License only) */
.app-footer .powered-by { display: none; }

/* Email preview header — match your brand */
.email-preview-header { background: linear-gradient(135deg, #0066CC, #6633CC); }

After editing, hard-refresh the admin (Ctrl+Shift+R / Cmd+Shift+R) to bypass browser cache.

For email-template CSS (different from app CSS), edit the system-email templates directly in Admin → System Emails — inline styles per the email-rendering rules in Understanding Email Client Rendering Differences.

Step 5 — Upgrade-safe Blade overrides#

When the Branding settings + custom.css + system-email templates aren't enough, you can override Acelle's Blade views. The trick is doing it in a way that survives patch-x.x.x.bin upgrades.

Wrong way (will get overwritten by every upgrade):

# Don't do this:
vi /var/www/acellemail/resources/views/auth/login.blade.php

Right way — publish to a vendor-specific override directory:

mkdir -p /var/www/acellemail/resources/views/vendor/overrides
# Copy the file you want to override
cp /var/www/acellemail/resources/views/auth/login.blade.php \
   /var/www/acellemail/resources/views/vendor/overrides/auth-login.blade.php
# Edit the copy
vi /var/www/acellemail/resources/views/vendor/overrides/auth-login.blade.php

Then in your custom AppServiceProvider (or by patching the views finder), tell Laravel to look at the overrides directory first:

// In a custom service provider's boot()
$this->loadViewsFrom(
    resource_path('views/vendor/overrides'),
    'overrides'
);

// And then in routes/web.php (or a router override), point the login route at:
Route::get('/login', fn () => view('overrides::auth-login'));

Document every override in a OVERRIDES.md file at the repo root:

- /resources/views/vendor/overrides/auth-login.blade.php
  - Replaces /resources/views/auth/login.blade.php
  - Changes: removed "AcelleMail" wordmark, added custom social-proof block
  - Last reviewed against Acelle vN.N.N: 2026-05-16

When AcelleMail releases a new version, diff auth/login.blade.php against your override and re-apply any structural changes. Painful but unavoidable for deep customisations.

Step 6 — Removing "Powered by AcelleMail" mentions#

Under the Extended License, you can remove every reference. The places to check:

• ✅ App footer — Branding setting (Step 1)
• ✅ Email footer — Branding setting (Step 1) + System Email templates (Step 2)
• ✅ Page titles — Branding's App Name
• ⚠️ HTML <meta name="generator"> — search resources/views/layouts/app.blade.php
• ⚠️ Email X-Mailer header — search config/mail.php and app/Library/Mailer/
• ⚠️ .htaccess / robots.txt comments — search for "AcelleMail"
• ⚠️ Any inline help links pointing to acellemail.com/docs — replace with your own KB

The ⚠️ items aren't user-visible to your customers but show up in source-view / email-headers / WHOIS-style checks. Audit twice if you're competing with AcelleMail-flavoured competitors.

# Quick audit grep:
sudo grep -rEi "acelle[a-z]*\\.com|powered.by.acelle" /var/www/acellemail/{resources,config,public,app} \
  | grep -v '/vendor/' | head -40

Step 7 — Browser tests#

After all of the above, run through this checklist:

• Open an incognito window → does the login page show your brand only?
• Sign up as a test customer → does the welcome email look like it came from your company?
• Verify the email → does the verification email look right?
• Log in → does the dashboard navbar / footer / colors all match?
• Trigger a password reset → does the reset email look right?
• Cancel the test subscription → does the cancellation email look right?
• View page source on dashboard → search for "acelle" — nothing should appear in user-visible text
• View email headers — X-Mailer should not say AcelleMail

Common issues#

FAQ#

Can I sell AcelleMail-derived code (not the SaaS) under my own license? No. The Extended License lets you operate AcelleMail as a SaaS under your brand — it does not grant redistribution rights for the source code. If a customer wants on-prem, they buy their own AcelleMail license.

Can I remove the AcelleMail footer entirely? Yes — per the Extended License terms. The Regular License requires a "Powered by AcelleMail" link in the footer.

What about the Acelle logo in marketing emails sent via my SaaS? Customer-facing marketing emails (campaigns your customers send to their subscribers) don't have any AcelleMail branding by default — they're rendered from the customer's chosen template. No action needed unless the customer's template references AcelleMail.

How do I theme dark mode? AcelleMail's admin has a dark-mode toggle. Custom CSS can target .theme-dark .your-class for dark-mode-only rules. The Logo Light setting (Step 1) is for the dark theme.

Can I use a Tailwind-style design system? Yes via the custom.css route — but be aware that AcelleMail's existing Blade markup uses Bootstrap-flavoured class names. You'll either layer Tailwind alongside (cohabitation is fine) or replace existing classes via Blade overrides (Step 5). For most SaaS operators, the cohabitation route is enough.

What about right-to-left (RTL) language support? AcelleMail's UI has RTL support built-in. Set the language in Admin → Languages, and the layout flips. Custom CSS may need [dir="rtl"] selectors for any layout tweaks you've added.

How often does the underlying AcelleMail UI change? Minor (point) releases rarely touch user-visible HTML; major releases (e.g. v4 → v5) may. Plan to re-test your white-label after every major upgrade — budget 2–4 hours.

Multi-brand from a single install? Acelle doesn't natively support per-tenant theming (only per-customer custom domain). For multi-brand SaaS (you run two separate brands off one install), you'll need either separate AcelleMail installs (cleaner) or a Blade override that switches branding based on the requesting hostname (hacky, harder to upgrade).

Related articles#

• Setting Up AcelleMail as a SaaS Platform — the technical SaaS setup (white-labelling sits inside this)
• Building Your Email Marketing SaaS — GTM / pricing context
• Install AcelleMail on Ubuntu 24.04 LTS — your APP_URL is set here
• Understanding Email Client Rendering Differences — how the system-email templates will render across clients
• Configuring Amazon SES with AcelleMail — for system-email sending
• Post-Install Hardening Checklist — applies to white-labelled installs too
• GDPR Compliance Guide for Email Marketing — required reading
• Email Preheader Text — The Hidden Conversion Booster — for the customer-facing system emails