Server settings, custom domains, and the scheduler

Do it

1. The five stages

   This lesson covers a lot of ground. Do the stages in order — A and D are the most universal; B / C / E are optional depending on what your installation needs:

   Stage A — Tune the Server Settings tab (app name, session timeout, prompt limit, SQL no-locks, bulk-email toggle).

   Stage B — Add a custom domain (optional). DashboardFox returns two CNAME records; add them to your DNS; wait for verification + SSL.

   Stage C — Configure IP Restrictions (optional). Include your own IP. Lockout warning is real.

   Stage D — Configure SMTP / Mail Settings (Settings → Scheduler → Mail Settings). Three modes; test send required before save.

   Stage E — Use the scheduler admin view and decide on bulk email (security tradeoff explained inline).

2. Stage A — Tune the Server Settings tab

   Navigate to Settings → Server Settings. Stay on the first tab (also called Server Settings). The fields worth tuning:

   • Application Name — text shown in the browser tab. Set in branding basics too; the value here is the global default that branding policies can override.
   • Session Timeout — minutes of inactivity before a logged-in user is bounced to the login screen. Defaults to 20. Most teams increase this (60, 120, 480) for daily-driver workflows; security-conscious environments leave it low.
   • Prompt Value Limit — the maximum number of values that can populate a filter dropdown in a report. Default is high (around 10,000). You rarely need to change this; even at 10,000 values the dropdown has a search box so users can find what they need.
   • Enable Bulk Email — global toggle that changes scheduled-report behavior. We'll leave this off for now and demo it in Stage E; the security tradeoff is significant.
   • SQL No Locks — applies WITH (NOLOCK) to queries against your Microsoft SQL connections. Recommended for production MS SQL because it prevents DashboardFox queries from blocking your transactional workload. The tradeoff: queries can read uncommitted (dirty) data, so a report run during a partially-completed transaction might see numbers that don't ultimately commit. For BI reporting that's usually an acceptable tradeoff — but if your reports drive financial close or any other "must be 100% consistent" use case, leave this off.

   Multi-tenant settings live on this tab too — covered in tenant mode (Module 4); ignore them here if you already configured tenant mode.

   Save.

3. Stage B — Add a custom domain (optional)

   By default, your DashboardFox is at yourslug.dashboardfox.app. Custom domains let you replace that with something on your own brand — analytics.acme.com, reports.acme.com, anything you control.

   Click the Custom Domains tab. Click Add Domain (or the equivalent button on your version).

   Enter the fully-qualified domain you want — just the host, no https://, no trailing slash. Submit.

   DashboardFox returns two CNAME records. Both must be added to your DNS at the appropriate provider (Cloudflare, Route 53, GoDaddy, your DNS host). One is the actual subdomain CNAME; the other is a verification record DashboardFox uses to confirm you control the domain.

   Add both records to your DNS. Wait. DashboardFox polls automatically — when DNS propagates, the verification step completes and SSL is provisioned for the domain. Typically minutes; can take up to a few hours depending on your DNS provider's TTL.

   Once active, the domain's status shows as enabled in the Custom Domains list. You can now point login branding at this domain for a per-tenant branded login experience.

   Custom domain capacity

   Each tier includes a number of custom domains. If you need more — agencies and multi-tenant deployments often do — your billing admin can view current capacity and purchase add-on domains in the Billing section. Domains are typically cheaper to add than additional branding policies, and the two often need to be added in pairs (one domain plus one login-branding policy per partner).

4. Stage C — Configure IP Restrictions (optional, with care)

   Click the IP Restrictions tab. You'll see your current connecting IP displayed prominently at the top.

   ⚠️ Read this before you click anything

   IP restrictions take effect immediately. If you save a configuration that doesn't include your own IP, you will be locked out of your DashboardFox instance on your next page load. There is no "are you sure?" confirmation.

   Before saving, verify: your own current IP is on the list. Any other admin's IP is on the list. Mobile / VPN / home IPs for legitimate users are on the list. If anyone connects through a dynamic IP, they'll need a static IP or VPN with a fixed exit point first.

   If you do lock yourself out: log in at my.dashboardfox.app with your admin credentials. From there you can manage IP restrictions and disable the entries that caused the lockout.

   Once you've planned the IPs and ranges:

   • Click to add a single IP — the simplest case. DashboardFox makes it one click to add the IP you're currently connecting from.
   • Add a CIDR range (e.g., 192.168.1.0/24) if you want to allow a whole subnet — typical for corporate office networks.
   • Add as many entries as you need. Save.

   To turn off IP restrictions entirely, remove all entries (or use the disable toggle in the same tab). Both immediately restore unrestricted access.

