Blog · Dmarc

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

When you route multiple email domains through one mail server, each domain needs its own SPF, DKIM, and DMARC configuration. Get any one of these wrong and legitimate mail starts failing silently, or spoofed mail starts passing without warning.

This guide walks through the specific ways multi-domain setups break email authentication, and what correct configuration actually looks like.

Why Multi-Domain Email Routing Breaks SPF, DKIM, and DMARC

Single-domain email authentication is straightforward. You have one domain, one mail server, one set of DNS records. Add a second domain through the same server and the complexity jumps faster than most guides admit.

The core problem is that SPF, DKIM, and DMARC each handle domain relationships differently. SPF ties authorization to the envelope-from domain. DKIM ties signatures to a selector domain that may or may not match your sender address. DMARC ties both of those to the header-from domain through alignment. When one mail server handles multiple domains, these layers can pull in different directions unless you configure them deliberately.

SPF for Multiple Domains: The 10-Lookup Limit

SPF authorizes your mail server by adding an include or redirect mechanism to your DNS record that points to your server's IP addresses. For one domain, this looks simple:

v=spf1 ip4:203.0.113.10 include:_spf.example.com ~all

For multiple domains pointing at the same server, you have two real options.

Option 1: Per-domain SPF records. Each domain gets its own SPF record pointing to the same server. This works cleanly but multiplies your DNS footprint. If your sending infrastructure changes, you update every domain's SPF record separately.

Option 2: Centralize with a subdomain. Create a subdomain like _spf.example.com that holds the actual SPF record with your server IPs. Then each sending domain includes that subdomain:

# example.com v=spf1 include:_spf.example.com ~all # example.org v=spf1 include:_spf.example.com ~all

Option 2 is easier to maintain. One change updates all domains at once.

The catch is the SPF 10-DNS-lookup limit. Each include: directive counts as one lookup. If you chain multiple includes or use third-party services (CRM, marketing tools, helpdesk), you can hit 10 lookups fast and your SPF record breaks silently. When that happens, mail fails or falls back to softfail unpredictably. This is one of the most common reasons legitimate mail stops delivering after a multi-domain setup goes live.

For multi-domain setups, consider flattening your SPF record by replacing include: chains with direct ip4: entries where possible. For example:

v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:sendgrid.net ~all

If you are using multiple third-party services, keep a running count of your lookup chain. This is where a monitoring tool like DMARCFlow helps: it surfaces sudden SPF failures across your domains within hours, rather than waiting for users to report bounces.

DKIM Signing Across Multiple Domains

DKIM attaches a cryptographic signature to outgoing mail. The signature lives under a selector subdomain, and the public key lives in DNS. The key question for multi-domain setups is whether one DKIM key works for all your domains, or whether you need separate keys per domain.

The answer depends on your selector configuration.

If your mail server signs with the same selector domain regardless of which sender domain is in the From header, all your domains share one DKIM result. That can create DMARC alignment failures.

DMARC requires either SPF alignment (the envelope-from domain matches the header-from domain) or DKIM alignment (the DKIM selector domain matches the header-from domain). If your selector is mail._domainkey.example.com but you are sending from newsletter@example.org, the DKIM domain does not align with the From header. DMARC fails even though the signature is valid.

Option 1: Dedicated selector per domain. Configure your mail server to use different DKIM selectors for each sending domain. You publish a separate DKIM public key for each selector in each domain's DNS. More work to set up, but alignment passes cleanly.

Option 2: Shared selector with DMARC relaxed alignment. If your selector uses a parent domain that all your sending domains are subdomains of, DKIM alignment passes under relaxed mode. For example, if you send from mail.example.com and shop.example.com, both are subdomains of example.com and alignment passes. But if you send from example.org, which is a different second-level domain, alignment fails.

Option 3: Separate DKIM keys but shared selector subdomain. Some hosting providers use a _dmarc.example.com style selector that works across all subdomains. This requires checking your specific provider's capabilities.

If you are not sure which selector your mail server is using, look at the DKIM-Signature header in a sent message. The d= tag shows the selector domain. If it does not match your From header domain and you are using strict alignment, you have a problem.

DMARC Alignment When Domains Share a Mail Server

DMARC is where most multi-domain setups quietly break. The rule is simple in theory: the domain that appears in your From header must match the domain that passed SPF or DKIM. In practice, when one server sends for example.com, example.org, and example.net, each of those domains needs to pass DMARC independently.

