DKIM and Third-Party Senders: Setting Up Custom Domain Signing

The Challenge of Third-Party Sending: When Your Email Isn't Really Yours

Modern businesses rely on dozens of cloud services to communicate with customers—Salesforce for CRM emails, HubSpot for marketing, Zendesk for support tickets, Stripe for receipts, and countless others. Each of these platforms sends email on your behalf, but here's the problem: by default, they sign messages with their own DKIM keys, not yours.

When Salesforce sends an email from noreply@salesforce.com, that's fine for Salesforce. But when they send an email that appears to be from noreply@yourdomain.com but sign it with s=sfdc under d=salesforce.com, receiving servers see a mismatch. The DKIM signature is cryptographically valid, but the domain in the signature (salesforce.com) doesn't match the domain in the From header (yourdomain.com).

This mismatch has serious consequences:

• DMARC failures: DMARC requires domain alignment. When the DKIM domain doesn't match the From domain, DMARC fails regardless of the cryptographic validity.
• Poor inbox placement: Gmail and Outlook treat unaligned authentication as suspicious, often filtering these emails to spam or the promotions tab.
• Brand confusion: Recipients see "via salesforce.com" next to your brand name in Gmail, undermining trust and brand consistency.
• Phishing vulnerability: Attackers can exploit misaligned DKIM to spoof your domain using legitimate third-party infrastructure.

The solution is custom domain DKIM signing—configuring your third-party senders to sign emails with your domain's private keys.

Understanding DMARC Domain Alignment for DKIM: The A-Tag and D-Tag Relationship

To understand why third-party configuration matters, you need to understand how DMARC evaluates DKIM signatures. A DKIM-Signature header contains two critical tags:

• d= (domain): The domain that signed the email (e.g., d=yourdomain.com)
• s= (selector): The selector used to find the public key
• a= (algorithm): The signing algorithm (e.g., a=rsa-sha256)

DMARC then checks for alignment between the DKIM signature's domain and the domain in the From header. There are two alignment modes:

• Strict alignment (adkim=s): The From domain must exactly match the DKIM d= domain. subdomain.yourdomain.com would NOT align with yourdomain.com.
• Relaxed alignment (adkim=r) [Default]: The From domain and DKIM d= domain can be different as long as they share the same organizational domain. subdomain.yourdomain.com aligns with yourdomain.com.

Most organizations use relaxed alignment, which is more flexible. However, even with relaxed alignment, salesforce.com signing a message from yourdomain.com will never align because the organizational domains (salesforce.com vs yourdomain.com) differ.

To pass DMARC, you need third-party senders to use your domain in the DKIM d= tag, which requires them to possess a private key for your domain and publish a corresponding public key in your DNS.

CNAME Delegation: The Modern Solution for Third-Party DKIM

In the early days of DKIM, third-party services would ask you to generate a key pair and paste the entire public key as a TXT record in your DNS. This approach worked but had significant drawbacks:

• Manual key rotation: When the provider needed to rotate their keys (for security or scaling), you had to manually update your DNS records.
• Key management burden: You ended up managing dozens of keys across different providers, each with different rotation schedules.
• Error-prone copy-paste: A single mistyped character in a 400-character base64 string broke DKIM.

Modern SaaS providers have standardized on CNAME delegation, which elegantly solves these problems. Here's how it works:

1. Your third-party provider (e.g., HubSpot) generates a DKIM key pair for your domain and stores the private key on their servers.
2. The provider gives you a CNAME record, not a raw public key. For example: hs1._domainkey.yourdomain.com CNAME hs1._domainkey.hubspot.com
3. You publish this CNAME record in your DNS. It contains no cryptographic material—just a pointer.
4. When a receiving server looks up hs1._domainkey.yourdomain.com, your DNS returns a CNAME that redirects the query to hs1._domainkey.hubspot.com.
5. HubSpot's DNS contains the actual TXT record with the public key, which HubSpot maintains and rotates automatically.

The benefits are enormous:

• You publish the CNAME once and never touch it again.
• The provider handles all key rotation—they update their DNS, and your delegation automatically follows.
• No risk of copy-paste errors with long base64 strings.
• The provider can implement advanced security features (like key rollover) without involving you.

Major providers using CNAME delegation include: Google Workspace (for third-party sending), Mailchimp, SendGrid, HubSpot, Salesforce (Pardot/Marketing Cloud), Zendesk, and many others.

Step-by-Step CNAME Configuration for Popular CRM and Marketing Platforms

While specific steps vary by provider, the general pattern is consistent. Here are detailed guides for popular platforms:

HubSpot DKIM Setup

