How to Configure SPF, DKIM & DMARC for Multiple Domains

If you run one mail server for multiple sending domains and need to configure SPF, DKIM, and DMARC correctly for all of them, this guide covers what most setups get wrong.

The core problem: each domain needs its own authentication records, and those records must align with each other. When you copy a record template from domain1 to domain2 without adjusting it, DMARC alignment fails even if the underlying configuration is correct.

This guide covers the correct configuration for multi-domain setups, common mistakes that cause authentication failures, and how DMARCFlow simplifies ongoing monitoring across all your domains.

Why Multi-Domain Authentication Is Harder Than It Looks

When you run one mail server for multiple sending domains, the naive approach is to copy the same DNS record template across all of them. That usually breaks.

The problem is that SPF, DKIM, and DMARC all have alignment rules. A record that works for domain1.com may not work correctly for domain2.com because the alignment domain does not match. DMARC in particular requires that the domain in the RFC5321 From header (the sender domain) matches the domain used in SPF and DKIM validation.

When you have five domains on one server, you need five separate SPF records, DKIM keys for each domain (or selectors configured correctly), and DMARC records that account for subdomain usage across all five.

SPF for Multiple Domains on One Server

Each sending domain needs its own SPF record. Even if all domains send from the same IP address, the SPF record must be published for each domain individually.

The SPF mechanism include can reference a common SPF template, but the domain in the include must match the domain that is actually sending:

For domain1.com:


v=spf1 ip4=203.0.113.1 include:_spf.domain1.com ~all

For domain2.com:


v=spf1 ip4=203.0.113.1 include:_spf.domain2.com ~all

If domain2.com uses include:_spf.domain1.com but mail actually originates from domain2.com's servers, the SPF check fails because the domains do not align.

A common mistake: using include:_spf.mailprovider.com for every domain without checking whether the include is scoped to that specific domain. Some mail providers issue separate include values per sending domain.

When a subdomain also sends mail, include the subdomain in the parent domain's SPF record using include:_spf.subdomain.domain.com or add an explicit include for the subdomain's sending infrastructure.

DKIM for Multiple Domains

DKIM works by signing outbound mail with a private key. The receiving server decrypts the signature using the public key published in DNS.

For multi-domain setups, you have two main approaches:

One DKIM key per domain

Each domain gets its own DKIM selector and private key. This is the cleanest approach because each domain's DKIM signature uses its own domain in the d= parameter, matching the RFC5321 From header correctly.

Selector record (published as a TXT record for selector mail):


mail._domainkey.domain1.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."

Domain1.com signs with selector mail, and the d= parameter in the signature is domain1.com. The receiving server looks up mail._domainkey.domain1.com and validates the signature against that domain.

Shared selector with proper domain matching

If your mail server generates DKIM signatures automatically and uses the same selector for all domains, the d= parameter in the signature must match the domain that is sending. Some advanced MTA configurations handle this by setting the d= value per-domain at signing time.

The failure mode to avoid: a DKIM signature where d=domain1.com but the message is from domain2.com. DMARC alignment fails and the message is rejected or flagged.

When you add a new domain to an existing multi-domain server, check whether your DKIM signing configuration automatically sets the correct d= value for the new domain. Many automated setups default to the primary domain and must be reconfigured per-domain.

DMARC Alignment for Multi-Domain Setups

DMARC requires alignment between the RFC5321 From domain and the domains used in SPF and DKIM validation. In a multi-domain environment, this means every sending domain needs a DMARC record.

The aspf and adkim tags control alignment strictness:

aspf=s (strict): the RFC5321 From domain must match exactly
aspf=r (relaxed, default): the RFC5321 From domain must match or be a subdomain
adkim=s / adkim=r: same behavior for DKIM alignment

For most multi-domain setups, relaxed alignment (aspf=r, adkim=r) is practical during initial rollout. Once you have confirmed that all legitimate mail passes alignment, tightening to strict alignment catches more misconfiguration.

Example DMARC record for domain1.com:


_dmarc.domain1.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@domain1.com; aspf=r; adkim=r"

For domain2.com:


_dmarc.domain2.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@domain2.com; aspf=r; adkim=r"

Note that each domain has its own rua reporting address. Aggregate reports are sent per-domain, so you need reporting configured for every domain you manage.

Subdomain handling

If subdomains send mail and should be covered by the same DMARC policy as the parent domain, use the sp tag or align subdomain policy to the parent:


