That alone isn’t enough, don’t keys have to be generated etc?
No, it’s not enough. You should disable and then re-enable the “Signing of outgoing mail enabled” option for it to be picked up.
I want to use Transfer rather then Restore for reasons like this. I would then have to fix each domain individually.
Confused, not restore - does it work? Or do you mean not restore system but still restore a domain - which I don’t want to do?
Where it’s at - New VPS.
Clean OS, fresh VMin 8 install.
Restore system settings from old server.
Edit selector in opendkim.conf
Disable and then re-enable the “Signing of outgoing mail enabled”
Old system.
Send an email to gmail, check Show Original - all good.
Transfer domain to new system
Back to new VPS.
Copy/paste DKIM record from Suggested DNS Records to the DNS zone file. Reload named on DNS server (external, not VMin).
Wait for propagation (1m) Get coffee.
Disable signing of outgoing mail
Send email to gmail. Accepted - proves SPF is OK.
Enable signing of outgoing mail
Send email to gmail - it works! DKIM lives with my choice of name.
Possibly getting the coffee made a difference allowing more time for google to see the updated DNS, the 60 second TTL isn’t long enough to wait.
I think I read somewhere that this is the recommended naming for the selector.
It is possibly because it is a sequence of numbers that are not repeated to prevent collision, also not using _default prevents probing?
No, not really!
I believe we should make it globally configurable in the Virtualmin config using default as a default selector.
Seeing how simple it actually is to do that should be an easy option to implement.
We could make it selectable when DKIM is first enabled, but changing it afterwards is tricky as this could break signatures for emails in the process of being delivered.
1 Like
How many emails end up queued? My guess is not many. So stop delivery? Warn the admin doing the change?
From the thread I’m not sure AFTER matters as much?
Maybe a separate issue is migrating a server. Option to not migrate it, if that happens and I remember some of the earlier posts correctly.
Another option would be to disable DKIM, then re-enable it with a new selector.
As I use my own DNS server that wouldn’t be a problem, I could have both DKIM entries in the Zone file.
VMin DNS would probably change old for new, or ir could leave the old and create a cron to remove it after a week or whatever.
You can have 2 selectors running and use a system cron to delete the old one after x number of hours
Or
Leave this problem to the admin. They must expect issues when changing the dkim
Alert! Suggestions are not appreciated.
1 Like
Yes, that’s true. However, if we make it configurable somewhere in the Virtualmin config page, it won’t be obvious, and most users won’t change it anyway.
And, also, we currently generate a new selector for every new install. What happens during migration? Do we correctly use the system’s new DKIM selector afterward?
The issue seemed to be knowing WHICH server so that would seem logical.
Like if a domain is migrated from one system to another? Currently Virtualmin will change the selector and use any key from the new system.
Good, that means we’re only dealing with adding a new feature. @Jamie, so, are you okay with making the DKIM selector configurable?
A post was split to a new topic: Should DKIM keys be rotated periodically?
@Jamie, bringing this up again to get your thoughts. It looks like users would like the option to configure their own DKIM selector.
Should we support that, and if so, what potential issues could it cause with the current code?