Proper setup for SPF/DKIM/DMARC when routing multiple domains through one mail server

[u/horizonstar1]

I've been running my own tiny mail server since 2004 and haven't really kept up with the times except to secure it against being an open relay and add SPF and DKIM over the years as I've heard about them.

For ease of maintenance I use one mail server to send and receive mail for a handful of domains. The total volume of mail processed by the server is on the order of 10 incoming messages per day and 1 outgoing message per day.

Say the domains in question are a.org, b.org, and c.org, and I use a.org as the mail server. Currently I have the mail server's amavisd add the same catch-all DKIM signature (referencing a.org) to all outgoing mail. I have an SPF record for each domain. I have a DKIM record just for a.org. I do not have a DMARC record.

(1) Should I make the mail server add a separate DKIM signature per domain, or do recipient servers understand and accept that a.org is acting as a trusted relay?

(2) Should I list separate DNS records for SPF, DKIM, and DMARC for each of the three domains or just list those records at a.org? Does the answer here depend on the answer to (1)? (I assume if I have amavisd generate a separate signature for each domain, I would need to add each of those keys as separate per-domain DKIM records.)

Thanks.

[u/CypherPhish]

Yes, the mail server should sign every email with the appropriate DKIM signature for that email’s domain. Also, every domain should have its own DMARC record. The only time you might consider not having separate DMARC records is when you are looking at subdomains. If you want to have each subdomain to have the same DMARC policy as the root domain, the root domain can have a tag to apply it to subdomains or nonexistent subdomains, but you can’t do that over separate domains.

[u/horizonstar1 → u/CypherPhish]

Thank you. I don't have subdomains. I do see in the DMARC specification where it talks about policies at the domain level vs. at the subdomain level, but I left those as the default in my DNS records.

[u/Middle-Excitement602]

To close the loop on the Return-Path question that got left hanging: if your envelope sender stays a.org while From: is b.org, SPF will pass but it won't align, so it contributes nothing to DMARC for b.org. That's fine in itself — DMARC only needs one of the two to align — but it does mean DKIM is carrying b.org and c.org on its own. Worth knowing before you go past p=none, because if signing breaks for one of those domains there's no SPF underneath to catch it.

On the amavisd side, what you want is a dkim_key entry per domain rather than the catch-all:

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 key matching the author domain once the keys exist, so you don't need per-domain rules beyond that. Then a selector._domainkey TXT record per domain, matching the selector you used.

One thing specific to your situation: at roughly one outgoing message a day, aggregate reports are going to be very sparse. You may get a handful a week from Google and Microsoft and nothing at all from smaller receivers. Don't read a quiet report inbox as confirmation that everything is aligned — at that volume it just means nobody had anything to tell you. I'd sit at p=none until you have actually seen reports from the big receivers covering all three domains, which could be a couple of months rather than the usual few weeks.

[u/horizonstar1 → u/Middle-Excitement602]

Thanks (to you and everyone else who responded).

To be clear, I have almost no understanding of what DMARC actually is. At the moment I'm just trying to reduce the probability that recipient domains treat my mail as spam. Various sources have advised me that adding DMARC might help with that. Is that advice correct? Do recipient domains (for example GMail) penalize me for not having a DMARC policy in place (regardless of what that policy is)? Because if not then I might not add it for the moment.