_dmarc.domain1.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@domain1.com; sp=quarantine; aspf=r; adkim=r"

Without the sp tag, subdomain policy defaults to p=none unless a separate _dmarc.subdomain.domain1.com record is published.

Record Management Pitfalls

TXT record limits

DNS TXT records have a 255-character per-string limit. Long DKIM keys (typically 2048-bit RSA keys are 344+ characters in base64) must be split into multiple strings within the same TXT record. When you copy a DKIM record from a provider's dashboard, verify that it has not been truncated.

A correctly formatted DKIM TXT record looks like:


selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PUBLICKEYBASE64VALUEHERE"

The entire value including quotation marks is one TXT record. If your DNS provider dashboard splits it into multiple records or adds extra line breaks, validation fails.

Propagation delays

When updating SPF, DKIM, or DMARC records for multiple domains simultaneously, remember that DNS propagation is not instant. TTL values control caching behavior. If you reduce a TTL before making changes, propagation happens faster. If you increase it during maintenance, changes take longer to propagate to all recursive resolvers.

For a multi-domain rollout, set low TTLs (300 seconds or less) before making changes, update all domain records, then restore higher TTLs after propagation is confirmed.

Propagation check

Do not assume that because your local resolver shows the new record, all receiving mail servers can see it. Use an independent DNS lookup tool that queries from multiple geographic locations before assuming a record is globally visible.

Quick Checklist: Adding a New Domain to an Existing Multi-Domain Setup

When you add domain7.com to an existing server that already handles domain1 through domain6:

1. Confirm the mail server's outbound IP or include mechanism matches the new domain's SPF record
2. Generate or assign a DKIM key for domain7.com with the correct selector
3. Verify the DKIM signing configuration sets d=domain7.com in the signature (not the primary domain)
4. Publish the DMARC record for domain7.com starting at p=none
5. Configure aggregate report collection for _dmarc.domain7.com
6. Wait for first aggregate report and confirm authentication pass rates before tightening policy
7. Add monitoring for the new domain alongside existing domain monitoring

FAQ

Can I use the same SPF record for all my domains if they send from the same server?

No. Each domain needs its own SPF record published in its own DNS namespace. You can use an include mechanism that points to a common template, but the include value must be scoped to the correct domain. Using include:_spf.primary.com for all domains breaks SPF alignment when the sending domain is not primary.com.

What happens if my DKIM selector is on a different domain than my sending domain?

The DMARC alignment check fails. The d= parameter in the DKIM signature must match the RFC5321 From domain. If you sign as d=marketing.com but send from d=example.com, DMARC rejects the alignment. Some mail providers handle multi-domain DKIM by configuring the MTA to sign with the correct domain per-message.

How do I handle subdomains that also send mail?

Add the sp tag to your DMARC record to specify subdomain policy. Without it, subdomains default to p=none. If a subdomain sends mail from a different infrastructure than the parent domain, publish a separate _dmarc.subdomain.example.com record to give it its own policy and reporting.

Should I use the same DKIM key across all my domains?

Technically possible but not recommended. Sharing a DKIM key means sharing a selector. If that selector's private key is ever compromised, all domains using it are affected. One key per domain with dedicated selectors is safer and makes revocation simpler.

How does DMARCFlow handle monitoring for multiple domains?

DMARCFlow collects aggregate reports from all configured domains and consolidates them into a single dashboard. When you add a new domain, you update the reporting address and DMARCFlow begins collecting immediately. SPF and DKIM coverage checks run across all domains, and you receive alerts when a new sending source appears in reports for any domain you monitor.

What Good Multi-Domain Authentication Looks Like

A correctly configured multi-domain setup has:

One SPF record per domain, each referencing the correct sending infrastructure

DKIM keys assigned per-domain with selectors configured to sign with the correct d= value

DMARC records for every sending domain with p=none during initial rollout

Aggregate report collection configured for each domain

A monitoring system that surfaces authentication failures across all domains, not just one

The operational challenge grows as you add domains. Each new domain is a new failure point if its records are misconfigured. With DMARCFlow, aggregate report collection and SPF/DKIM coverage checks run automatically across all domains you configure. When a new sending source appears in reports for any domain, or when DKIM alignment starts failing on a domain you have not touched recently, DMARCFlow sends an alert. You do not have to check each domain's reporting mailbox manually.

The checklist above covers setup. DMARCFlow handles the ongoing part: keeping track of all your domains without requiring you to log into each one separately.