A client on one of our servers, whom wants web hosting only, has asked us for a public DKIM record for them to publish in order to satisfy their DMARC requirements of having DKIM alignment as well as SPF. The websites they have on our server has the ability to send emails (typical web form scenario), of which they want the website to be dispatching directly instead of via their mail exchange with SMTP. I suspect that providing us SMTP credentials would have an ongoing cost to them whereas dispatching directly would not.
Theyâve added the IP addresses of our web server to the domain namesâ SPF record but delivery often ends up in quarantine because their DMARC requires DKIM alignment too. DKIM is installed and working on the web server in question, however Virtualmin doesnât appear to be able to configure a DKIM key for the virtual servers because they neither host DNS or email.
I looked into the DKIM settings panel but found that domains can only be signed according to the âDomains to sign for by defaultâ option:
Only those with DNS and email enabled
All domains with DNS
No domains, unless enabled on the DNS Options page
Is it possible for an âAll domainsâ option regardless of DNS/email being enabled?
I tried to use the âExtra domains to sign forâ option too however a DNS record for a public DKIM key does not appear in the virtual serverâs suggested DNS records.
The signing happening in postfix and mail need to be enable to see it in the dns suggested records.
They need to use the hosting smtp to send the emails on the website with authentication.
This isnât related to Apache directly as technically it could also be a scheduled CLI process doing the mail sending as well as a web process.
This is more about the virtual server being able to produce a DKIM key and suggested DNS record for when the account doesnât host mailboxes to handle and store incoming mail. (Just as an authorised sender host.)
Add the ability to enable DKIM even if the mail feature is disabled
But you might need to handle the DNS for them. You may be able to set the DNS up on VM, not disable it, and just give them the keys. Just becasue the DNS is enabled does not mean it needs to be used.
Also, are there not DKIM generators out there you could just use?
In order to make this work the email forms they are using needs to log into the mail server via smtpd/submission connection instead of using a mail injection command.
This way postfix will be able to send those emails out with a DKIM attached.
So that account will need to have âMail for Domainâ feature in order to have a Domainkey.
Oh interesting, I thought that LMTP would be used instead for this case. I somewhat come from running WHM/cPanel servers whereby a website dispatching an email, without SMTP, would go through Exim using LMTP credential-less. Those emails got DKIM signed regardless of whether the account had any mailboxes or hosted emails at all. In terms of PHP this would be with sendmail. I noticed just now when sudo-ing into a terminal for a virtual server user that they donât have permission to execute the sendmail binary, only root can do this.
Turning on the mail features for the virtual server doesnât seem to cause any unwanted side effects, thatâs fine by me. For the few clients that do login to Virtualmin weâll just inform them that the mail features largely wonât work because theyâre hosting them elsewhere. Though it appears youâre saying weâd need to make a mailbox user (eg ânoreply@â or âwebsite@â) within the virtual server for a website to ensure its dispatched emails get DKIM signed?
Iâve been gradually transitioning our servers to Virtualmin for a range of reasons (not just cost) and am not 100% clued up on the Virtualmin way of life quite yet. Most of my experience is with Exim either from WHM/cPanel or our pure Debian servers with only Webmin (but not Virtualmin).
heh unfortunately this isnât our decision. It would definitely make sense though when clients have their emails hosted by big providers like Office 365 or Google Workspace it costs them a monthly fee to open a new mail capable user. We get quite a bit of resistance on that. Itâs also often not our clients directly deciding this, they often have an I.T. MSP making those decisions.
Itâs been over a decade since we allowed the use LMTP, but this process was done through Dovecot and our users where on a MySQL Database at the time. Someone with more knowledge on this would need to chime in.
Another thing you could look into, If you know that your clients email forms are passing through Postfix? Add their account username along with their domain name manually to the Extra domains to sign for In DomainKeys Identified Mail
Should work without having to give them Email features.
And give them a copy of the DKIM DNS records for domains
many major email services out there, Iâm thinking mostly of Gmail/Google, only require spf and dkim and dmarc if you send over 5000 msgs in a day to them.
if you are under 5000/day, while having all three is of course great, they only require ONE of spf or dkim. so it might be possible, absent any auditing requirements, to delete dmarc and dkim and just use SPF (assuming SPF is working OK for you).
being the âdns guyâ at my agency, I like to focus on SPF first and see if that solves my problems
Iâve just come across a big problem by enabling âMail for Domainâ on a virtual server just to get DKIM for outgoing emails.
If something on the same server dispatches an email to the same domain name as the above virtual server, such as a website dispatching an email (even from a different virtual server), the real MX records are ignored and the email is routed locally within Postfix to itself. This causes Postfix to bounce the message to itself with error: dsn=5.1.1, status=bounced (User unknown in virtual alias table)
There would need to be an option within the virtual serverâs settings on how to route emails per domain name. I suspect this is why cPanel has a setting for mail routing, which offers 4 options:
Local: Accept incoming emails for the domain, process forwarders and store in mailboxes, ignore of MX records
Backup: Accept incoming emails for the domain temporarily, do not process forwarders or store in mailboxes, attempt to pass message to higher priority exchange as per MX records
Remote: Do not accept incoming emails for the domain at all, use MX records for destination of locally produced messages
Auto: Choose one of the above based on the domainâs MX records:
If this server is found and has most significant priority: Local
If this server is found but does not have most significant priority: Backup
Otherwise remote
Obviously the most appropriate answer here would be for SMTP credentials of a remote exchange to be provided, which I will press for, but is not a given. Iâll also try the approach cyberndt suggested.
Unfortunately we donât dictate our clientâs DMARC policy, which mandates DKIM is in place, even though the volume of emails dispatched from this website is very low.
This is the route of the problem does this username exist within the user alias ? If whatever the username is you need to create it. That said if this a migration from some other panel there could be advanced settings there that the migration function is not aware of. Check the domain to see if that username is created