How to Set Up SPF, DKIM & DMARC for Multiple Domains

Running two, five, or fifty domains from a single mail server is common. It reduces infrastructure cost and simplifies operations. The complication is that SPF, DKIM, and DMARC were designed around single-domain setups. Each protocol handles multiple domains differently, and the mistakes that break mail are not obvious until you are already getting reports of undelivered messages.

The core challenge is this: your mail server is one machine, but the email authentication standards think in terms of one domain per message. When a message arrives from example.com, SPF checks the server IP against example.com's SPF record. DKIM verifies a signature attached to example.com. DMARC checks whether SPF and DKIM results align with the header-from domain. None of these checks know that you also manage example.org and example.net on the same server.

The operational problem is even larger than the technical one. When you run five domains from one server, you have five sets of SPF records, five DKIM keys (or one shared across five), five DMARC policies, and five sets of aggregate reports landing in five different inboxes. Without a monitoring tool that consolidates this, you are managing five separate authentication configurations manually, and the chance of missing a failure on one domain grows with every domain you add. DMARCFlow is built to monitor SPF, DKIM, and DMARC across all your domains from a single dashboard, which is the main reason multi-domain setups end up broken: not the technical complexity, but the monitoring gap.

Step 1: Plan Your SPF Setup Before Adding Domains

SPF has a hard limit of 10 DNS lookups per record. Exceed it and the record fails to resolve, which means the receiving server treats your SPF check as a permanent error rather than a pass or fail.

For a single domain this is rarely a problem. With five domains each referencing the same mail server plus a handful of third-party services, the lookups add up faster than you expect. A typical vendor include like include:sendgrid.net counts as one lookup, but that vendor's own SPF record may include three more, which means you are burning four lookups on one vendor.

The shared SPF include approach helps. Instead of each domain having its own verbose record, centralise your SPF configuration into one include record that all domains reference:

example.com: v=spf1 include:_spf.example.com ~all
example.org: v=spf1 include:_spf.example.com ~all
_spf.example.com: v=spf1 ip4:YOUR_SERVER_IP include:sendgrid.net include:support.example.com ~all

Now each domain has exactly one lookup, and all the complexity lives in the central _spf.example.com record. When you add a new sending service, you update one record instead of five.

If you have many domains and many third-party senders, even the shared include approach can exceed 10 lookups. The fix is subdomain-per-sender: your mail server sends from primary.example.com, your marketing platform sends from marketing.example.com, your support tool sends from support.example.com. Each subdomain has a minimal SPF record with only the lookups it actually needs. This keeps every record well under the limit.

Step 2: Generate and Deploy DKIM Keys Per Domain

DKIM requires a public-private key pair. The private key lives on your mail server and signs outgoing messages. The public key is published as a DNS TXT record on the domain you are signing mail for.

For multiple domains you have two strategies.

Option A: One DKIM key shared across all domains

Your mail server signs every outgoing message with the same private key, regardless of which domain the message is from. You publish the matching public key as a DKIM record on each domain under the same selector.

This works cleanly for DMARC alignment because the DKIM signature domain matches the header-from domain. It is simpler to operate: one key to rotate, one DNS record to update per domain when rotation happens. The tradeoff is that a compromised key affects every domain simultaneously.

Option B: Separate DKIM keys per domain

Each domain has its own DKIM selector and key pair. Your mail server signs mail with the appropriate key based on which domain the message is from.

This provides better key isolation but increases operational complexity. Key rotation means updating DNS for every domain individually. Large hosting companies and MSPs usually run Option B because limiting the blast radius of a compromised key to one client domain is worth the operational overhead.

For setups with fewer than 20 domains, Option A is usually sufficient and far easier to manage. The key is publishing the same public key consistently across all domains under the same selector name, usually something like selector._domainkey.example.com.

Before going live, test each domain by sending a message to a DMARC checker and confirming that DKIM verifies correctly for each one.

Step 3: Configure DMARC Records for Each Domain

Each domain needs its own DMARC record. The record lives at _dmarc.example.com as a TXT record. For a domain that sends mail and is ready to enforce:

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

The policy flags are:

p=none: monitor only, no action on failures

p=quarantine: failed mail gets marked as suspicious

p=reject: failed mail is dropped

Each domain needs its own p= setting based on that domain's sending maturity. Do not assume a domain should inherit the same policy as your primary domain.

Subdomain inheritance works differently than most people expect. If newsletters.example.com sends mail but has no DMARC record, it does not automatically inherit example.com's policy. It inherits the policy of its own organisational domain, which means it needs its own record. The only time a subdomain inherits from a parent is when it is explicitly part of the same organisational domain and the parent record includes the "o=-" tag to designate it as the organisational domain boundary.

The practical rule: give every domain that sends mail its own DMARC record, starting at p=none, and promote each one to p=reject independently based on its own sending history.

Step 4: Understand DMARC Alignment

DMARC alignment is what makes multi-domain setups tricky. For a message to pass DMARC, either the SPF domain or the DKIM domain (or both) must align with the header-from domain.

There are two alignment modes. Relaxed alignment (adkim=r, the default) means a subdomain like mail.example.com aligns with example.com, so a DKIM signature from example.com satisfies the alignment requirement for a message with a header-from of mail.example.com. Strict alignment (adkim=s) requires an exact domain match, so mail.example.com would not align with example.com.

Relaxed alignment is the right choice for almost every multi-domain setup. It accommodates the reality that your mail server infrastructure often operates at the organisational level while individual domains or subdomains handle specific sending functions.