1. In HubSpot, navigate to Settings → Website → Domains & URLs.
2. Click on your domain under "Email sending."
3. In the DKIM section, click "Generate DKIM record."
4. HubSpot will provide two or more CNAME records (for redundancy). They'll look like: hs1._domainkey.yourdomain.com CNAME hs1._domainkey.hubspot.com
5. Copy each CNAME record exactly as shown (including any trailing dots).
6. In your DNS provider (Cloudflare, AWS Route53, GoDaddy, etc.), create new CNAME records with the provided names and targets.
7. Wait for DNS propagation (typically 5-30 minutes), then return to HubSpot and click "Verify DKIM."
8. HubSpot will confirm when the records are active and begin signing your marketing emails.

Salesforce Marketing Cloud (Pardot) Setup

1. In Pardot, go to Admin → Domain Management.
2. Select "Sender Domains" and add your domain.
3. Salesforce will generate a unique DKIM selector and provide a CNAME record.
4. Publish the CNAME in your DNS: [selector]._domainkey.yourdomain.com CNAME [selector]._domainkey.sfmc-marketing.com
5. After DNS propagation (allow up to 24 hours), return to Pardot and verify the configuration.
6. Test by sending a marketing email to a verification address.

SendGrid (Twilio Email API) Setup

1. In SendGrid, navigate to Settings → Sender Authentication.
2. Choose "Domain Authentication" and enter your domain.
3. Select "CNAME" as the verification method (instead of TXT).
4. SendGrid will provide three CNAME records: one for DKIM (email signing), one for SPF (sending authorization), and one for ownership verification.
5. Add all three CNAME records to your DNS.
6. SendGrid will automatically detect the records and begin signing your transactional and marketing emails.

Zendesk Support DKIM Setup

1. In Zendesk, go to Admin → Channels → Email.
2. Under "Outgoing email," select your domain and click "Configure DKIM."
3. Zendesk provides a CNAME record: zendesk._domainkey.yourdomain.com CNAME zenid._domainkey.zendesk.com
4. Add the CNAME to your DNS. Note that Zendesk may use a unique subdomain instead of a generic name—copy exactly.
5. After verification (usually instant after DNS propagation), Zendesk support tickets will be DKIM-signed with your domain.

Universal tip: Always add the trailing dot to CNAME targets if your DNS provider requires fully qualified domain names. For example, target.provider.com. (with dot at end) instead of target.provider.com. Check your DNS provider's documentation.

Managing DKIM for Independent Brand Subdomains

If your organization uses different subdomains for different brands or departments (e.g., marketing.yourdomain.com, billing.yourdomain.com, support.yourdomain.com), you need separate DKIM configuration for each subdomain.

Why separate configuration matters: DMARC's alignment check operates at the subdomain level in strict mode (adkim=s). Even in relaxed mode, some receivers treat subdomains as separate entities for reputation tracking.

Best Practices for Subdomain DKIM

• Create unique selectors per subdomain: Don't reuse the same selector name across different subdomains, as this creates key management confusion.
• Configure each ESP separately: If you use HubSpot for marketing emails (marketing.yourdomain.com) and Zendesk for support (support.yourdomain.com), configure DKIM separately in each platform using the appropriate subdomain.
• Consider wildcard DKIM: Some providers support wildcard DKIM records that apply to all subdomains. For example, *._domainkey.yourdomain.com. However, this approach has security tradeoffs and isn't supported by all receiving servers.
• Use DMARC reporting to monitor: DMARC aggregate reports will show you which subdomains are sending email and whether they have valid DKIM configuration. Use this feedback to identify gaps.

Example configuration for a multi-subdomain organization:

# Marketing subdomain
marketing.yourdomain.com:
  - Selector: hs1._domainkey.marketing.yourdomain.com CNAME hs1._domainkey.hubspot.com

# Support subdomain  
support.yourdomain.com:
  - Selector: zd1._domainkey.support.yourdomain.com CNAME zenid._domainkey.zendesk.com

# Transactional subdomain
txn.yourdomain.com:
  - Selector: sg1._domainkey.txn.yourdomain.com CNAME sg1._domainkey.sendgrid.net

Handling DNS Propagation Windows: Patience Is a Virtue

One of the most common frustrations when setting up third-party DKIM is DNS propagation delay. You add the CNAME record, click "Verify" in the provider's dashboard, and it fails immediately. This doesn't mean you made a mistake—it usually means DNS hasn't propagated yet.

Understanding Propagation Timing

DNS records don't update instantly across the entire internet. When you add or change a record:

1. Your DNS provider updates their authoritative nameservers immediately.
2. However, recursive resolvers (like Google's 8.8.8.8 or your ISP's DNS) cache records based on their TTL (Time-To-Live).
3. Your third-party provider also caches DNS lookups to reduce latency and cost.

Realistic propagation timelines:

• 5-30 minutes: If your domain's TTL was previously set low (300 seconds) and you're checking from a resolver without aggressive caching.
• 1-4 hours: Typical for standard TTL settings (3600 seconds / 1 hour).
• 24-48 hours: If your previous TTL was high (86400 seconds / 24 hours) and resolvers are respecting it.
• Up to 72 hours: In rare cases with misconfigured resolvers or ISP-level caching.

