Sender Identities

Every marketing email in Gordon CRM must be sent from a verified sender identity. This is an email address on a subdomain you control, verified via DNS records.

How Sender Identities Work

A sender identity consists of:

Subdomain Sending

Gordon CRM uses a subdomain isolation architecture. When you add your domain, the system automatically derives a sending subdomain:

You enter:        acme.com
System registers: mail.acme.com  (with Resend)
Default email:    hello@mail.acme.com
Default reply-to: hello@acme.com

This separation provides several benefits:

• Reputation isolation — Your sending subdomain (mail.acme.com) builds its own email reputation independently from your root domain
• Reply routing — The Reply-To header points to your root domain, so recipients reply to a familiar address instead of the sending subdomain
• Clean DNS — Sending-related DNS records (DKIM, SPF) live on the mail subdomain and don't conflict with your root domain's existing DNS configuration

One Domain Per Workspace

Each workspace can have one sending domain. This constraint ensures consistent sender identity across all emails from a workspace. If you need to change your domain, the existing identity must be removed first.

Reply-To Configuration

The Reply-To address is editable from Settings → Sender Identities → Edit Details. It defaults to hello@yourdomain.com (root domain) but can be changed to any address you control.

Workspace vs. Platform Identities

Gordon CRM supports two tiers of sender identities:

Workspace Sender Identities

• Created and managed by workspace owners/admins under Settings → Sender Identities
• Scoped to a single workspace
• Must be DNS-verified before they can be used to send emails
• Support both marketing and transactional email categories

Platform Sender Identities

• Managed by super admins at the platform level
• Used for system emails only (verification emails, password resets, workspace invitations)
• Not used as a fallback for marketing emails — this protects the platform domain's sender reputation
• Tracking is always disabled on platform domains (openTracking: false, clickTracking: false) — system emails contain no tracking pixels, no wrapped links, and no unsubscribe headers

Sender Resolution Order

When the campaign or broadcast sweeper needs to send an email, it resolves the sender in this order:

1. Step/Broadcast-specific sender — If the campaign step or broadcast has a sender_identity_id set, use that verified identity.
2. Workspace default — Query the workspace's verified sender identities and use the first one found (ordered by creation date).
3. Fallback sender — If no workspace sender identity exists, the system generates a virtual sender address using the workspace name and a dedicated fallback domain.
4. Fail — If no fallback domain is configured in the environment, the enrollment is marked as failed (campaigns) or the broadcast is marked as failed.

At every tier, the resolution queries use the sender's id and dns_verified status — not the domain text. This ensures the sender remains continuously resolvable regardless of domain configuration changes.

How the Fallback Sender Works

When a workspace doesn't have its own verified sender identity, Gordon CRM constructs a virtual email address:

{slugified-workspace-name}-{short-id}@{FALLBACK_SENDER_DOMAIN}

Example: A workspace named "John's Team" with ID a1b2c3d4-... would generate:

johnsteam-a1b2c3d4@mail.gordoncrm.com

The fallback sender also:

• Sets the From Name to the workspace's display name (e.g., "John's Team")
• Sets the Reply-To header to the workspace owner's email address, so replies go to a real inbox

Why not the platform sender? Marketing emails are intentionally isolated from the platform's transactional domain. This ensures that a workspace's bulk email activity never harms the deliverability of system-critical emails like password resets and verification links.

Fallback Tracking

The fallback sender has no tracking_subdomain in the database. For tracking, the system falls back to the FALLBACK_TRACKING_DOMAIN environment variable. If set, fallback senders follow the same tracking precedence matrix as custom-domain senders — marketing emails can be tracked via the fallback tracking domain, and transactional emails always have tracking disabled.

If FALLBACK_TRACKING_DOMAIN is not configured, tracking is silently disabled for fallback senders.

DNS Verification

To verify a sending domain, you need to add DNS records (typically DKIM and SPF) to your domain's DNS settings. The exact records are provided by Gordon CRM when you add a new sender identity.

Once the records propagate and are confirmed, the dns_verified flag is set to true and the identity becomes available for sending. Upon verification, Resend's built-in tracking is automatically disabled on the domain — Gordon CRM handles click and open tracking through its own first-party tracking engine.

⚠️ Important: Only DNS-verified sender identities can be used to send emails. Unverified identities are stored but cannot be selected for campaigns or broadcasts.

Tracking Subdomain DNS

In addition to the sending domain records, each sender identity has a tracking subdomain that requires its own CNAME record. This enables branded click and open tracking URLs (e.g., links.yourdomain.com/api/c/...).

The tracking subdomain is automatically registered with Vercel when you add your domain. The required CNAME target is dynamically fetched from the Vercel API — it is a project-specific value unique to your domain.

When you view your DNS records in Settings → Sender Identities → DNS Records, the tracking CNAME record is displayed alongside your sending domain records with the correct target value.

If the Vercel API is temporarily unavailable, the DNS dialog falls back to showing cname.vercel-dns.com as the CNAME target. Vercel handles SSL certificate provisioning automatically once the CNAME record propagates.

See Tracking & Analytics for full details on the tracking engine.