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

The Core Rule: One Sending Identity Per Domain

Every sending domain or subdomain needs its own SPF and DKIM records. One mail server does not change this. The mail server handles transport; the sending identity is the From address your users see.

If you run three domains from one Postfix instance, you need three SPF records, three DKIM records (or three selectors), and three DMARC records. The mail server does not collapse these into one. If you try to use a single SPF record across all three domains, two of them will fail when the IPs do not match.

This catches a lot of people off guard. They set up the mail server correctly, publish one SPF record, and then spend days wondering why two of their domains keep failing DMARC.

Step 1: Set Up Per-Domain SPF Records

Each domain needs its own SPF record. If example.com, example.org, and example.net all send mail from the same Postfix server at 203.0.113.50, each domain needs its own TXT record at its own domain.

For example.com:

v=spf1 ip4:203.0.113.50 ~all

For example.org:

v=spf1 ip4:203.0.113.50 ~all

For example.net:

v=spf1 ip4:203.0.113.50 ~all

The IP address is the same in each record. The domains are different. That is intentional. Each domain's DNS zone is a separate namespace, and SPF lookups are scoped to the domain in the envelope-from address, not the From header.

The "-all" at the end means "reject everything else" in hard fail mode. Change "~all" to "-all" only after you have confirmed legitimate mail is passing. Jumping to "-all" before testing is how you discover your billing system has been sending from a different IP range for two years.

Common mistake: copying one domain's SPF record and pasting it into another domain's DNS without changing the IPs. If example.org happens to have its own SPF record from a previous setup, you now have two "include" mechanisms pointing at different places, and neither domain works predictably.

Step 2: Set Up Per-Domain DKIM Signing

This is where most multi-domain setups quietly break.

Each domain needs its own DKIM selector. The signing domain (d=) in the DKIM signature must match the From domain for alignment to pass. If your From address is user@example.com, the DKIM signature must be from example.com, not from example.org.

There are two practical cases:

Case 1: Unrelated domains on one server (multi-tenant)

Each domain should sign with its own selector and its own key pair. With OpenDKIM, you configure a KeyTable and SigningTable that map each domain to its own private key:

KeyTable example.com:selector._domainkey.example.com
SigningTable example.com selector._domainkey.example.com

The DNS record for the public key goes at selector._domainkey.example.com as a TXT record.

Case 2: Same organization, domains that share a brand (example.com and mail.example.com)

These can share a DKIM key because the organizational domain is the same. example.com and mail.example.com both align under the same parent domain for DMARC purposes when relaxed alignment is in use. A single DKIM selector signing for both is valid.

The failure mode most people hit: they set up DKIM for example.com, it works, then they add example.org to the same mail server but forget to configure a separate DKIM selector for it. Example.org sends mail without a DKIM signature, DMARC alignment fails, and the admin spends an afternoon confused about why example.com still passes.

Step 3: Add DMARC Records

Each domain needs its own DMARC policy record at _dmarc.example.com, _dmarc.example.org, and so on.

For example.com with relaxed alignment:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; rf=afrf; sp=relaxed; adkim=relaxed

Key elements for multi-domain setups:

• p=none while you are testing. Move to quarantine or reject only after you have reviewed aggregate reports and confirmed legitimate mail is passing.
• rua sends XML aggregate reports to the address listed. Each domain should have its own rua target. You can use the same inbox for all of them, but the DNS records are per domain.
• adkim=relaxed means a DKIM signature from a subdomain of example.com will align with example.com. This is what makes multi-domain-per-server practical. Strict alignment (adkim=strict) requires an exact domain match and is rarely workable when you have several domains sending from the same server.
• sp=relaxed applies the same logic to subdomains of each domain in your policy record.

Relaxed alignment is not a compromise. It is the mode designed for exactly this use case: multiple domains under one administrative umbrella, sending from shared infrastructure.

Step 4: Read Aggregate Reports to Catch Failures

Aggregate reports (RUA) are the only way to know something is wrong before users complain. They arrive as XML attachments in your dmarc-reports inbox, usually once per day per domain. They tell you which sources are passing and failing DMARC for your domain, broken down by receiving organization.

At three domains, reviewing one report per domain per day is manageable. At twenty, it becomes a part-time job nobody does.

For multi-domain setups, aggregate reports are also the only way to catch the failure mode where a vendor reshapes mail and breaks alignment for a domain you thought was working fine. You will not see this in server logs. You will only see it in the aggregate data from the receiving mail system.