How to Speed Up Propagation

• Lower TTL in advance: Days before adding third-party DKIM records, reduce your domain's default TTL to 300 seconds. This doesn't speed up the initial propagation but ensures future changes propagate faster.
• Use multiple verification tools: Don't rely solely on your provider's verification. Use our DKIM Checker, plus command-line tools like dig or nslookup, to check different DNS resolvers.
• Flush your local DNS cache: On Windows: ipconfig /flushdns. On macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On Linux: sudo systemd-resolve --flush-caches

Pro tip: Most third-party providers automatically retry verification every few hours. If you see "pending verification" or "verifying," leave it alone for 24 hours before troubleshooting.

Solving the SPF 10-Lookup Limit with DKIM Alignment

SPF (Sender Policy Framework) has a critical limitation: the SPF specification limits DNS lookups to 10 during evaluation. Each time you include a third-party service's SPF mechanism (like include:spf.sendgrid.net), that counts toward the limit. If you use more than 10 lookups, SPF evaluation fails with a "PERMERROR," causing authentication to fail.

This becomes a serious problem for organizations using many third-party senders. A typical configuration might include:

• include:_spf.google.com (Google Workspace) - 2-3 lookups
• include:spf.protection.outlook.com (Microsoft 365) - 2-3 lookups
• include:spf.sendgrid.net - 2-4 lookups
• include:spf.mailchimp.com - 2-3 lookups
• include:servers.mcsv.net - 1-2 lookups

This easily exceeds 10 lookups, causing SPF to fail even though each individual mechanism is valid.

The DKIM Solution

Here's the key insight: DMARC passes if EITHER SPF passes AND aligns OR DKIM passes AND aligns. You don't need both to pass. This means you can strategically use DKIM alignment to bypass SPF limitations.

Example strategy:

• Maintain SPF for your primary sending sources (e.g., Google Workspace, your own mail servers) where you stay under 10 lookups.
• For all other third-party senders, rely exclusively on DKIM alignment. Don't add them to SPF at all.
• Configure custom domain DKIM (using CNAME delegation as described above) for each third-party sender.
• DMARC will pass because DKIM passes and aligns, even if SPF fails or isn't configured.

Important caveat: Some third-party senders don't support custom DKIM signing. In those cases, you must include them in SPF. Prioritize which services you add to SPF based on volume and criticality, staying under the 10-lookup limit.

Use our DKIM Checker's SPF lookup counter to see how many lookups your current SPF record uses and identify which services could be moved to DKIM-only authentication.

Auditing Outbound Headers Using the DKIM Checker

After configuring third-party DKIM, you must verify that it's working correctly. Here's a comprehensive audit process:

Step 1: Send Test Emails from Each Provider

For each third-party service (HubSpot, SendGrid, Zendesk, etc.), trigger a test email to an address you control. Use real content that mimics your typical email (don't use test content that might bypass authentication pathways).

Step 2: Inspect Raw Email Headers

Open the raw message source and look for the DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=hs1;
  c=relaxed/relaxed; h=from:subject:date:to;
  bh=WmY3Qj...; b=dzdVyO...

Verify three critical elements:

• d= tag: Must be your domain (e.g., d=yourdomain.com), not the provider's domain.
• s= tag: Should match the selector you configured in DNS (visible as the CNAME record you added).
• Authentication-Results header: Look for dkim=pass or dkim=neutral. If it shows dkim=fail, something is wrong.

Step 3: Use Our DKIM Checker for Automated Validation

Our DKIM Checker automates this process. Simply:

1. Enter your domain and the selector (from the CNAME you added).
2. The tool performs a DNS lookup to verify the CNAME chain resolves to a valid TXT record with a public key.
3. It validates the key format, key length, and syntax.
4. Optionally, forward a test email to our verification inbox, and the tool will parse the headers and report pass/fail status.

Step 4: Monitor DMARC Aggregate Reports

After configuring DKIM for all third-party senders, monitor your DMARC aggregate reports (RUA) for 1-2 weeks. Look for:

• DKIM alignment rates: Ideally 100% of your email should have aligned DKIM signatures.
• Source IPs: Verify that each third-party sender's IP ranges appear in reports with passing authentication.
• Failure reasons: Any DKIM failures will include the selector and domain—use this to debug misconfigured providers.

Final checklist for third-party DKIM success:

• ✓ All CNAME records added to DNS for each provider
• ✓ DNS propagation complete (wait 24-48 hours before troubleshooting)
• ✓ Each provider's dashboard shows "Verified" or "Active" status
• ✓ Test emails show d=yourdomain.com in DKIM signature
• ✓ DMARC reports show passing DKIM alignment for all third-party sources
• ✓ SPF lookup count remains under 10 (or you've accepted SPF failures for DKIM-aligned senders)

If any provider fails verification after 48 hours, double-check that you used the exact CNAME name and target provided—including any trailing dots, case sensitivity, and provider-specific formatting requirements.