How to Set Up DKIM Per Domain So Each Business Sends Under Its Own Key

How to Set Up DKIM Per Domain, Step by Step

Understanding how to set up dkim per domain requires treating each sending entity as an isolated identity. Follow this systematic workflow for every domain you manage.

Step 1: Inventory Your Sending Domains

List every domain from which you dispatch outbound email. Include client-facing brands, formed LLCs, e-commerce stores, and secondary domains used solely for sending digital receipts or automated invoices. If a domain strictly receives incoming mail and never dispatches outbound messages, no outbound SMTP transactions exist to attach a DKIM signature to under IETF RFC 6376 specifications. However, to protect that domain against spoofing, operators typically publish a restrictive DMARC record even if no DKIM keys are configured.

Step 2: Generate a Distinct Key Pair for Each Domain

Each domain requires a unique private and public key pair. Reusing the same private key across different domains undermines security isolation: if a key associated with a minor side project is compromised, an attacker can sign malicious email on behalf of your core operational business. While 1024-bit RSA was historically common, modern mailbox providers consider 2048-bit RSA the baseline for reliable security. Ed25519 keys offer shorter strings and faster cryptographic computation, but receiver support remains uneven across older corporate receiving servers. For broad deliverability, stick to 2048-bit RSA.

You can generate these keys directly inside your mail host's interface, or manually using OpenSSL on the command line:

# Generate a 2048-bit RSA private key
openssl genrsa -out private.key 2048

# Extract the matching public key
openssl rsa -in private.key -pubout -outform PEM -out public.key

Step 3: Publish the Public Key in DNS

Log in to the DNS provider for your first domain. Create a new TXT record. The hostname or record name follows this explicit structure:

[selector]._domainkey.example.com

If your DNS provider automatically appends your root domain, you only need to enter [selector]._domainkey in the name field. The record value must be structured using standard DKIM syntax:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Be mindful of string lengths. Under IETF RFC 1035, individual text strings in DNS TXT records are limited to 255 characters. A 2048-bit RSA public key exceeds 400 characters. Most modern DNS control panels handle this automatically, but if yours rejects the string, you must break the public key into two quoted strings inside the same record, like this: ("v=DKIM1; k=rsa; p=part1..." "part2...").

Step 4: Enable Outbound Signing in Your Mail Host

Import or activate the corresponding private key within your mail host. Your mail platform must map outbound sender identities to their respective private keys. When your client dispatches an email where the From: address is operator@brand-a.com, the mail host must pull the private key specifically generated for brand-a.com and apply the signature.

Step 5: Send a Verification Test and Inspect Headers

Send a standard plain-text message to an external account, such as a personal Gmail or Outlook address. Open the raw email headers (in Gmail, select "Show original"; in Outlook, view "Message details"). Confirm two items:

• The d= value in the DKIM-Signature header precisely matches the root domain in the From: header.
• The s= value matches the exact selector you published in DNS.
• The Authentication-Results header displays dkim=pass.

Step 6: Repeat the Process for Remaining Domains

Repeat steps 2 through 5 for every other domain in your portfolio. Do not copy the private.key file or the TXT value from your first business over to your second business. Generating per-domain dkim keys ensures that if a key on your secondary side project is compromised, your core operating entity remains secure.

Choosing a Selector Name and Key Size Without Overthinking It

A DKIM selector is simply an arbitrary text label that points a receiving server to the right DNS TXT record. Because a single domain can possess multiple public keys—for transactional engines, newsletter platforms, and personal mailboxes—the selector differentiates between them.

You can name a selector almost anything, provided it consists only of alphanumeric characters and hyphens. Avoid complex naming schemes. Practical options include:

• Date-based selectors: 202601 or 2026q3. This format is practical because it immediately tells you when the key was deployed.
• Application-based selectors: desk, transact, or mail. This clarifies which system signs the message.
• Provider defaults: Many hosts assign automated strings like k1, s1, or folio.

The only mandatory rule is that the selector declared in the outbound email's DKIM-Signature header (s=value) must match the subdomain label preceding ._domainkey in your DNS records.

When selecting your key length, choose 2048-bit RSA. A 1024-bit key is cryptographically weak by modern standards and can trigger deliverability penalties from security-conscious receivers. A 4096-bit key offers higher theoretical security, but its public key record is so large that it can encounter DNS UDP packet size limits, leading to DNS timeouts and verification failures.

When publishing the TXT record, set the Time-To-Live (TTL) to 3600 seconds (1 hour) for ongoing stability. Once the migration is complete and verified, return the TTL to 3600.