5. Stage D — Configure SMTP / Mail Settings

   Navigate to Settings → Scheduler → Mail Settings. You'll see three cards corresponding to three modes, with the currently-active mode marked.

   • Default Gateway — DashboardFox's shared mail infrastructure. Mail goes out from reports@mail.dashboardfox.app. Works out of the box, requires no setup. Use this if you don't need branded sender addresses.
   • Custom SMTP — your own mail server. Mail goes out from your own domain. Best for branded experiences and deliverability control. Requires SMTP credentials and a successful test send before save.
   • Disabled — no outbound email at all. Scheduled reports won't deliver. Useful if you want to silence all scheduling without changing branding policies (though hiding the Schedule action via branding is usually a better long-term answer — see branding basics).

   Setting up Custom SMTP

   Click the Custom SMTP card. The fields:

   • SMTP Host — your mail server hostname (e.g., smtp.yourdomain.com).
   • Port — typically 587 for TLS / STARTTLS or 465 for SSL. 587 is the modern standard.
   • From Address — the sender shown on outgoing mail. Often something like reports@yourdomain.com or no-reply@yourdomain.com.
   • Username — your SMTP account username (usually but not always the same as From Address — SendGrid is a notable exception, see below).
   • Password and Confirm Password — your SMTP password. Re-entered every time you save, even on subsequent edits, since DashboardFox doesn't return passwords from the server.
   • Use TLS / Enable SSL — match what your mail server requires. With port 587, TLS is the typical answer; with 465, SSL.

   Test send is required before save

   Enter a recipient address in the Send test to field and click Send Test. The Save SMTP Settings button only activates after a successful test. If the test fails, DashboardFox shows the error returned by your mail server — usually clear enough to diagnose. If you mis-configure and stop receiving emails later, switch back to the Default Gateway as a fallback while you debug.

   The provider accordions below cover the three most common SMTP services with their specific gotchas:

   Gmail / Google Workspace SMTP

   The settings:

   • SMTP Host — smtp.gmail.com
   • Port — 587 with TLS (or 465 with SSL)
   • From Address — your full Gmail address (e.g., you@yourdomain.com for Workspace, or you@gmail.com for free Gmail)
   • Username — same as From Address
   • Password — App Password, not your regular Google password (see below)
   • Use TLS — yes (with port 587)

   You need an App Password, not your regular password

   Google effectively requires 2-Step Verification on all accounts, and 2FA-enabled accounts cannot use their regular password for SMTP. Generate a 16-character App Password instead.

   How to generate: Go to your Google Account → Security → 2-Step Verification (enable it if not already on) → App Passwords. Create a new app password named something like "DashboardFox SMTP". Google shows the 16-character password once — copy it immediately. Paste that into the Password field in DashboardFox, not your regular Google password.

   Sending limits: ~500 emails/day for free Gmail, ~2,000/day for Google Workspace. Per-recipient, not per-message. If you have scheduled reports going to large distribution lists, you'll hit this.

   Office 365 / Microsoft 365 SMTP

   The settings:

   • SMTP Host — smtp.office365.com
   • Port — 587 with STARTTLS
   • From Address — the licensed mailbox you're sending from
   • Username — same as From Address (full email)
   • Password — the mailbox password, or an App Password if MFA is enabled
   • Use TLS — yes

   SMTP AUTH must be enabled on the mailbox

   Microsoft disables Authenticated SMTP per-mailbox by default for new tenants. If your test send fails with "5.7.57 Client not authenticated", your Microsoft tenant admin needs to enable SMTP AUTH on this specific mailbox via the Exchange admin center or PowerShell. This is the single most common Office 365 SMTP failure in DashboardFox.

   If MFA is enabled on the mailbox, you'll also need an App Password — generate one in the user's My Account → Security info → App passwords.

   Basic Auth is being deprecated

   Microsoft is in the process of retiring Basic Authentication for SMTP submission. The exact deprecation date has shifted but enforcement is expected by late 2026. If your scheduled reports start failing in 2026/2027, this is the likely cause. Email team@dashboardfox.com when that happens — DashboardFox will adapt as Microsoft's authentication path stabilizes.

   Sending limits: 10,000 recipients/day per mailbox, throttled at 30 messages/minute.

   SendGrid SMTP relay

   The settings:

   • SMTP Host — smtp.sendgrid.net
   • Port — 587 with TLS (or 465 with SSL, or 2525 if your network blocks 587)
   • From Address — any address you've verified in SendGrid (Single Sender Verification or full Domain Authentication)
   • Username — the literal string apikey — not your SendGrid account email. This is the most common SendGrid mistake.
   • Password — your SendGrid API key, starting with SG.
   • Use TLS — yes

   Generating the API key

   In SendGrid, go to Settings → API Keys → Create API Key. Choose Restricted Access and grant only Mail Send permission (principle of least privilege). Copy the generated key immediately — SendGrid only shows it once. Paste into the DashboardFox Password field.

   Before sending, also verify your sender identity in SendGrid (Settings → Sender Authentication) — either Single Sender Verification (one address) or Domain Authentication (the whole domain). Without this step, sends will be rejected.

   Sending limits: SendGrid's free tier is 100 emails/day forever; paid tiers scale into the millions.

   Other / generic SMTP server

   For any other SMTP provider (Mailgun, Postmark, Amazon SES via SMTP, a corporate Exchange server, etc.), the basic shape is the same:

   • SMTP Host — the hostname your provider gives you
   • Port — almost always 587 for TLS, occasionally 465 for SSL
   • From Address — must be a sender address the provider authorizes you to use
   • Username + Password — the provider's SMTP credentials (sometimes the same as your account; sometimes a separate SMTP-only credential)
   • Use TLS — yes, unless your provider explicitly says otherwise

   One general note: this configuration uses the SMTP protocol only. API-based mail providers (Mailgun's HTTP API, Postmark's HTTP API, SendGrid's Web API) require a different integration that DashboardFox doesn't currently offer here — for those services, look for the provider's SMTP relay credentials, which they typically offer alongside their HTTP API.

   When the test send fails, the error message from your provider's server is shown directly in DashboardFox. Most failures fall into one of: wrong port (try 465 if 587 fails), TLS/SSL mismatch, sender address not authorized, or credentials wrong. Read the error verbatim — it's usually specific.

6. Stage E — Use the scheduler admin view + decide on bulk email

   Navigate to Settings → Scheduler. The first sub-tab shows the admin view — every scheduled report across every user in your instance, who owns it, when it runs, and what its recipient list looks like.

   Two common things to do here:

   • Audit scheduled volume — get a sense of how much email DashboardFox is sending, and to whom.
   • Transfer ownership — when an employee leaves, their scheduled reports don't automatically migrate. Use this view to reassign ownership so the reports keep running.

   The bulk-email toggle

   Back in Stage A you saw the Enable Bulk Email toggle on the Server Settings tab. Now's the moment to decide which mode you want. The two behave very differently:

   	Bulk Email OFF (default)	Bulk Email ON
   Recipient picker	Check boxes from the existing user list only.	Free-form type any email address (semicolon-separated, no spaces). User-list option still works too.
   Security context of the report	Runs in each recipient's security context. Row-level security, tenant mode, profile tags — all respected per recipient. Different recipients can see different data from the same scheduled report.	Runs in the sender's security context. Every recipient sees identical data — whatever the sender's account would see, regardless of who the recipient is.
   When to use	Internal-only distribution where row-level security matters. Safer default.	External recipients without user accounts, broad distribution lists, marketing-style emails. Convenient — and the more common request — but read the security implications below carefully.

   ⚠️ Bulk email security tradeoff

   When bulk email is ON, scheduled reports run as the sender — meaning if a senior analyst with access to all-customer data schedules a report to external@customer.com, the customer receives a report containing all customers' data, not just their own.

   Mitigation: Reports intended for bulk external distribution should be built with hardcoded filters (much like guest reports), so the data is safe to expose regardless of who runs it. Don't rely on row-level security to scope bulk-emailed reports — RLS doesn't apply when the report runs as the sender.

   If you need both modes for different groups, use branding policies to hide the Schedule feature for groups that shouldn't have bulk-email capability, while still leaving the global toggle on.

   Turning on bulk email

   Go back to Settings → Server Settings, toggle Enable Bulk Email on, save. Users (including you) must log out and log back in for the change to take effect.

   Then test by signing in as a non-admin user, opening a report, and scheduling it. You should see a new free-form email field in addition to the check-from-user-list option. Type any email address into the free-form field, save the schedule, and verify the recipient receives the report.