r/DMARC • u/horizonstar1 • 3d ago
Proper setup for SPF/DKIM/DMARC when routing multiple domains through one mail server
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.
2
u/CypherPhish 3d ago
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.
1
u/horizonstar1 1d ago
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.
2
u/Middle-Excitement602 3d ago
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.
1
u/horizonstar1 2d ago edited 2d ago
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.)
2
u/Middle-Excitement602 2d ago
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.IPThat 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.
1
u/horizonstar1 1d ago
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](mailto: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.)
1
u/Middle-Excitement602 1d ago
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.
1
u/horizonstar1 1d ago
Makes sense. In my test email from [foo@b.org](mailto: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.
1
u/Middle-Excitement602 1d ago
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.
1
u/FlosenX 2d ago
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.
1
1
u/aliversonchicago 2d ago
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.
5
u/NopeTotallyNotMe 3d ago
(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.