If you are using Option A with one shared DKIM key, make sure your DKIM signature uses the organisational domain as the signing domain. This ensures alignment works correctly across all domains without separate DKIM keys for each one.

Step 5: Common Mistakes That Break Multi-Domain Mail

Missing SPF records on subdomains that send mail

This is the most frequent cause of unexpected DMARC failures after going live. If newsletters.example.com sends through a marketing platform and nobody added an SPF record for newsletters.example.com, that subdomain inherits whatever DMARC policy is in effect. When the platform's server is not in any SPF record, SPF fails, and if DKIM is also not configured, DMARC fails too.

The fix: audit every subdomain that sends mail, including ones that send only occasionally. For each one, either add an explicit SPF record or set a local DMARC record with p=none so it does not inherit a reject policy unexpectedly.

One DKIM key published incorrectly across domains

If you publish the same DKIM public key for multiple domains but the selector names differ, your mail server signs correctly but the DNS record does not match. The receiving server looks up selector._domainkey.example.com but finds nothing because the record is published under a different selector name.

The fix: use the same selector name consistently. If you use selector1 as your selector, publish selector1._domainkey.example.com on every domain that shares the key.

Forgetting to add new domains to monitoring

When a new domain is added to your server, it starts sending immediately. If you have not yet published a DMARC record for it, you have no aggregate report visibility. That means you do not know what is being sent on that domain's behalf until a receiving server rejects it and a user complains.

Add domain onboarding to include publishing a DMARC record and configuring aggregate report delivery before the domain starts sending mail.

Misconfigured aggregate report addresses

Each domain needs an rua target that actually receives and monitors reports. If the report address is on a domain that is not yet protected, or if it points to an unmonitored inbox, you will miss the data you need to catch problems early.

Use a dedicated inbox or a DMARC monitoring tool for aggregate reports. Reading XML reports by hand is time-consuming enough that most teams stop doing it, which means they miss the early warning signs.

Step 6: Test Before Going Live

Before changing DNS records to enforce policies, run through this checklist:

Send a test message from each domain through your server to a DMARC testing service. Confirm that SPF, DKIM, and DMARC all report as pass for each one individually.

Run a DMARC lookup on each domain using a DMARC checker. Confirm the record resolves correctly and reports are being delivered to the address you specified.

If moving from p=none to p=reject, set pct=50 first. Monitor for 24 to 48 hours. If nothing breaks, increase to pct=75, then to pct=100. The percentage mechanism catches failures on a subset of mail before you commit to full enforcement.

Check aggregate reports within 24 hours of any policy change. Look for sending sources that were not in your planning analysis. New sources at this stage mean your initial audit was incomplete.

How Multi-Domain Monitoring Changes the Risk Profile

Once you have configured SPF, DKIM, and DMARC across multiple domains, the ongoing risk is not misconfiguration. It is change. A new marketing platform gets provisioned. A business unit adopts a new SaaS tool that sends from your domain. An acquisition brings a new domain onto your mail server. Each of these events changes your sending landscape without notifying your DNS records.

In a single-domain setup, you notice these changes quickly because you are watching one set of reports. In a multi-domain setup, you can go weeks without noticing that a new source has appeared on a domain you check less frequently. By the time you notice, the new source is sending mail that fails DMARC, and you are dealing with a deliverability problem instead of a simple DNS update.

This is the operational reality that makes multi-domain email authentication harder than single-domain setups. The configuration is a one-time task. The monitoring is ongoing, and it is the part that determines whether your authentication setup stays effective or slowly degrades.

DMARCFlow addresses this directly. The multi-domain view in DMARCFlow shows you passing and failing DMARC status across all your domains in one screen. When a new sending source appears on any domain, you get an alert immediately, not when a user reports a bounced message. When you are ready to move a domain from p=none to p=reject, the aggregate reports in DMARCFlow give you the full sending picture for that specific domain before you change the policy, so you are not guessing about whether the domain is ready.

FAQ

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

Yes. Publish the same public key in each domain's DKIM DNS record using the same selector. The mail server signs all outgoing mail with the same private key. As long as the signing domain in the DKIM signature matches or aligns with your header-from domain, DMARC will pass. The tradeoff is that a compromised key affects all domains at once. For most organisations with fewer than 20 domains, the operational simplicity is worth the risk.

What if a third-party service sends mail from my domain without being in my SPF record?

Their mail fails SPF because your SPF record does not authorise their server. If they are also not DKIM-signing with your key, both SPF and DKIM fail, and DMARC fails. The receiving server may quarantine or reject the message. The fix is to either add the third-party to your SPF record or configure them to DKIM-sign mail at your domain.

Should each domain have its own DMARC policy?

Each domain needs its own DMARC record with its own p= setting. Set each domain's policy based on that domain's own sending maturity. Your primary brand domain might be at p=reject after months of clean reports. A new domain you just added should be at p=none until you have verified its sending behaviour. Managing them independently is not optional.

How do I know if my SPF records are hitting the 10-lookup limit?

Use an SPF lookup tool to check your record. Most SPF checkers show the total lookup count and break down which includes contribute to it. If you are at or above 10, consolidate redundant includes or switch to an SPF flattening approach where you replace includes with their resolved IP addresses.

My domains are on different servers. Do I still need multi-domain SPF/DKIM/DMARC setup?

Yes. DMARC alignment is based on the header-from domain shown to recipients, not the sending server's location. Each domain that sends mail needs its own SPF record pointing to its own servers, its own DKIM signature from its own signing infrastructure, and its own DMARC policy. The fact that the servers are different does not change the authentication requirements or the multi-domain complexity.