Blog · Dmarc
How to Set Up SPF, DKIM, and DMARC for Multiple Domains on One Mail Server
If one mail server sends for three domains, all three need valid SPF, DKIM, and DMARC records. That sounds simple, but the configuration is not obvious. The mistake most admins make is treating all three records as a single global setup. They are not. Each domain needs its own DMARC record, its own DKIM key, and its own thought about alignment.
Here is how it works.
Why Multi-Domain Mail Servers Need Per-Domain Authentication
When the same MTA sends for a.org, b.org, and c.org, each of those From addresses must independently pass DMARC. That means for each domain, both SPF and DKIM must align with the From domain. If your mail server signs every outgoing message with a.org's DKIM key regardless of which domain is in the From header, then b.org and c.org will fail DKIM alignment. The From address says b.org but the signature says a.org. That is a mismatch, and receivers will treat it as a potential spoofing attempt.
SPF Records for Each Domain
Each domain needs its own SPF record. If your mail server's IP is 203.0.113.50, the SPF record for each domain looks the same:
v=spf1 ip4:203.0.113.50 -all
The Return-Path (envelope sender) must also match the From domain for SPF alignment. If you are sending From b.org but the Return-Path is a.org, SPF alignment will fail. Most MTAs set the Return-Path automatically from the domain you authenticated with, so as long as your MTA authenticates per-domain this usually works itself out. Check by looking at the Received-SPF header in a test message sent from each domain.
DKIM Signing: One Key Does Not Fit All
This is where the common setup breaks down. Many admins configure amavisd or their MTA to add one DKIM signature using a single domain's key to all outgoing mail, regardless of which domain is in the From address. That works for a.org but fails for b.org and c.org.
The fix is per-domain DKIM signing. Each domain gets its own private key, and the MTA signs with the key matching the From domain.
In amavisd, this looks like:
dkim_key('a.org', 'mail', '/var/db/dkim/a.org.key.pem');
dkim_key('b.org', 'mail', '/var/db/dkim/b.org.key.pem');
dkim_key('c.org', 'mail', '/var/db/dkim/c.org.key.pem');
Amavisd picks the correct key automatically based on the author domain. You do not need per-recipient rules.
For each domain you also need a DKIM selector record in DNS. If your selector is mail, the record name is mail._domainkey and it lives in the DNS zone of that specific domain:
mail._domainkey TXT "v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."
This record must exist in b.org's DNS zone and c.org's DNS zone, not just a.org.
Your DNS Layout Per Domain
For each domain you are sending from, you need three DNS records:
| Record type | Example for a.org | Example for b.org |
|---|---|---|
| SPF | a.org TXT "v=spf1 ip4:203.0.113.50 -all" | b.org TXT "v=spf1 ip4:203.0.113.50 -all" |
| DKIM selector | mail._domainkey.a.org TXT "v=DKIM1; p=..." | mail._domainkey.b.org TXT "v=DKIM1; p=..." |
| DMARC | _dmarc.a.org TXT "v=DMARC1; p=none; rua=mailto:dmarc@a.org" | _dmarc.b.org TXT "v=DMARC1; p=none; rua=mailto:dmarc@b.org" |
Each domain carries its own authentication fingerprints. There is no shortcut that works across all three.
Understanding DMARC Alignment
DMARC requires at least one of SPF or DKIM to align with the From domain. Both can pass and both can align, but you need at least one. Alignment means the domain in the From header matches the domain in the SPF result (the Return-Path domain) or the domain in the DKIM signature.
When everything is configured correctly:
- The From header says b.org
- The SPF check sees b.org in the Return-Path, and the sending IP is authorized in b.org's SPF record. SPF passes and aligns.
- The DKIM signature uses b.org's DKIM key, and the signature verifies against b.org's DKIM record. DKIM passes and aligns.
- DMARC passes.
When per-domain DKIM is missing:
- The From header says b.org
- SPF passes (the server is authorized for b.org's SPF record)
- DKIM fails alignment because the signature is from a.org, not b.org
- DMARC fails, because DKIM does not align and SPF alone is not enough if DKIM is also present and failing
This is the most common reason legitimate multi-domain mail gets flagged or rejected. The fix is always per-domain DKIM signing.
The Observation Phase: Why Start at p=none
Set every new DMARC record to p=none first. That means nothing gets blocked. You receive aggregate reports and watch what is happening. This phase is not optional. It is the only way to know whether your configuration is actually working before you tell receivers to start rejecting mail that fails.
For low-volume senders, aggregate reports come in slowly. If you send one message a day, you might get a handful of reports a week from Gmail and Microsoft and nothing at all from smaller receivers. A quiet report inbox does not mean everything is fine. It might just mean nobody had anything to report. Do not read silence as confirmation.
This is where a DMARC monitoring tool earns its place. DMARCFlow pulls aggregate reports from all your domains into one view and shows you which domains have alignment failures and why, without you having to parse XML files manually. For multi-domain setups, this matters especially: a failure on b.org is easy to miss if you are only watching a.org's inbox. DMARCFlow flags it automatically and tells you which domain is affected, which authentication mechanism failed, and which receiving server reported it.
When to Move to p=quarantine or p=reject
The rule of thumb is: move to p=quarantine only after you have seen clean aggregate reports from the major receivers (Google, Microsoft, Yahoo) for at least four consecutive weeks with no alignment failures. "Clean" means zero failures for all your domains, not just fewer failures than before.
Move to p=reject only after p=quarantine has run cleanly for several weeks. p=reject means any failing message gets hard-rejected, not quarantined. The upgrade path matters. Going straight to p=reject after setting p=none is how legitimate mail ends up in limbo.
For multi-domain setups, watch all domains together. If b.org suddenly starts failing DKIM alignment while a.org is fine, that is a separate problem to fix before you tighten b.org's policy.
FAQ
Can I use the same DKIM key for all domains?
No. DKIM signatures are domain-specific. If you sign a message From b.org with a.org's key, the signature will not align with b.org and DMARC will fail. Each domain needs its own key pair and its own DKIM DNS record.
Do I need a DMARC record for each domain, or can I put one on the primary domain only?
Each domain needs its own DMARC record. DMARC policies do not inherit across domains. You cannot put a DMARC record on a.org and expect it to cover b.org. If b.org has no DMARC record, it has no policy, and receivers will not send you aggregate reports for it either.
My server sends from a.org for all domains. Can I just use a.org's SPF and DKIM for everything?
SPF will align if the Return-Path is set to a.org for all mail. But DKIM will not align for b.org and c.org unless you are signing with those domains' keys. The From address is what matters for DMARC, not the envelope sender. So: no, a shared DKIM key across domains will fail DMARC for the secondary domains.
How long should I stay at p=none?
At minimum, four weeks of clean reports from the major receivers. For low-volume senders, this can take longer because aggregate reports arrive sporadically. There is no fixed deadline, but the goal is to have seen zero alignment failures across all domains before tightening the policy.
I send less than 5000 messages per day to Gmail. Do I need DMARC?
Gmail does not require DMARC for low-volume senders. But DMARC is still useful even at low volume because the aggregate reports are the only feedback you get about whether your mail is actually aligning. Without DMARC, you have no way to know if something is quietly failing. Setting p=none costs nothing and tells you whether your configuration is working.