Sign in Subscribe
Digital Presence & Online Policies

Why Subdomains Matter for Modern Law Firms

Promise Legal Staff

• 5 min read
Isometric domain hub: copper node with orbiting app tiles, shielded subdomains, cyan links.
Loading the Elevenlabs Text to Speech AudioNative Player...

Why subdomains matter for modern law firms

A subdomain is a prefix added to your firm’s main domain (for example, portal.yourfirm.com) that points to a separate website or application. For law firms, subdomains are more than “nice organization.” Done well, they improve client experience (clear destinations, faster access to tools) and strengthen risk management (separating public marketing pages from systems that handle confidential data).

Common real-world patterns include:

  • portal.yourfirm.com for a client portal (documents, messages, intake status).
  • ai.yourfirm.com for an internal or client-facing AI assistant with strict access controls.
  • cases.yourfirm.com for matter dashboards, task lists, or case-status updates.

This guide is written for law firm owners, admins, and ops-minded lawyers who want a practical, repeatable way to stand up subdomains using Cloudflare and a DigitalOcean Droplet — without accidentally breaking email, misrouting DNS, or exposing sensitive data. By the end, you’ll be able to plan subdomains, point DNS correctly, deploy a basic server safely, and establish simple governance so subdomains don’t turn into “shadow IT.”

Important: a subdomain is still your responsibility. If any subdomain will store or transmit client confidences, credentials, or personal data, involve IT/security early, use least-privilege access, and treat configuration changes like production work. For step-by-step setup context, see How to Set Up a Subdomain Using Cloudflare and a Digital Ocean Droplet for Lawyers.

At a Glance: TL;DR setup checklist for law firm subdomains

  • Plan the subdomain: define the purpose (client portal vs. marketing), whether it’s public or authenticated, and what data it will touch (client documents, PII, payments). Assign an owner.
  • Create/confirm your Cloudflare setup: ensure the firm controls the Cloudflare account and has MFA enabled; document who can change DNS and SSL settings.
  • Move DNS to Cloudflare (full setup): add the domain, review imported DNS records carefully, then update your registrar to use Cloudflare nameservers (this makes Cloudflare your authoritative DNS). Pay special attention to email records (MX/SPF/DKIM/DMARC) so mail doesn’t break.
  • Provision a DigitalOcean Droplet: choose a region close to clients/staff, select an LTS OS image, and attach SSH keys (avoid password-only access).
  • Harden the server before going live: create a non-root user, disable root SSH login, restrict inbound ports (typically 22, 80, 443), enable automatic security updates, and turn on backups/snapshots.
  • Create DNS records for the subdomain: add an A (or CNAME) record for portal, ai, etc.; decide whether to proxy through Cloudflare (often beneficial for client-facing apps).
  • Enable HTTPS end-to-end: install TLS on the Droplet (e.g., Let’s Encrypt) and confirm Cloudflare SSL mode is configured correctly for your origin.
  • Test + govern: verify DNS propagation, HTTPS, logins, and permissions; keep an inventory of subdomains, rotate credentials, patch monthly, and require change review for anything handling sensitive data.

If you want the full walkthrough behind this checklist, see How to Set Up a Subdomain Using Cloudflare and a Digital Ocean Droplet for Lawyers.

Choose subdomain use cases that actually help clients

Start with subdomains that reduce friction for clients and reduce risk for the firm. The best early wins are “single-purpose” destinations clients can understand instantly and staff can administer consistently.

  • portal.yourfirm.com (client portal): Authenticated. Data: messages, documents, invoices, PII. Owner: ops/IT + a practice lead. Goal: reduce email attachments and missed updates.
  • status.yourfirm.com (case-status page): typically Authenticated (or public for firmwide outage notices). Data: milestone summaries, next steps, deadlines (avoid privileged narrative). Owner: intake/CS team.
  • ai.yourfirm.com (AI assistant): Authenticated, often internal-first. Data: prompts/outputs, possibly client facts; set rules for what may be entered. Owner: knowledge management + security.
  • forms.yourfirm.com (secure intake/forms): usually Public entry with secure submission. Data: leads, incident details, uploads. Owner: intake manager + marketing (with security review).
  • automations.yourfirm.com (workflows/webhooks): Authenticated/service-to-service. Data: integration payloads, tokens, logs. Owner: IT/engineering; treat as high-sensitivity.

