SPF, DKIM & DMARC for Multiple Domains on One Mail Server

When multiple email domains route through one mail server, the most common mistake is treating authentication as something you set up once and share across all domains. You cannot. Each domain authenticates independently and each domain needs its own SPF record, its own DKIM key, and its own DMARC policy.

The good news is that the per-domain setup is not hard. The rules are consistent. Once you understand how SPF, DKIM, and DMARC interact at the per-domain level, you can replicate the pattern across as many domains as you have.

If you are managing this across several domains already, DMARCFlow is designed to collect and visualize aggregate reports for all your domains in one place, with per-domain alerting when something drifts. That is a practical starting point before we get into the mechanics.

How SPF works when multiple domains share one server

SPF verifies that the sending mail server is authorized for your domain. The SPF record lives in DNS and lists the IPs or domains authorized to send mail for _that_ domain.

When you have domain A and domain B on the same server, they each need their own SPF record. The records can point to the same IPs, but the DNS records are separate.

A typical SPF record for a domain that uses Microsoft 365 looks like this:


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

If domain A and domain B both send through Microsoft 365, both get the same include mechanism. That works fine. What does not work is assuming one SPF record can cover both domains if they have different sending infrastructure.

The 10-lookup limit applies per record. If you have many third-party senders, use the redirect= modifier to point one domain's SPF record to another domain's SPF record instead of duplicating all the includes. Update one record and both domains stay in sync.

DKIM selectors: one per domain, not one for all

DKIM adds a cryptographic signature to outbound mail. The signing happens on your mail server using a private key. The public key lives in DNS under a selector you choose.

Here is the part that trips up most multi-domain setups: the DKIM selector is specific to the domain in the DKIM-Signature header. If you generate a DKIM key for selector1._domainkey.example.com and apply it to mail from domain A, the signature validates for domain A only. If you try to use that same key for mail from domain B, the signature fails because the From domain and the DKIM domain do not match.

Each domain needs its own DKIM key pair and selector.

On a server like OpenDKIM or Amavis with multiple domains, you configure one key table entry per domain:


example.com._domainkey IN TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY_HERE"
example.org._domainkey IN TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY_HERE"

When the mail server signs outgoing mail, it looks up the selector for the From domain and uses the corresponding private key. Domain A uses domain A's key. Domain B uses domain B's key. Same server, separate keys.

This is the most common point of failure in multi-domain DKIM setup: using one selector for all domains because they share the same server. It will not work.

DMARC alignment: the From domain is the anchor

DMARC checks that the domain in the From header aligns with the domains validated by SPF and DKIM. There are two alignment modes:

Strict: the From domain must exactly match the SPF domain or the DKIM domain
Relaxed: the From domain must share the same root domain as the SPF or DKIM domain (subdomains are allowed)

For most organizations, relaxed alignment is practical. You can have subdomain.example.com in your DKIM signature while the From header is example.com and alignment passes.

For multi-domain setups, this means each domain's DMARC record applies to mail _from_ that domain. If you send a newsletter from newsletter@example.com through a third-party ESP, the DKIM signature must be from example.com -- not from the ESP's domain -- or alignment fails.

The DMARC record itself lives at _dmarc.example.com for each domain. Each domain can use a different policy level once each one independently passes alignment checks.

Step-by-step: getting to p=reject for all domains safely

Do not set p=reject on day one. The safe progression is:

Step 1: Set p=none and collect aggregate reports

With p=none, you see what is happening without changing mail flow. Every DMARC-capable mail service sends aggregate reports to your RUA endpoint. Review these weekly for the first month.

Step 2: Check each domain independently

For each domain, confirm:

SPF passes for all legitimate sending IPs

DKIM signatures validate correctly for all authenticated sending sources

Alignment is clean -- no failures where mail should pass

If one domain has failures and another does not, investigate separately. Do not apply the same policy to all domains until each one is clean.

Step 3: Move to p=quarantine

When a domain has zero alignment failures for two consecutive weeks, move its policy to p=quarantine. Failing mail goes to spam instead of being rejected. Watch the quarantine rate -- a sudden spike means something in your sending setup changed.

Step 4: Move to p=reject

When a domain shows zero false positives at p=quarantine for two weeks, move to p=reject. From this point, any mail that fails authentication is silently rejected. There is no second chance for unaligned mail.

The entire multi-domain monitoring loop -- collecting reports per domain, checking for drift, acting on anomalies -- is where dedicated DMARC monitoring earns its place. Manually collecting XML reports from multiple domains and parsing them separately is time-consuming and error-prone. DMARCFlow automates that collection and gives you per-domain alerting so you do not have to check each domain manually.

Verifying each domain in isolation

Before relying on aggregate reports, test each domain individually:

1. Use MXToolbox SPF lookup to confirm your SPF record resolves correctly
2. Use DKIMValidator.com or mail-tester.com to send a test message and check DKIM signature status
3. Use DMARC Inspector to confirm your DMARC record is valid and properly formatted

Once individual tests pass, the aggregate reports should confirm the same at scale. If individual tests pass but aggregate reports show failures, the issue is with a specific sending source -- a subdomain, a marketing tool, or a legacy system -- and you need to find which one.

FAQ

Can I use the same DKIM selector for all domains on my mail server?

No. A DKIM selector is specific to the domain in the DKIM-Signature header. Using the same selector for all domains causes validation failures because the From domain does not match the domain the selector is authorized for. Each domain needs its own key pair.

Do all domains on the same server share the same SPF record?

They can share the same sending infrastructure, but each domain needs its own SPF DNS record. You can use redirect= to point one domain's SPF record to another domain's SPF record to avoid duplication, but the records themselves are separate.

Will DMARC p=reject break mail if I apply it to all domains at once?

Only if any domain has unaligned SPF or DKIM for legitimate mail. Apply the policy per-domain once each domain independently passes. Do not batch-apply p=reject to all domains simultaneously.

How many DKIM selectors can one domain have?

Technically unlimited, but most organizations use one active selector at a time. You can rotate selectors by publishing the new one before retiring the old one. Some domains use separate selectors for different sending systems -- marketing platform vs transactional vs internal.

What causes DKIM alignment failures in multi-domain setups?

The most common cause is using a DKIM key for the wrong domain. If your marketing platform signs as marketingplatform.com but your From header is example.com, alignment fails. The fix is to configure the ESP to sign as your domain, not their own.

How do I monitor multiple domains without checking each manually?

Aggregate reports are the answer, but they arrive as XML to an RUA endpoint. If you have five domains, you need those reports collected and parsed per domain. DMARCFlow automates that collection and surfaces per-domain failure rates and alignment data so you can see which domain has a problem without manually checking each one.