Connect your domain.
Understand every record.

Know what each connection does.

01 / Prepare the domain.

1. Confirm access to the authoritative DNS provider. Your registrar and DNS host may be different.
2. Export or record the current MX, TXT, and CNAME entries. Identify every service sending mail for the domain.
3. Use your provider’s domain verification record and confirm domain ownership in its admin console.
4. Keep the existing provider MX records for incoming replies. Do not point MX at a tracking hostname or replace working mail routing when connecting an outreach application.

DNS name fields vary. Some providers accept @ for the domain root and append the domain to a short name automatically. Avoid entering the domain twice.

02 / Set up Google Workspace.

1. Confirm Gmail is active for the domain and your Google-provided MX records are configured.
2. Review the existing SPF record. If Google Workspace is your only sending service, the example below authorizes Google. If you use other senders, merge their required mechanisms into one SPF record instead.
3. In Google Admin, open Apps → Google Workspace → Gmail → Authenticate email. Select the domain and generate a 2048-bit DKIM key where supported.
4. Add the exact TXT hostname and public key Google supplies. Return to Google Admin and start authentication after DNS resolves.
5. Send a test message to a separate mailbox and inspect its authentication results.

v=spf1 include:_spf.google.com ~all

Use Google’s own DKIM key for Google-managed signing. A private key from the public generator cannot replace Google’s managed key configuration.

03 / Set up Microsoft 365.

1. Verify the custom domain in Microsoft 365 and retain the tenant’s exact MX destination.
2. Review the current SPF record. The example below applies when Microsoft 365 is the only sending service in a standard commercial tenant; confirm the policy for your environment.
3. In Microsoft Defender’s email authentication settings, select the domain and copy both assigned DKIM CNAME targets.
4. Create CNAME records named selector1._domainkey and selector2._domainkey. Use the exact tenant-specific targets shown in Defender; do not construct them from an example domain.
5. For Cloudflare DNS, keep DKIM CNAMEs DNS only. Verify both aliases, enable signing in Defender, and test a message.

v=spf1 include:spf.protection.outlook.com -all

Microsoft manages its DKIM private keys and rotation. Its two CNAME destinations are specific to your tenant and domain.

04 / Review DMARC before enforcement.

First confirm SPF or DKIM passes and aligns with the visible From domain for each legitimate sending service. A monitoring policy is a starting point for reviewing results; it does not request quarantine or rejection.

v=DMARC1; p=none;

Keep one DMARC record at the policy hostname. Review legitimate sending sources before changing an existing policy or moving to quarantine or reject. Do not weaken an established enforcement policy just to match this example.

05 / Connect sending and incoming replies.

1. Connect the mailbox through the account connection flow. For Google or Microsoft, review the OAuth permissions and choose the correct work account.
2. For a provider that uses IMAP and SMTP, obtain the exact server names, ports, and TLS requirements from that provider. Use its approved app-password or authorization method.
3. Test an outgoing message and reply to it from a separate mailbox. Confirm the original mailbox receives the reply and the connected application synchronizes it into the correct thread.
4. Verify replies and opt-outs stop follow-ups. Check connection recovery and revoke unused mailbox access from the provider’s security settings.

SPF, DKIM, and DMARC do not let an application read your mail. MX routes incoming messages; the authorized mailbox connection handles reply synchronization. Never put passwords, OAuth tokens, or private keys in DNS.

06 / Configure a custom tracking hostname.

1. Choose an unused hostname, such as track.example.com, separate from the website and incoming mail hostnames.
2. Copy the exact CNAME target assigned by the application’s domain connection flow. Do not copy Smartlead’s, Instantly’s, or another customer’s target.
3. Add a CNAME with the short name track and the assigned target. Use the connection flow’s TTL and proxy instructions; keep it DNS only unless the service explicitly supports proxying.
4. Verify domain ownership, CNAME resolution, and HTTPS provisioning in the connection flow before enabling tracking.
5. Send a test with a tracked link. Check the redirect destination, link behavior, and reporting. Opens and clicks may include privacy-proxy or security-scanner activity.

A DNS alias alone does not record events. The tracking service must process requests and associate them with the correct account. Custom tracking does not require changing your mailbox MX records.

07 / Verify the complete path.

• Confirm the domain resolves through public DNS and there is only one SPF policy for the sending hostname.
• Check DKIM at the selector supplied by the sending provider, and inspect the DMARC policy.
• Send a real message and inspect Authentication-Results for SPF, DKIM, and DMARC alignment. A DNS lookup alone cannot prove a message was signed correctly.
• Test an incoming reply, an opt-out, an invalid address, and a disconnected account.
• Keep a record of changes and recheck after provider migration or key rotation.