How to Configure SPF, DKIM, and DMARC for Multiple Domains

The Core Problem with Multi-Domain Email Authentication

If you run one mail server for two domains, say example.com and example.org, and you send a newsletter from newsletter@example.org while your mail server identifies itself as mail.example.com, DMARC will flag that message. Not because something is broken, but because the domains do not align.

This trips up a lot of people. They set up SPF and DKIM correctly. The mail server signs the message. SPF passes. DKIM verifies. And yet DMARC reports show failures. The reason is usually a mismatch between the domain that sends the mail and the domain that appears in the From header.

Understanding this alignment problem is the key to making multi-domain email authentication work.

How SPF Works Differently Across Domains

SPF checks the Return-Path domain, also called the envelope-from domain. This is the domain your mail server uses when it delivers mail. It is usually the same as your mail server's hostname, not the From header domain your recipients see.

If your mail server identifies as mail.example.com and you send mail with a From header of newsletter@example.org, SPF checks mail.example.com. That SPF record might pass. But DMARC then checks whether the From header domain (example.org) aligns with the Return-Path domain (example.com). It does not. DMARC fails.

Each domain you send From needs its own SPF record that covers the actual sending infrastructure.

The practical rule: for every domain you use in a From header, make sure the Return-Path domain either matches exactly or is explicitly included in your SPF record via the include mechanism.

One common mistake is publishing a single large SPF record for all domains, then sending from domains whose Return-Path domains were not included. Another mistake is using a shared mail server hostname that belongs to one domain but sending from another domain's From address without proper SPF includes.

DKIM: Shared Key vs Per-Domain Keys

DKIM signs the message content with a private key. Receivers verify the signature using the public key published in DNS. The question for multi-domain setups is whether to use one DKIM key across all domains or generate separate keys per domain.

Option A: Shared DKIM key

You generate one DKIM key pair on your mail server and publish the public key under your mail server's domain, say mail._domainkey.example.com. Every domain that sends through this server uses the same DKIM signature.

This works if all your sending domains share the same mail server and you use relaxed DMARC alignment. Under relaxed alignment, subdomains of the DKIM domain can align with the From header domain. But if your From header is example.org and your DKIM domain is example.com, those are sibling domains, not parent and child. Relaxed alignment does not help here. You would need strict alignment, which requires exact domain match.

The practical result: shared DKIM keys across sibling domains almost always fail strict alignment and often fail relaxed alignment too.

Option B: Per-domain DKIM keys

You generate a separate DKIM key pair for each sending domain. For example.com you publish under example.com._domainkey.example.com. For example.org you publish under example.org._domainkey.example.org. Each domain gets its own DKIM signature matching its own DNS record.

This is more work to set up, but it means every domain aligns perfectly with its own DKIM key. DMARC passes under both relaxed and strict alignment.

Option C: Third-party relay or ESP

If you use SendGrid, Mailgun, Amazon SES, or any third-party relay, the DKIM keys belong to that provider. You typically add DNS records under your own domain to authorize the provider's signing. In this case you follow the ESP's multi-domain setup guide. Most providers handle DKIM signing on your behalf across multiple domains, but you usually need to add separate DNS records for each domain.

DMARC Alignment: Relaxed vs Strict

DMARC alignment is what causes the most surprises in multi-domain setups.

Relaxed alignment means the organizational domain of the DKIM-signed domain or the SPF checked domain can match the organizational domain of the From header. Organizational domain is the registered domain, stripped of subdomains. So mail.example.com and newsletter@example.org have the same organizational domain (example.com and example.org are different). But mail.example.com and sub.example.com share the same organizational domain.

Strict alignment means the From header domain must exactly match the DKIM-signed domain or the SPF Return-Path domain. No subdomain allowance. No sibling domain allowance.

For multi-domain setups, relaxed alignment gives you more flexibility, but only if your DKIM keys and SPF records are configured to cover sibling domains properly.

The trap is assuming relaxed alignment will paper over configuration gaps. It will not. If your DKIM domain is example.com and your From header is example.org, relaxed alignment treats these as different organizational domains. Alignment fails regardless of the mode.

The solution is per-domain DKIM keys and SPF includes that cover each sending domain explicitly.

Step-by-Step Configuration

Step 1: Define your sending domains

List every domain you use in From headers. For each one, identify whether it shares a mail server with other domains or uses a separate relay.

Step 2: Set up SPF per domain

For each sending domain, create or update the SPF record to include all IP addresses and third-party senders that deliver mail for that domain.

Example for example.com:


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

Example for example.org (different IP, same server hostname):


v=spf1 ip4:203.0.113.20 include:_spf.example.org ~all