If you are managing more than three domains on one server, automated aggregation is not optional. Manually reviewing XML reports for each domain every day is a process that fails in week two. Tools that consolidate reports from multiple domains into a single dashboard remove the manual overhead and make it possible to act on the data instead of drowning in it. DMARCFlow is built for exactly this: teams running multiple domains who need one view of aggregate report data without manually processing separate XML files per domain.

To verify your setup is working: send a test message from each domain to a external address that can show you the authentication results (gmail, outlook.com, or a mailbox behind a strict DMARC policy). Then check your aggregate report inbox for the sending domain and confirm you see the test message listed with SPF pass, DKIM pass, and DMARC pass for that domain. If the test message arrived but does not appear in the report, check that your RUA address is receiving the XML attachments and that the sending domain's DMARC record points to the correct rua target.

Common Failure Modes

Forwarding reshapes mail and breaks alignment

When a message is forwarded, the forwarding server becomes the new sending relay from the receiver's perspective. The original SPF pass from your mail server no longer applies, and if the forwarding server does not sign with ARC, the original DKIM signature may no longer validate either. DMARC fails because the From domain in the message no longer matches the sending infrastructure that the receiver sees. This is not a configuration error on your end. Forwarding is the root cause, and you cannot prevent it with DNS records alone.

One DKIM key shared across unrelated domains

If you configure OpenDKIM to sign for multiple unrelated From domains using the same selector and key, the DKIM signature will only validate for one of them. The other domains will show DKIM failures in aggregate reports, and DMARC will fail for those domains even though the signing infrastructure is technically working.

Subdomains sending mail without their own SPF records

If sales.example.com sends its own mail but only example.com has an SPF record, the sales subdomain will fail SPF checks at every receiver that does SPF lookups. This is a common oversight when subdomains are added without updating DNS.

Vendors sending on your behalf

When a marketing platform, billing system, or CRM sends email using your From domain, it must do one of three things: send through your mail server so your SPF and DKIM apply; sign with a DKIM key under your domain so alignment passes; or accept that DMARC will fail at receivers that validate DKIM. The third option means your domain fails DMARC checks at receivers like Gmail, Microsoft, and Yahoo every time that vendor sends. If that vendor sends transactional email or receipts, you are ticking time on a deliverability problem you will only notice when open rates drop.

Frequently Asked Questions

Do I need a separate DKIM key for each domain?

If the domains are unrelated and share only the mail server, yes. DKIM signatures are scoped to the signing domain (d=), and alignment requires the d= domain to match or be a subdomain of the From domain. Unrelated domains with different From addresses need different DKIM selectors. If example.com and example.org are both sending from the same server, they need different DKIM configurations, not because of the server but because of how DKIM alignment works.

What does relaxed alignment mean for multi-domain setups?

Relaxed alignment (adkim=relaxed) allows the DKIM signature domain or the SPF domain to be a subdomain of the From domain. For example, a DKIM signature from mail.example.com will align with example.com under relaxed mode. Strict alignment (adkim=strict) requires an exact match. For most multi-domain mail server setups, relaxed alignment is the only workable mode. Without it, every subdomain that sends mail directly would need its own DKIM key and its own DMARC record.

A vendor sends mail from our domain. What needs to change?

The vendor needs to send either through your mail server (so your SPF/DKIM apply) or sign with a DKIM key under your domain (so alignment passes). If neither is possible, you need to update your DMARC policy to accept the alignment failure, which means moving to a mode where you monitor the failure rate rather than enforce against it. Enforcing DMARC reject against a vendor you do not control will break their mail.

How do we monitor aggregate reports for ten or more domains without it being a full-time job?

At ten domains, manually reviewing XML reports is not sustainable. Most teams start with a shared inbox, move to a spreadsheet tracker, and then abandon both within a few weeks when the volume becomes unmanageable. Automated aggregation that consolidates reports from all domains into one interface is the practical solution. If you are at five domains and still reading XML every morning, start looking at tools before the problem gets worse.

Does each subdomain need its own SPF and DKIM records?

If the subdomain sends mail directly (not through your main mail server), it needs its own SPF record. For DKIM, if the subdomain uses the same mail server as the parent domain and the DKIM is signed from the parent domain's selector, relaxed alignment means it will pass. If the subdomain sends through a different service or has its own signing infrastructure, it needs its own DKIM configuration.

The Short Version

One sending identity per domain. One DKIM key per domain or domain family. One SPF record per domain. Relaxed alignment (adkim=relaxed) is what makes this work in practice.

If you are running more than three domains from one mail server and you are not reviewing aggregate reports for each domain, you are flying blind. Legitimate mail is failing silently, and you will only find out when a user complains or a domain gets flagged. Aggregate reports are the only early warning system you have. At scale, automated aggregation is the only reliable way to use them.