DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Dmarc

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

By DMARCGuardian Editorial Team ·

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

The question comes up regularly in mail admin communities: you have one mail server handling three domains, or maybe twenty. You need SPF, DKIM, and DMARC working for all of them. Every guide you find explains the single-domain case. This one explains what changes when the same server sends for multiple sending domains.

The short answer is that every sending identity still needs its own DNS records. The mail server is the transport. The From address on the envelope and the From address in the message header are the sending identities. One server handling multiple domains means multiple sets of DNS records, one per domain. It is not complicated, but it is easy to get wrong if you assume one shared config will cover everything.

---

The Core Rule: One Sending Identity Per Domain

Before touching DNS, understand what you are actually protecting. SPF authorizes the server that sends mail. DKIM signs the message content with a cryptographic key. DMARC ties both of those to the From domain and tells receiving servers what to do when alignment fails.

When you run one mail server for multiple domains, each domain is a separate sending identity. That means each domain needs its own SPF record, its own DKIM key and selector, and its own DMARC policy record. The mail server running Postfix or Exim or Haraka does not care how many domains you host. The DNS records do.

This is the part that catches people. One amavisd instance, one OpenDKIM instance, one server IP. But that server is sending as hello@example.com and hi@example.org and bye@fictional.org. Each of those needs its own authentication chain.

---

Step 1: Set Up Per-Domain SPF Records

SPF lives in DNS as a TXT record at the domain you are authorizing. For a single domain example.com hosted on mailserver.example.net, the SPF record at example.com looks like:


v=spf1 ip4:203.0.113.50 -all

Add a second domain and the record at example.org looks the same, but points at the same IP:


v=spf1 ip4:203.0.113.50 -all

Both domains authorize the same mail server IP. The records are separate because they live at different domain names. That is all SPF is: a statement from each domain about which servers are allowed to send mail on its behalf.

When you have more going on, say a marketing platform sending newsletters and a transactional service sending receipts, the record grows:


v=spf1 ip4:203.0.113.50 include:mailchimp.com include:sendgrid.net -all

Copy this structure to each domain. Each one gets its own record authorizing the same set of sending sources. Do not forget the -all at the end. ~all (softfail) is not the same as -all (fail). If you are ready to enforce, use -all.

Common mistake: copying a record from one domain to another without checking whether the included IPs and services apply to both. If example.org does not use SendGrid, do not include it in that domain's SPF record.

---

Step 2: Set Up Per-Domain DKIM Signing

DKIM adds a cryptographic signature to message headers. The receiving server uses the public key published in DNS to verify that signature. The signing happens on your mail server. The key pair lives on the server (private key) and in DNS (public key).

For multiple domains, you have two choices. The easy choice is one key pair shared across all domains. This works as long as the DKIM signing domain (d=) matches the From domain or is a parent of it. The problem comes when different business units or different teams manage different domains and someone asks why one domain's DKIM key is signing mail for another domain.

The right choice for most multi-domain setups is separate DKIM selectors per domain. Here is why:

  • Domain A sends mail. Its DKIM signature has d=example.com.
  • Domain B sends mail. Its DKIM signature has d=example.org.
  • Both are signed by the same mail server, but the signatures are distinct.
  • If one domain's key is compromised, only that domain's signatures are forged.
  • Aggregate reports show DKIM results per domain, not per server.

With OpenDKIM, you define multiple KeyTable and SigningTable entries:


KeyTable     refile:/etc/opendkim/KeyTable
SigningTable  refile:/etc/opendkim/SigningTable

Each entry maps a selector to a domain and private key path. The SigningTable uses domain patterns so one config covers all your hosted domains.

With Amavisd-new, you define per-domain DKIM keys by adding domain entries to @dkim_signature_options_bysender_maps. Each domain gets its own private key stored in a separate directory.

The DNS TXT record for one domain's DKIM public key looks like:


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

Repeat this per domain. The selector name (the part before _domainkey) can be the same across domains if each has its own key file. Or you can use different selector names. It does not matter as long as the matching selector is used at signing time and published in DNS.

---

Step 3: Add DMARC Records

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

The minimal record starts with monitoring mode:


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

This tells receiving servers to send aggregate reports to dmarc-reports@example.com but take no action on failures. You stay here until you have reviewed enough reports to know what legitimate mail looks like for this domain.

When you are ready to enforce, the record looks like:


v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; rf=afrf

Or for full rejection:


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

For multi-domain setups, the practical choice is relaxed alignment mode. DMARC alignment has two modes:

  • Strict: the From domain must exactly match the DKIM signing domain (d=) and the SPF envelope domain.
  • Relaxed: the From domain must match or be a subdomain of the DKIM signing domain and the SPF envelope domain.

Relaxed alignment means example.com and mail.example.com can both pass alignment if they are covered by the same DKIM key or SPF record. This is what makes multi-domain servers workable. Without relaxed alignment, any subdomain sending mail directly would fail alignment.

Your multi-domain DMARC record:


v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; rf=afrf; adkim=r; aspf=r

The adkim=r and aspf=r are explicit relaxed modes. p=quarantine sends failing mail to spam rather than rejecting it outright. Keep p=quarantine for at least two weeks after moving from p=none. Review the aggregate reports every few days before going to p=reject.

---

Step 4: Read Aggregate Reports to Catch Failures

Aggregate reports (RUA) arrive daily from every major receiving server (Gmail, Microsoft, Apple, Yahoo, and hundreds of others). They come as XML files attached to emails. The subject line is "DMARC Report for [your domain]." They are not human-readable by default.

Each report tells you:


  • which IP addresses sent mail claiming to be from your domain

  • whether SPF and DKIM passed or failed for each source IP

  • whether alignment passed or failed

  • an approximate volume count

