DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Dmarc

How to Set Up SPF DKIM and DMARC for Multiple Domains on One Mail Server

By DMARCGuardian Editorial Team ·

The most common question when setting up DMARC for multiple domains from one server: do you need separate DKIM keys per domain, or does one shared key work?

The answer depends on whether your From header domains are related. If all your sending domains are subdomains of one parent domain, one DKIM key can work. If they are independent second-level domains, you need separate keys per domain. This guide covers both cases and walks through the full setup.

---

The Scenario: Multiple Domains One Server IP

You run a mail server at IP 203.0.113.50. That server handles outbound mail for three domains:

  • example.com
  • example.org
  • example.net

All three send through the same Postfix or Exchange instance. All three need SPF, DKIM, and DMARC published in DNS. All three need to pass authentication checks at receiving mail servers.

The challenge is that each authentication layer works slightly differently when multiple domains are involved. Get one layer wrong and the others fail by extension.

---

SPF for Multiple Domains From One Server

SPF authenticates the SMTP conversation. It checks whether the IP that delivered the message is authorized for the Return-Path (bounce address) domain, not the From header domain.

For each of your domains, publish an SPF record in DNS. With one server IP handling all three, each record looks like this:

example.com:

v=spf1 ip4:203.0.113.50 -all

example.org:

v=spf1 ip4:203.0.113.50 -all

example.net:

v=spf1 ip4:203.0.113.50 -all

All three records point to the same IP. This is valid. SPF evaluates the Return-Path domain, not the From header, so there is no conflict between the three records.

One thing to watch: if you send bounce messages from a different IP than your inbound mail server, that IP needs its own SPF record. The Return-Path for NDRs comes from your mail server's envelope-sender and may differ from your From header domain.

---

The DKIM Key Decision: Shared or Separate?

DKIM signs the message content with a private key. The receiving server uses the public key in DNS to verify the signature. The DKIM signature covers the From header domain, and this is where the multi-domain question matters.

When one DKIM key works across all domains:
If your mail server signs with a domain that matches all your From header domains, one key covers everything. This happens when your From domains are subdomains of a shared parent and your signing domain is that parent. Example: signing domain example.com aligns with sub1.example.com and sub2.example.com.

When you need separate DKIM keys:
If your From domains are independent second-level domains (example.com and example.org have no structural relationship), you need separate DKIM keys. Generate a key pair per domain, publish each public key under the correct domain and selector, and configure your mail server to sign each domain with its matching private key and selector.

Example DKIM record for example.com:

selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."

Example DKIM record for example.org:

selector2._domainkey.example.org TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The practical rule: if your mail server software supports per-domain DKIM key configuration, use separate keys per domain. If your software only supports one global DKIM key, keep all sending domains under one parent domain that matches the signing domain.

---

Publishing DKIM Records for Multiple Domains

After generating your DKIM key pairs:

1. Publish the public key as a TXT record under selector._domainkey.domain.com for each domain
2. Configure your mail server to sign outbound mail from each domain using the matching private key and selector
3. Test by sending a message and checking the Authentication-Results header

For each domain, the record format is:

selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY"

2048-bit RSA is the current minimum recommended key length. Some mail servers generate keys and selectors automatically (Microsoft 365 does this). Others require manual configuration.

Common mistake: publishing the DKIM record under the wrong domain. The record must be under the domain that your mail server uses as the signing domain. A mismatch between the signing domain and the DNS record domain causes DKIM to fail silently.

---

DMARC Alignment in Multi-Domain Setups

DMARC adds alignment checking on top of SPF and DKIM. SPF passes when the sending IP is authorized for the Return-Path domain. DKIM passes when the signature matches a published DKIM record. DMARC requires at least one of those authentication results to align with the From header domain.

In a multi-domain setup, a failure looks like this:

  • Mail is sent from user@example.org
  • Return-Path is set to user@example.com (your mail server's global bounce domain)
  • SPF passes for example.com
  • DKIM is signed by example.com
  • DMARC alignment fails because neither the SPF domain nor the DKIM signing domain matches the From header example.org

This happens when your mail server sets a global Return-Path domain or uses a centralized DKIM signing domain that does not match all your From header domains.

Your DMARC record has an aspf tag that controls alignment strictness:


  • aspf=r (relaxed, the default): subdomains of the aligned domain are accepted

  • aspf=s (strict): only the exact domain matches

For most multi-domain setups, aspf=r is the right setting. Strict mode breaks legitimate mail when your signing infrastructure uses a parent domain but your From headers use subdomains.

---

How to Verify Each Domain Is Configured Correctly

After publishing your DNS records, send a test message from each domain to a Gmail address and a Microsoft 365 address. Check the Authentication-Results headers:

What passing results look like:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass
       dmarc=pass

If any authentication method shows fail, your DMARC aggregate report (sent to your rua endpoint) will show which method failed and which domain was checked.

For multi-domain setups, reviewing the per-domain aggregate report is the only reliable way to catch failures that do not show up in individual test messages. A monitoring tool that tracks each domain independently and alerts on new alignment failures is the practical solution here. DMARCFlow consumes the daily aggregate report from each domain, tracks per-domain DKIM and SPF pass rates, and flags new sources that fail alignment. One misconfigured selector on example.net will not get buried in an aggregate view across all your domains.

Before you move any domain to p=quarantine or p=reject, confirm each of the following for that domain:

  • [ ] SPF record resolves correctly for all sending IPs
  • [ ] DKIM public key is published under the correct domain and selector
  • [ ] Test messages pass SPF, DKIM, and DMARC at Gmail and Microsoft 365
  • [ ] Aggregate report shows alignment failures on fewer than 1% of mail sent (for p=quarantine readiness) or fewer than 0.1% (for p=reject readiness)
  • [ ] All legitimate third-party senders for this domain are identified and accounted for
  • [ ] DKIM key rotation schedule is documented

---

FAQ

Can I use the same DKIM key for multiple domains?
Only if the signing domain matches the From header domain for all of them. In practice, this requires a parent-subdomain relationship between domains, or your mail server must sign each domain with its own private key while referencing the same public key. Separate keys per domain is the safer default.

What happens if my SPF record is the same for all domains?
Nothing wrong with that if all domains send from the same IP. Each SPF record is evaluated against its own Return-Path domain. Sharing the same IP across multiple SPF records is normal and does not cause authentication failures.

My DMARC policy is p=none. Do I still need DKIM working for all domains?
Yes. p=none means receivers only monitor and report, they do not reject mail. But moving to p=quarantine or p=reject without DKIM working correctly for every domain will break your legitimate mail with no warning. Get DKIM right now so enforcement is safe later.

How often should I rotate DKIM keys?
Microsoft recommends at least every 6 months. Some operators rotate every 90 days. Whatever schedule you choose, keep the old public key published for at least one DNS propagation cycle after rotating. Rotating too quickly causes transient authentication failures at receivers with strict DKIM requirements.

Who should receive DMARC aggregate reports?
Your own domain abuse team or postmaster address first. If you use a third-party monitoring service, include their endpoint as a secondary recipient. Avoid free external services for aggregate reports without checking their data retention and security practices. Your aggregate reports contain details about your mail volume and recipient data.