The common failure mode looks like this:

  • example.com sends mail through the shared server. SPF passes (envelope-from is example.com), DKIM passes (selector is mail._domainkey.example.com). DMARC alignment passes.
  • example.org sends through the same server. SPF passes (envelope-from is example.org), but the DKIM selector is still mail._domainkey.example.com because the server was configured for example.com first. DMARC fails because DKIM domain does not align with From header.

This is how organizations end up with legitimate mail failing DMARC for some domains but not others, sometimes without anyone noticing for weeks.

The fix is to either configure per-domain DKIM selectors, or use a parent-domain selector that all sending domains align with under relaxed DMARC rules.

Step-by-Step: Configuring SPF, DKIM, and DMARC for Multi-Domain Setups

Step 1: Decide on your SPF structure first. Pick a subdomain to hold your centralized SPF record. Update every sending domain to include that subdomain. Count your DNS lookups before you go live.

Step 2: Configure DKIM per domain or use aligned selectors. If your mail server supports per-domain DKIM key pairs, generate and publish a DKIM key for each sending domain. If it only supports one selector, make sure all your sending domains are subdomains of the selector domain under relaxed DMARC alignment.

Step 3: Set initial DMARC records. Start with p=none for monitoring on each domain. Aggregate reports arrive within 24-48 hours. Review them before moving to enforcement.

Step 4: Check DMARC alignment for each domain. Look at your aggregate reports and confirm that both SPF and DKIM are passing with the correct domain in the From header. If any domain shows alignment failures, go back to step 2.

Step 5: Move to p=quarantine, then p=reject gradually. Once you have confirmed clean passes across all domains, tighten your policy. Moving straight to p=reject risks losing legitimate mail if your DKIM selector is still misconfigured for one of your domains.

How to Check Your Multi-Domain DMARC Reports

DMARC aggregate reports arrive from receiving mail servers as XML files. Each report covers a 24-hour window and lists every domain that tried to send mail to each receiver, along with SPF, DKIM, and DMARC results.

For multi-domain setups, these reports are essential. A problem with one domain can hide behind volume from your other domains if you are not looking at per-domain breakdowns.

This is where ongoing monitoring matters. Six months after you set everything up correctly, someone adds a new sending subdomain without updating the SPF record. Without regular report review, you would not know until mail starts bouncing.

DMARCFlow aggregates these reports across all your domains into one view. You can spot alignment failures per domain, track SPF lookup count issues, and see which domains are sending without proper authentication before problems compound. The monitoring section of your multi-domain setup is not optional once you reach enforcement mode.

Common Multi-Domain Problems and What Causes Them

Problem: Some domains pass DMARC, others fail. Usually a DKIM selector mismatch. The selector domain does not match the From header domain for the failing domains.

Problem: All domains fail SPF. Likely an envelope-from mismatch. Check whether your mailing software is rewriting the bounce address or return path per domain. Some tools set a default envelope-from that does not match the sending domain.

Problem: DMARC fails after adding a new domain. New domain was added to the mail server but DKIM was not configured for it. Or the new domain is not a subdomain of the selector domain and strict alignment is in use.

Problem: SPF hits the 10-lookup limit suddenly. A third-party service was added to the sending infrastructure without checking the existing lookup count. The SPF record exceeded 10 lookups and started returning permanent errors instead of passing or failing.

FAQ

Can one mail server send for multiple domains with DMARC?
Yes, but only if SPF and DKIM are configured per domain or aligned correctly. DMARC alignment is the most common failure point, not the server itself.

How do I set up SPF for multiple domains on the same IP?
Use a centralized SPF subdomain. Create _spf.example.com with your server IPs. Have each sending domain include _spf.example.com. This keeps maintenance simple and avoids duplicating IPs across records.

Does DKIM work across all domains with one key?
Not by default. One DKIM key produces one selector domain. If that selector domain does not match your From header domains (in strict mode) or is not a parent domain (in relaxed mode), DMARC alignment fails. Most multi-domain setups need either per-domain DKIM keys or a shared parent-domain selector.

What happens if I move mail servers and forget to update SPF?
SPF is tied to IP addresses, not server names. If the new server uses the same IPs, SPF continues working. If the IPs change, all domains on that server fail SPF until the SPF record is updated. DKIM keys are tied to DNS, not server IPs, so DKIM continues working as long as the DNS keys are not removed.

The Short Version

Multi-domain email authentication on one server is solvable. Centralize your SPF with a shared include subdomain, configure DKIM selectors to align with your From header domains (or use relaxed alignment), and monitor your aggregate DMARC reports per domain.

The setup takes an afternoon. The monitoring saves you from silent failures that last weeks.