DKIM support for custom selector
Not Planned
Hi,
As per the basic Exim configurations provided by cPanel,
only DKIM with the default selector will be recognized, however lots of domains are using a custom selector.
In order to accept the custom selector, we would need
to modify the Exim configurations and we wish to open a feature request.
Please do the needful to help us on priority.
Thanks and regards
Charan
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
Would love this, as Dkim requires a different selector than "default" for some sites.
I had problems with godaddy always telling me to "tell the selector" when using default.
I made a exim4 configuration tweak to use the domain name instead of default and it works.
Would love this, as Dkim requires a different selector than "default" for some sites.
I had problems with godaddy always telling me to "tell the selector" when using default.
I made a exim4 configuration tweak to use the domain name instead of default and it works.
I would very much like to see this happen as I run an Autoresponder Service and Yahoo wants to know the selector being used and they do not accept "default" as the selector hense mail doesn't go through.
I would very much like to see this happen as I run an Autoresponder Service and Yahoo wants to know the selector being used and they do not accept "default" as the selector hense mail doesn't go through.
I agree. This becomes a real issue rather than a minor annoyance in the event of trying to send mail for the same domain from two different cpanel servers.
If one has root access, then they can edit the keys to match, but this is not "according to Hoyle" and while it would be technically feasible as a work-around, it does present some issues.
And if the case of operating in a shared hosting environment, this would not be possible at all, since to change the default selector would change it for everyone on the server.
I agree. This becomes a real issue rather than a minor annoyance in the event of trying to send mail for the same domain from two different cpanel servers.
If one has root access, then they can edit the keys to match, but this is not "according to Hoyle" and while it would be technically feasible as a work-around, it does present some issues.
And if the case of operating in a shared hosting environment, this would not be possible at all, since to change the default selector would change it for everyone on the server.
Would like to add my voice to this. I use G Suite for Business and would like to use its DKIM key for to cover any outgoing messages from my web site running on the cPanel server. Without being able to tell cPanel that I'm already using a DKIM selector and key, this makes it rather difficult to ensure that everything I send is compliant.
Would like to add my voice to this. I use G Suite for Business and would like to use its DKIM key for to cover any outgoing messages from my web site running on the cPanel server. Without being able to tell cPanel that I'm already using a DKIM selector and key, this makes it rather difficult to ensure that everything I send is compliant.
I'll agree with this... If you have another mail system that also "forces" default, now you have two places telling you that the only selector you can use is "default" for your domain. Whichever service you need the most, wins out. Example: cPanel forces default._domainkey and Mailchip forces default._domainkey. You're either using your mailing list service and shutting down the webform on your website, or vice-versa.
What I propose, is to add a unique hash at the end of the selector and change the selector from default to cpanel. This would queue someone who houses DNS on another nameserver, that the domainkey is coming from a cpanel generated server. G Suite (Google Apps) uses google._domainkey BTW.
For example of a hash setup:
The domain key is unique to the domain, so there's no reason that I know of where it can't be a unique hash value. Adding the hash, would allow someone to better check against cpanel and the key they're currently using (assuming NS is offsite) as opposed to looking at the key itself to see if they're different. You can simply glance at the selector to verify: "Yup, selectors are the same, so the key's between cpanel and godaddy are the same" or "Nope, the selectors are different, so I need to update Godaddy".
First item of business though, is to re-design the email authentication page so we actually have access to ALL of the addon domain DKIM keys. Only being able to briefly "see" the primary account DKIM key, doesn't help with 10 addon domains when each addon domain has it's own unique key generated, but we can't even see them.
I'll agree with this... If you have another mail system that also "forces" default, now you have two places telling you that the only selector you can use is "default" for your domain. Whichever service you need the most, wins out. Example: cPanel forces default._domainkey and Mailchip forces default._domainkey. You're either using your mailing list service and shutting down the webform on your website, or vice-versa.
What I propose, is to add a unique hash at the end of the selector and change the selector from default to cpanel. This would queue someone who houses DNS on another nameserver, that the domainkey is coming from a cpanel generated server. G Suite (Google Apps) uses google._domainkey BTW.
For example of a hash setup:
The domain key is unique to the domain, so there's no reason that I know of where it can't be a unique hash value. Adding the hash, would allow someone to better check against cpanel and the key they're currently using (assuming NS is offsite) as opposed to looking at the key itself to see if they're different. You can simply glance at the selector to verify: "Yup, selectors are the same, so the key's between cpanel and godaddy are the same" or "Nope, the selectors are different, so I need to update Godaddy".
First item of business though, is to re-design the email authentication page so we actually have access to ALL of the addon domain DKIM keys. Only being able to briefly "see" the primary account DKIM key, doesn't help with 10 addon domains when each addon domain has it's own unique key generated, but we can't even see them.
Add my vote, too. My organization maintains multiple cPanel servers and we often have more than one server that is sending e-mail for a particular domain. (Usually during an account transition, but occasionally for longer periods.)
The ideal solution would be for cPanel to properly impelement DKIM to allow us to specify our own selectors. Then it would be trivial to add each server's selectors to the separately-maintained zone files. The outgoing messages would be signed by each server with their own keys and selectors, and the messages would validate against the DNS records.
Right now, the only way we can handle this is through behind-the-scenes synchronization of each domain's DKIM public keys between the servers, as stored in /var/cpanel/domain_keys/private and /var/cpanel/domain_keys/public.
This isn't ideal, and it certainly doesn't conform to DKIM's stated purpose for selectors: "selectors are used to permit multiple keys under the same organization's domain name. This can be used to give separate signatory controls among departments, date ranges, or third parties acting on behalf of the domain name owner."
Add my vote, too. My organization maintains multiple cPanel servers and we often have more than one server that is sending e-mail for a particular domain. (Usually during an account transition, but occasionally for longer periods.)
The ideal solution would be for cPanel to properly impelement DKIM to allow us to specify our own selectors. Then it would be trivial to add each server's selectors to the separately-maintained zone files. The outgoing messages would be signed by each server with their own keys and selectors, and the messages would validate against the DNS records.
Right now, the only way we can handle this is through behind-the-scenes synchronization of each domain's DKIM public keys between the servers, as stored in /var/cpanel/domain_keys/private and /var/cpanel/domain_keys/public.
This isn't ideal, and it certainly doesn't conform to DKIM's stated purpose for selectors: "selectors are used to permit multiple keys under the same organization's domain name. This can be used to give separate signatory controls among departments, date ranges, or third parties acting on behalf of the domain name owner."
Hi cpanel team, it has passed 5 years since this idea, and it is really important, but no feature for this yet.
Any update on this subject ?
Hi cpanel team, it has passed 5 years since this idea, and it is really important, but no feature for this yet.
Any update on this subject ?
Also discussed at...
https://forums.cpanel.net/threads/cpanels-crippled-dkim-implementation.672121
Also discussed at...
https://forums.cpanel.net/threads/cpanels-crippled-dkim-implementation.672121
I'd consider this a bug. Hard to say dkim is supported or fully implemented when dkim selectors are supposed to be arbitrary.
I'd consider this a bug. Hard to say dkim is supported or fully implemented when dkim selectors are supposed to be arbitrary.
Still causing headaches for those needing to send email from multiple cPanel hosts. We're performing a migration. Would love to have new host fully provisioned and tested before updating DNS, but it appears that is impossible.
Still causing headaches for those needing to send email from multiple cPanel hosts. We're performing a migration. Would love to have new host fully provisioned and tested before updating DNS, but it appears that is impossible.
We would like to implement this issue, but it hasn't been taken on by a development team just yet. If that does happen, they'll be sure to post an update here, but I don't have anything to add at this point.
We would like to implement this issue, but it hasn't been taken on by a development team just yet. If that does happen, they'll be sure to post an update here, but I don't have anything to add at this point.
Replies have been locked on this page!