A common operational pitfall involves text formatting. When copying a public key from a terminal or web interface, users often inadvertently include line breaks, carriage returns, or surrounding quote marks. Some DNS interfaces do not sanitize input; they store the record with literal line breaks or escape characters. This creates an invalid record that appears present during a manual check but fails mathematical parsing when queried by a remote mail server.

Verifying Per-Domain DKIM Without a Deliverability Team

You do not need an enterprise deliverability consultant to confirm that your separate dkim for multiple domains setup works properly. You can verify it yourself by reading raw message headers.

Send a test message from each domain to an external mailbox. When the message arrives, inspect the headers. Locate the Authentication-Results block. A healthy header looks similar to this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@brand-a.com header.s=202601 header.b=X9aL7k...;
       spf=pass (google.com: domain of operator@brand-a.com designates 192.0.2.1 as permitted sender);
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=brand-a.com

Look specifically at three data points:

1. dkim=pass indicates the signature was decrypted and the payload matched the hash.
2. header.i= or the d= tag matches your visible domain name.
3. dmarc=pass confirms that your DKIM identity aligns with your header.from domain.

If you see dkim=pass but dmarc=fail, your signature is cryptographically valid, but your domains do not align. This happens when an email claims to be from brand-b.com in the sender line, but was signed using the private key and selector belonging to brand-a.com. This is the classic signature mismatch caused by mail aliases.

You should also verify your DNS records using public lookup tools before initiating large outbound campaigns. Our free domain health check evaluates SPF, DKIM, DMARC, and MTA-STS records instantly, without requiring an email address to view results. Remember that DNS is domain-specific. Testing brand-a.com tells you nothing about the health of brand-b.com; verify every domain separately.