For one or two domains, you can download a free XML viewer tool and check manually every week. For five or more domains, manual review stops happening.

This is where monitoring tools matter. DMARC aggregate reports are only useful if someone reads them. A tool that parses the XML and shows you the summary (pass/fail rates per domain, new IPs appearing, sudden drops in volume) turns a tedious manual task into something a busy admin can do in five minutes.

DMARCFlow is designed for this. You point your DMARC records at a DMARCFlow-hosted inbox, and the dashboard shows you authentication results across all your domains in one view. For MSPs managing client domains, this is the practical path rather than trying to review separate XML reports per client domain.

If you prefer to stay manual, at minimum set up a dedicated inbox for DMARC reports and check it when you change any authentication record.

---

Quick-Reference: DNS Records for Two Domains on One Server

| Domain | SPF TXT record | DKIM selector | DMARC TXT record |
|---|---|---|---|
| example.com | v=spf1 ip4:203.0.113.50 -all | selector._domainkey.example.com | v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r |
| example.org | v=spf1 ip4:203.0.113.50 -all | selector._domainkey.example.org | v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.org; adkim=r; aspf=r |

Each row represents one domain. The IP address is the same for both; the DKIM selector and DMARC record domain are different.

---

Common Failure Modes

Forwarding reshapes mail and breaks DMARC alignment. This is the most common failure in multi-domain setups. A recipient's server forwards your mail to another address. The forwarding server becomes the RFC 5321 sender (the envelope MAIL FROM), which changes the SPF result. The forwarding server may also modify headers, which breaks the DKIM signature. DMARC alignment fails because the From domain no longer matches the envelope sender or the DKIM signing domain. This is not a configuration error. It is a fundamental property of how email forwarding works. ARC (Authenticated Received Chain) was designed to handle this, but adoption is uneven across receivers.

One DKIM key shared across unrelated From domains without proper parent domain alignment. If your DKIM signature uses d=example.com and you send mail from differentcompany.com, alignment fails. Some setups try to use a parent domain as the signing domain for all sub-brands. This only works if the DMARC policy for the parent domain covers subdomains, or if each brand uses a proper subdomain that aligns.

Subdomains sending mail without their own SPF records. If sales.example.com sends transactional mail but only example.com has an SPF record, SPF fails for the subdomain. Every subdomain that sends mail directly needs its own SPF record. DMARC policies do not inherit -- if sales.example.com is not covered by your _dmarc.example.com record (and it is not, unless you use a wildcard subdomain record), it needs its own _dmarc.sales.example.com record.

Vendors sending on your behalf without proper configuration. Your CRM sends renewal notices from your domain. Your billing platform sends invoices. Both reshaped the mail in transit and broke your DKIM signature. They need to either send directly through your mail server (so the DKIM signature is applied correctly) or use a sub-domain that is covered by your DMARC policy.

---

Frequently Asked Questions

Do I need a separate DKIM key for each domain?

Best practice is yes, a separate selector and key per domain. This keeps authentication results separate in aggregate reports and limits the blast radius if a key is compromised. One shared key works technically, but it blurs the line between domains in reports and makes troubleshooting harder.

What does relaxed alignment mean for multi-domain setups?

Relaxed alignment (adkim=r) means DMARC passes as long as the DKIM signing domain matches the From domain or is a parent of it. If you send from newsletter@example.com and your DKIM uses d=example.com, that passes alignment. If you send from hello@example.org with the same DKIM (d=example.com), that fails alignment because example.org is not example.com or a subdomain of it. Relaxed alignment does not let you use one DKIM key for completely unrelated domains.

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

The vendor needs to either sign the mail with your DKIM key (requires them to use your mail server or your DKIM selector) or send the mail through your mail server so the signature is applied correctly. If neither is possible, you need to add the vendor's sending infrastructure to your SPF record and accept that DKIM will fail for those messages. Your aggregate report will show DKIM failures for those sources.

How do we monitor aggregate reports for 10+ domains without it being a full-time job?

Use a DMARC monitoring service that aggregates the XML reports into a dashboard. Point each domain's DMARC rua= target at the monitoring service address. DMARCFlow parses reports from all your domains into one view, which is the practical path when manual XML review stops happening. Review the dashboard weekly and after any changes to your mail infrastructure.

Does each subdomain need its own SPF and DKIM records?

Every subdomain that sends mail directly needs its own SPF record. For DKIM, if the subdomain is under the same domain that signs DKIM (d=example.com and From=example.com or From=mail.example.com), the subdomain is covered by relaxed alignment without its own DKIM key. But if the subdomain sends from a different From domain than the parent, it needs its own DKIM configuration and its own DMARC record. DMARC policies do not inherit across sibling domains.

What does "p=quarantine" actually do?

It tells receiving servers to treat failing mail as suspicious. In practice, Gmail and Microsoft route quarantined mail to the spam folder rather than rejecting it outright. The exact behavior varies by receiver. "p=reject" (which you should eventually move to) tells receivers to refuse the message at SMTP time.

---

The Short Version

One mail server handling multiple domains means one set of DNS records per domain:

1. Each domain gets its own SPF TXT record authorizing the same server IP or include statements.
2. Each domain gets its own DKIM selector and private key. Publish the public part at selector._domainkey.domain.com.
3. Each domain gets its own DMARC TXT record at _dmarc.domain.com. Use relaxed alignment. Move from p=none to p=quarantine after reviewing aggregate reports.
4. Read the aggregate reports. Set up a monitoring inbox or use DMARCFlow. Do not skip this step before moving to enforcement.

The configuration itself is not complex. The discipline is keeping the records in sync as your mail infrastructure grows, and actually reading the reports that tell you when something breaks.