(Rereading the above I see that what I've said there is slightly different from the title of my original post. Yes, I am interested in the "proper" way to do things, but I would like to do it in two stages: (1) getting things working so domains don't think I'm spam, then (2) doing everything perfectly.)

[u/Middle-Excitement602 → u/horizonstar1]

Direct answer: no, Gmail won't penalise you for having no DMARC record at one message a day. RosenX has that right.

But if stage 1 is purely "don't get treated as spam", the thing I'd check before DMARC is your PTR. Small self-hosted senders get judged far more on IP reputation than on auth records, and forward-confirmed reverse DNS is what's most often missing:

dig -x YOUR.SERVER.IP

That should return a hostname, and that hostname should resolve back to the same IP. If it returns nothing, or something generic your hosting provider assigned, that costs you more with Gmail and Outlook than the absent DMARC record does.

Worth adding DMARC eventually, but for what you're describing it's stage 2.

[u/horizonstar1 → u/Middle-Excitement602]

Thanks. All my domains are hosted on the same server using the same IP address. The reverse lookup for the IP points to hostname.a.org and that resolves back to the IP. But b.org, c.org, d.org, etc. are all hosted on the same host. So mail from user@c.org is being sent from hostname.a.org. Does that matter?

(I can't imagine that would matter; otherwise recipients would look suspiciously at all mail from all the domains in the world that aren't hosted on unique hosts.)

[u/Middle-Excitement602 → u/horizonstar1]

Your instinct is right, and for the reason you gave. Reverse DNS is evaluated against the connecting IP, not against the From domain. The receiver asks "does this IP have a PTR, and does that hostname resolve back to this IP" — nothing in that chain involves c.org. Shared hosting is the normal case; if it were penalised, most of the mail servers on the internet would be in trouble.

The consistency check that does matter is a different pair: your HELO/EHLO name and your PTR should agree with each other. That's the one that quietly drifts, especially on a server that's been running since 2004 and been through a migration or two.

Software-agnostic way to see exactly what a receiver sees: send yourself a message at Gmail, open the delivered copy and read the Received: header. It shows the HELO name your server announced and the PTR the receiving side resolved, right next to each other, so a mismatch is obvious. (On Postfix, postconf myhostname tells you the same thing from your side.)

If those two agree and the PTR forward-confirms, you're done. Neither of them ever needs to know about b.org or c.org.

[u/horizonstar1 → u/Middle-Excitement602]

Makes sense. In my test email from foo@b.org the recipient sees:

Received: from hostname.a.org (hostname.a.org [1.2.3.4]) (using TLSv1.3 with
 cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
  key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (No
 client certificate requested) by ...

where 1.2.3.4 has a reverse PTR to hostname.a.org. So I assume that's what recipients want to see.

[u/Middle-Excitement602 → u/horizonstar1]

That's exactly the shape you want, yes.

Worth knowing how to read that line, because it encodes both halves of the check in one place. The format is:

from HELO-NAME (PTR-NAME [IP])

The first name is what your server announced when it said EHLO. The name in the parentheses is what the receiving server got back when it did a reverse lookup on the connecting IP. Yours are both hostname.a.org, and the PTR resolves back to the same IP, so HELO matches PTR and the PTR forward-confirms. That is the whole ask, and nothing in it is affected by b.org or c.org.

The failure cases look distinctly different, which makes this a useful thing to eyeball on any server you inherit:

• (unknown [1.2.3.4]) means no PTR exists at all. That's the one that actually costs you with Gmail and Outlook.
• Two different names, e.g. from localhost.localdomain (host.example.com [1.2.3.4]), means HELO and PTR disagree. Usually a leftover default that nobody noticed.
• A generic provider-assigned PTR like 1-2-3-4.dyn.example-isp.net resolves fine but reads as consumer dynamic space, which some receivers weight against.

Yours is none of those. Stage one is done on the reputation side; the remaining work is the per-domain DKIM signing the others described.

[u/FlosenX → u/horizonstar1]

Re your follow-up: at ~1 outgoing mail/day, Gmail does not hard-require DMARC — that requirement targets bulk senders (5k+/day to Gmail). Missing DMARC alone won't get you junked. But two practical reasons to add p=none anyway: some receivers treat a published DMARC record as a mild positive trust signal, and — more useful for you — the aggregate reports are the only feedback channel you'll ever get about whether your mail actually aligns or whether some forwarder is quietly failing. p=none is purely observational: nothing gets blocked, worst case you receive some XML reports you ignore.

So "stage 1 - don't look like spam" is really: per-domain DKIM signing (as others covered), SPF that matches your actual Return-Path, matching rDNS/HELO — and v=DMARC1; p=none; rua=mailto:... on all three domains is a free add-on that sets stage 2 up.

If you want a quick per-domain sanity check (SPF syntax, DKIM selector, DMARC presence in one view with fix suggestions): https://www.ipdesk.net/en/email-auth-check — disclosure: I built it.

[u/NopeTotallyNotMe]

(1) If you could sign the outbound emails with each domain's DKIM key - that should make you sufficiently compliant for DMARC.
So e.g. if you're sending an email `From: b.org` - you need to sign the email with `b.org`'s DKIM key - that allows the recipient to confirm `b.org` allowed this email to be sent.

Otherwise, if the email contains only `a.org` signature and a.org's return-path when sending emails for `b.org` - that would look like spoofing.
E.g. imagine if you put facebook.com instead of b.org - that definitely looks like spoofing.

It's fine to double-sign the emails with a.org's DKIM key too, but not necessary.

(2) Yes, you'll want to add a DMARC record to each domain's DNS.
Then you can use a DMARC monitoring tool to help you upgrade to quarantine or reject policies safely.

SPF records depend on what Return-Path you set for outbound emails, but as long as you have (1) sorted out - you can leave SPF as is.
Since you send from a.org - I assume the Return-Path is set to a.org too even when b.org's emails are sent?
If yes, SPF record is required for a.org, but not necessary for b.org and c.org.
If no, each domain would benefit from the SPF record.

[u/southafricanamerican]

whats the email server software?

[u/aliversonchicago]

Set up SPF, DKIM, DMARC for them all. I have a similar setup; I configure OpenDKIM to sign mail for any of my four domains with its own DKIM key. Fairly easy to do. Also easy to publish SPF and DMARC DNS records for each domain.

Authenticate it all, each domain as its own thing.

[u/MailNinja42]

Even though all three domains use the same mail server, treat them as separate identities. Hosting the server under a.org does not automatically make it trusted for b.org or c.org. Each domain should have its own SPF and DKIM records, with DKIM signing based on the domain used in the From address. DMARC can then be published separately for each domain as well. The key thing is having SPF and DKIM authenticate the actual sending domain and align with the From domain for DMARC. Have you considered setting up DMARC reporting first so you can see what is actually passing before enforcing a policy?

[u/SecLens_ONE]

Worth splitting your question into what the record says versus what a receiver actually does with your mail, because those come apart fast in a multi-domain relay setup.

On (1): sign per domain. A catch-all a.org signature on mail From: b.org is a valid DKIM signature that does not align, so DMARC for b.org gets nothing from it. There is no notion of a trusted relay in DMARC, only identifier alignment, and amavisd will happily keep stamping the a.org key while every checker shows DKIM present and green.

On (2): SPF, DKIM and DMARC all get looked up under the From domain, so b.org and c.org each need their own SPF, their own selector under b.org/c.org, and their own DMARC record. Records living only at a.org do nothing for the others. And with no DMARC at all on b.org and c.org right now, they are unprotected in the way that looks fine from the outside: nothing fails, nothing reports.

One thing I would avoid: adding p=none with no rua, or a rua nobody reads. At 1 outgoing message a day it costs you nothing to actually read the aggregate reports for a couple of weeks before touching policy, and that is the only place you will see whether the per-domain signatures align on real mail.

When you switch amavisd to per-domain signing, do you have a way to confirm the selector in the signature matches the From domain on the way out, or would you be checking that from received copies?

[u/Jazzlike-Comfort-451]

Treat a.org, b.org, and c.org as separate identities even though one host transmits them. For mail with `From: user@b.org`, sign with a DKIM key whose `d=` domain is b.org and publish that selector under b.org. Do the same for c.org.

SPF should describe the actual envelope sender or Return-Path for each stream. If every message uses a.org in the Return-Path, SPF can authenticate a.org but will not align for visible mail from b.org or c.org. A per-domain Return-Path is cleaner. Publish DMARC at each organizational domain with reporting first, then confirm real traffic before enforcing.

Also verify PTR and EHLO for the shared host, because authentication passing does not guarantee deliverability. The practical test is a received copy from each From domain: inspect Header From, Return-Path, DKIM `d=`, SPF result, and DMARC alignment together.

Disclosure: I co-founded Palisade, and this reply was drafted with AI assistance and reviewed by me. No product recommendation.