For ongoing monitoring, examine your DMARC aggregate reports (sent to the address specified in your DMARC record's rua= tag). These XML reports list every server sending mail on behalf of your domain, alongside pass/fail stats for SPF, DKIM, and DMARC alignment. Because modern phishing tactics frequently target unauthenticated domains, verifying authentication is vital. The Federal Trade Commission guidance on phishing highlights how unauthenticated communication enables sender spoofing; setting up strict alignment ensures receivers drop unauthorized mail claiming your name.

Doing This by Hand vs. Letting the Host Publish the Records

There are two methods for managing DKIM across several business entities: manual generation and automated DNS publishing.

Managing the records manually means you generate keys using a CLI or hosting dashboard, access each domain registrar's control panel, manually copy and paste the TXT records, and wait for propagation. This approach works reliably and gives you total control over selector naming conventions, key sizes, and rotation schedules. However, manual management carries friction. Transcribing long cryptographic keys across three, five, or ten domains introduces formatting mistakes, truncated strings, and missing periods.

The alternative is automated setup via protocols like Domain Connect. Under this model, your mail host integrates directly with supported registrars (such as Cloudflare, GoDaddy, or Namecheap). When you connect a domain, the platform generates the key pair and automatically publishes the requisite MX, SPF, and DKIM records to your DNS zone file with a single authorization click. This eliminates human transcription errors and cuts domain provisioning down to seconds.

The operational comparison between manual and automated approaches comes down to speed and control:

• Manual DNS setup: Total control over selectors and key rotation, but high administrative burden when configuring more than three domains. Transcription errors can lead to silent authentication failures.
• Automated setup (Domain Connect): Zero manual pasting, no syntax mistakes, and rapid onboarding across multiple domains. However, you rely on the provider's default selector labels.

If you manage multiple entities as an independent operator, your setup time represents real overhead. Setting up five domains by hand can take several hours of meticulous record-checking. Automated setups resolve the plumbing instantly so you can focus on running your businesses. If you already have working, isolated DKIM keys at your current host, there is no technical reason to move. The goal is proper cryptographic isolation, regardless of how the records are published.

What Per-Domain DKIM Costs When You Run Several Domains

The traditional business email market is structured around teams, charging on a per-user, per-month seat basis. If you are one person managing four separate businesses—an LLC, an online store, a newsletter, and an advisory firm—traditional vendors expect you to purchase four separate seats or rely on aliases that break DKIM alignment.

For an operator running four distinct entities, paying for multiple isolated seats can quickly total several hundred dollars each year simply to send authenticated email under separate domains.

Independent multi-brand operators face a distinct set of operational needs. Solo entrepreneurs, portfolio entrepreneurs, and multi-LLC owners need separate domains, not extra seats. Here is how hosting models compare when handling multiple sending domains:

Review the limits before the benefits. Folio has no free plan. It offers a 14-day free trial and a no-credit-card preview, then flat paid plans (Solo, Studio, Holding Co.). The no-credit-card preview is strictly limited to one domain and 100 sends. Monthly outbound send limits are capped at 1,000 sends (Solo), 6,000 sends (Studio), and 30,000 sends (Holding Co.), with individual attachments capped at 15 MiB per message.

Furthermore, Folio is a single-operator inbox, not a team or shared mailbox — there are no per-user seats and no team collaboration features. Folio encrypts mail in transit (TLS) and at rest, but is not end-to-end or zero-knowledge encrypted: mail is stored server-side and readable by Folio for spam filtering and search. Folio is a proprietary, hosted service; its source code is not public. Folio is a fully hosted service and cannot be self-hosted or run on your own servers or infrastructure.

For a solo founder operating five domains, paying $12 per month billed annually ($144 per year) on Folio's Studio plan provides full cryptographic separation for every brand without paying for unused seats. When evaluating alternative providers, you can estimate your potential costs using our email cost calculator.

Common Mistakes and Edge Cases

Even technical operators encounter configuration traps when setting up DKIM for multiple domains. Watch out for these specific issues:

1. Publishing the Record on the Root Instead of the Subdomain

DNS hosts differ in how they accept hostnames. If your registrar expects relative hostnames and your domain is brand-a.com, entering selector._domainkey.brand-a.com creates a broken record pointing to selector._domainkey.brand-a.com.brand-a.com. Check whether your registrar automatically appends your root domain before saving.

2. Overwriting or Missing Third-Party Senders

Your primary mailbox host is rarely your only outbound sender. If you run a Shopify store, use a transactional email provider, or dispatch newsletters via a third-party platform, those systems send mail on your behalf. They require their own distinct selectors (e.g., k1._domainkey or s1._domainkey). Publishing a DKIM key for your personal mailbox does not replace the keys needed for your transactional providers. Each service needs its own selector record in your DNS zone file.

3. Key Rotation Without Overlapping Selectors

Security best practices suggest rotating cryptographic keys periodically. If you rotate keys by updating the text value of an existing selector record, emails in transit or queued by receiving mail servers will fail verification. often generate a new selector (e.g., switching from 202601 to 202602), publish the new record alongside the old one, verify that the new record resolves, switch outbound signing in your mail host, and wait at least 48 hours before deleting the old selector.

4. Subdomain Alignment Quirks

If you dispatch transactional messages from a subdomain like receipts.shop.com while your DMARC record lives at shop.com, relaxed DMARC alignment allows a DKIM signature with d=shop.com to pass. However, if your DMARC policy enforces strict alignment (adkim=s), that check fails. Verify that your DMARC alignment policy matches your sending architecture.

5. Assuming Success on One Domain Means All Are Configured

Every domain operates in isolation. A pristine pass on your agency domain does not validate the store domain you registered last night. Every new domain demands its own key generation, DNS publication, and header verification.

Frequently Asked Questions

Can I use the same DKIM key for multiple domains?

Technically, a private key can generate signatures for multiple domains, but doing so is poor practice. Reusing keys links your domain reputations together and exposes every business you run if that single private key is compromised. Additionally, you would still need to publish identical public key records across the DNS of every domain. Generate a unique key pair per domain instead.

How do I check whether each of my domains has its own DKIM key?

Send a test email from an address on each domain to an external Gmail or Outlook account. View the raw message headers and find the DKIM-Signature header. Check the d= value (the signing domain) and the s= value (the selector). If the d= tag matches the domain in the From: address and the selectors point to unique public keys in DNS, your domains are authenticating independently.

What is the difference between DKIM alignment and DKIM verification?

DKIM verification checks the cryptographic integrity of the message: did the public key in DNS decrypt the signature, confirming the message was not modified in transit? DKIM alignment checks domain identity under DMARC: does the domain in the signature's d= tag match the domain displayed to the recipient in the visible From: header? A message can pass DKIM verification while failing DKIM alignment.

Do I need a separate DKIM key for a domain I only use to receive mail?

No. DKIM functions strictly as an outbound signing protocol under IETF RFC 6376. When a domain is configured solely to receive mail via MX records without an active outbound SMTP sender, there are no outbound messages to sign. However, publishing a defensive DMARC policy (such as p=reject) alongside an empty SPF record (v=spf1 -all) protects that receive-only domain against spoofing. If that domain ever sends automated vacation replies, forwarded messages, or system notices, it requires its own DKIM key and selector.

How long does it take for a new DKIM record to start working?

When you deploy an entirely new selector string that remote recursive DNS resolvers have not previously queried, resolvers fetch the record directly from your authoritative nameservers during initial message verification. If you are modifying or rotating an existing selector rather than publishing a new one, resolvers may cache and retain the old record until its Time-To-Live (TTL) expires, which can take anywhere from a few minutes up to 24 hours depending on your previous configuration.

Run the free domain health check to see whether each of your domains has a valid DKIM record, then compare per-domain pricing at our pricing page if you are paying per seat for domains only you use.