Do not reuse the same SPF record across domains unless the Return-Path domains are identical. They rarely are.

Step 3: Generate DKIM keys per domain

On your mail server, generate a DKIM key pair for each domain. Most Postfix and Exim installations use opendkim or opendmarc. Configuration typically looks like:


Domain example.com
KeyFile /etc/opendkim/keys/example.com/private
Selector mail

Repeat this for every sending domain, pointing each to its own key file.

Step 4: Publish DKIM DNS records

For each domain, publish the DKIM public key to your DNS. The selector (in this case mail) forms the record name: mail._domainkey.example.com. The TXT record value is the public key.

Step 5: Create DMARC records per domain

Start with p=none while you verify alignment:


v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100;

Once you confirm passing results in aggregate reports, move to quarantine then reject.

Each domain needs its own DMARC record. They do not inherit from a parent domain.

Step 6: Verify with free tools before going live

Run through each domain with DMARCFlow's Domain Setup Wizard before you start monitoring. It validates SPF, DKIM, and DMARC configuration in one pass and flags the specific problems that cause multi-domain setups to fail, like missing DKIM keys for sibling domains or SPF records that include IPs from only one of your sending domains.

The SPF Record Checker is useful for multi-domain setups specifically. As you add include statements for different sending services, it is easy to approach or exceed the 10 DNS lookup limit without realizing it. The tool shows you the current lookup count so you can flatten the record before it breaks.

How to Check If Your Setup Is Working

DMARC aggregate reports tell you whether messages are passing or failing alignment. A clean report shows near-zero failures from your legitimate sending infrastructure.

When reviewing aggregate reports across multiple domains, look at failures per source IP per domain. A common pattern in multi-domain setups is seeing DKIM failures for one domain while all other domains pass. That tells you exactly which domain has a missing or misconfigured DKIM key, rather than a systemic problem.

A concrete example: a company running Postfix for example.com and example.org published the same DKIM key under mail._domainkey.example.com for both domains. When they sent from example.org, the DKIM signature verified against example.com but the From header was example.org. Alignment failed. The aggregate report showed DKIM failures only for example.org, not example.com. Switching to per-domain DKIM keys fixed it immediately.

If you do not yet have aggregate reports set up, DMARCFlow's DMARC Record Checker can validate your current DNS records directly. It shows whether your DMARC, DKIM, and SPF records are actually present and correctly formatted for each domain, without waiting for a receiver to send you a report.

When to Move to p=reject with Multiple Domains

Do not set p=reject until you have confirmed that all legitimate mail is passing DMARC for every domain. With multiple domains, this means verifying each domain separately and waiting long enough to capture all your regular sending patterns, including automated mailings and transactional email.

The phased approach:

1. p=none for 2-4 weeks. Review aggregate reports weekly. Fix failures before proceeding.
2. p=quarantine for 2-4 weeks. Mail failing DMARC goes to spam or quarantine. Monitor for legitimate mail getting blocked.
3. p=reject. Only after you have zero failures from legitimate sources across all domains for at least two consecutive weeks.

The risk with multiple domains is that a misconfiguration on one domain affects all domains using the same mail server. If you set p=reject and one domain has an undetected SPF or DKIM problem, legitimate mail from that domain gets hard rejected.

FAQ

Can I use the same DKIM key for all my domains?

You can, but it only works under strict alignment if the DKIM domain matches the From header domain exactly. For sibling domains like example.com and example.org, you need separate DKIM keys for each domain.

Does each domain need its own SPF record?

Yes. SPF is checked against the Return-Path domain, which is specific to each sending domain. If you send from both example.com and example.org, each needs its own SPF record covering the actual sending infrastructure.

What is the difference between relaxed and strict DMARC alignment?

Relaxed alignment allows subdomains to match the organizational domain. Strict alignment requires exact domain match. Relaxed is the default and more forgiving, but it does not allow sibling domains like example.com and example.org to align.

How do I know if my subdomains are covered by DMARC?

If the parent domain has a DMARC record with rua= defined, aggregate reports cover all subdomains that send mail. The DMARC record itself does not need to be published on subdomains unless they need different policies.

What happens when I forward mail with DMARC enabled?

Forwarding typically breaks DKIM because the forwarder resends the message and most forwarders do not preserve the original DKIM signature. SPF can still pass if the forwarder is authorized, but DMARC alignment fails because the forwarding mail server's domain does not match the original From header domain. This is a known limitation of DMARC, not a misconfiguration on your end.

Can I use DMARCFlow to monitor multiple domains?

Yes. DMARCFlow supports multiple domain monitoring. Each domain is tracked separately. The free tools can verify configuration for any domain without requiring an account.