Mini scenario: a new personal-injury client is told “go to forms.yourfirm.com to upload photos and sign authorizations.” The submission routes into the matter workspace, and the client receives updates via portal.yourfirm.com instead of email.

  • Success metrics: faster intake completion, fewer missing documents, fewer staff follow-ups, higher client satisfaction.
  • Common risks: making a sensitive subdomain public by mistake, logging confidential data, weak access controls, and unclear ownership (no one patches it).

If you’re building anything AI-related, also review your vendor and data-use posture so prompts/outputs aren’t reused in ways you didn’t intend; see AI Terms of Service Contracts.

Prepare your domain and Cloudflare account

Before you point any subdomain at a new server, make sure your domain’s DNS is controlled, auditable, and unlikely to break email. Cloudflare is a common choice because it centralizes DNS and adds security controls that are helpful for client-facing legal tools.

  • Inventory what already depends on DNS: website host, email provider, practice apps, verification records, and any existing subdomains. Export current DNS zone records from your existing DNS provider (or take screenshots) so you have a rollback reference.
  • Add the domain to Cloudflare: create the Cloudflare account under firm ownership (not a vendor’s personal login), enable MFA, and add your apex domain (yourfirm.com). Cloudflare will attempt to import existing DNS records — review them line-by-line.
  • Verify email records before switching nameservers: confirm your MX records match your email provider. Also confirm SPF (TXT), DKIM (TXT/CNAME), and DMARC (TXT at _dmarc) are present. Missing mail-auth records can cause deliverability issues even if mail “still works.”
  • Switch nameservers carefully: at your registrar, replace the existing nameservers with Cloudflare’s nameservers. Plan the cutover during a low-risk window and keep the prior DNS provider active until Cloudflare shows the domain as active and traffic/email are verified.

Proxy mode (orange cloud) in Cloudflare: when enabled for a subdomain, Cloudflare sits in front of your origin server. This can hide your server’s IP, absorb basic DDoS/noise traffic, and let you use WAF/rate limiting — often a good default for public client-facing subdomains. For service-to-service tools (webhooks, APIs), you may prefer DNS-only to avoid unexpected proxy behavior.

For a related walkthrough focused on lawyer use cases, see How to Set Up a Subdomain Using Cloudflare and a Digital Ocean Droplet for Lawyers.

Set up and harden a DigitalOcean Droplet for law-firm use

For most small firm apps (a portal, forms intake, or a status dashboard), start simple: choose a current Ubuntu LTS image, pick a region near your users, and size conservatively (often 1–2 vCPU / 2–4GB RAM) with an easy path to scale up later.

  • Create the Droplet securely: add SSH keys at creation (avoid password-only login) and enable monitoring/backups if available.
  • Create a non-root admin user and lock down SSH: adduser deploy, usermod -aG sudo deploy, then in /etc/ssh/sshd_config set PermitRootLogin no and consider disabling password auth.
  • Firewall: allow only what you need (typically 22, 80, 443). On Ubuntu, UFW is the common baseline: ufw allow OpenSSH, ufw allow 80,443/tcp, ufw enable.
  • Automatic security updates: enable unattended security updates (Ubuntu’s unattended-upgrades) so critical patches aren’t missed.
  • Backups: turn on provider backups/snapshots and test a restore path before you rely on it.

Nginx skeleton (example for portal.yourfirm.com): create /etc/nginx/sites-available/portal with a server block and proxy to your app:

  • server_name portal.yourfirm.com;
  • location / { proxy_pass http://127.0.0.1:3000; }
  • Enable it: ln -s /etc/nginx/sites-available/portal /etc/nginx/sites-enabled/ then nginx -t and systemctl reload nginx.

Mini scenario: a rushed setup leaves SSH open with password login and an app binds directly to the public internet on port 3000 — exposing an unauthenticated admin panel. The steps above reduce that risk by removing root access, requiring keys, limiting inbound ports, and placing Nginx in front as the single controlled entry point.

For the full end-to-end walkthrough (Cloudflare + Droplet), see How to Set Up a Subdomain Using Cloudflare and a Digital Ocean Droplet for Lawyers.