DKIM for Multiple Email Providers: Selector and Key Management

Most businesses don't send all their email through a single provider. You might use Google Workspace for everyday communication, SendGrid for order confirmations, and Zendesk for customer support tickets. Each of these services needs to sign outgoing email on behalf of your domain, and that means each one needs its own DKIM configuration.

The good news is that DKIM was designed for exactly this situation. With the right setup, every provider can authenticate mail independently without interfering with the others.

Browse all How It Works guides.

Why Businesses Use Multiple Email Providers

Different types of email have different requirements. A marketing newsletter platform is built for bulk sends and list management. A transactional email service is optimized for speed and deliverability of receipts, password resets, and shipping notifications. Your primary mailbox provider handles day-to-day conversations.

Here are some common combinations:

Each of these services sends email as your domain. Without DKIM configured for each one, receiving mail servers have no way to verify that those messages are legitimate. If you also manage multiple domains, each domain-provider combination needs its own setup.

How DKIM Selectors Prevent Conflicts

The key to running multiple DKIM configurations on the same domain is the selector. As defined in RFC 6376 Section 3.6.2.1, a selector is a label that tells receiving servers which public key to look up in your DNS. Each provider gets its own selector, so their keys never overlap.

For example, if your domain is example.com, your DNS might contain three separate DKIM records:

google._domainkey.example.com      → Google Workspace's public key
s1._domainkey.example.com          → SendGrid's public key
zendesk1._domainkey.example.com    → Zendesk's public key

When SendGrid sends an email on your behalf, it signs the message and includes s=s1 in the DKIM signature header. The receiving server sees that selector, looks up s1._domainkey.example.com, retrieves the matching public key, and verifies the signature. The other DKIM records are not involved at all.

Setting Up DKIM for Multiple Providers

The process is the same for each provider you add. You'll repeat these steps once per service:

Example: A Three-Provider Setup

Here is what a typical multi-provider DNS configuration looks like for example.com:

Notice that some providers use TXT records containing the full public key, while others use CNAME records that point to the provider's own DNS. Either approach works. Follow whatever your provider specifies.

DMARC Alignment with Multiple Providers

DKIM is only one part of email authentication. For DMARC to pass, the domain in the DKIM signature (the d= tag) must align with the From address domain. This is called alignment.

When you set up DKIM through a provider's official process, they typically sign with your domain in the d= tag, which satisfies alignment. However, some providers sign with their own domain by default until you complete custom DKIM setup. That means DMARC will fail even though DKIM itself passes.

Common Mistakes to Avoid

Selector collisions. If two providers happen to use the same selector name, one record will overwrite the other in DNS. This is rare with major providers since they each use distinctive selectors, but it can happen with smaller services. If you spot a conflict, check whether the provider allows you to customize the selector.

Forgetting a provider. It's easy to overlook a service that sends email as your domain, especially tools set up by other team members. A CRM, helpdesk, or invoicing tool may be sending mail without DKIM, which can trigger DMARC failures once you enforce a strict policy.

Not updating after switching providers. When you stop using a service, remove its DKIM DNS record. Old records pointing to decommissioned keys create confusion during troubleshooting and, in rare cases, could be exploited if the old provider reassigns infrastructure.

Skipping verification. Adding the DNS record is not enough. Always verify within the provider's dashboard and confirm with a test email. Typos in DNS records are one of the most common DKIM issues.

Auditing Your DKIM Setup

If your domain has been around for a while, you may not know exactly which DKIM records exist in your DNS. Here's a practical way to audit:

1. List every service that sends email as your domain. Check with your marketing, sales, support, and IT teams. Don't forget transactional services tied to your app or website.
2. Check your DMARC reports. DMARC aggregate reports show which IP addresses and services are sending mail for your domain, including whether DKIM passed or failed for each.
3. Look up known selectors. For each provider on your list, look up their default selector in DNS to confirm the record exists and is valid.
4. Remove stale records. If you find DKIM records for services you no longer use, delete them from DNS.

Running this audit once or twice a year keeps your authentication setup clean, especially as your team adds or removes email tools.

References

• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures

---

Managing DKIM across multiple providers is straightforward once every service has its own selector and DNS record. Use DKIM Creator to generate keys for any provider that needs a custom setup.