Score:1

How to get DKIM to sign for both, a subdomain and the root domain addresses?

gb flag

I'm using latest versions of DKIM + Postfix on Ubuntu 20.04 I got the DKIM to sign the e-mails [email protected]. However it refuses to sign e-mails that originate from @mydomain.com. Is it possible to sign for both e-mail addresses and if yes, how do I do that?

Below is my opendkim.conf

# This is a basic configuration that can easily be adapted to suit a standard
# installation. For more advanced options, see opendkim.conf(5) and/or
# /usr/share/doc/opendkim/examples/opendkim.conf.sample.

# Log to syslog
Syslog          yes
# Added later
SyslogSuccess           Yes
LogWhy                  Yes

# Required to use local socket with MTAs that access the socket as a non-
# privileged user (e.g. Postfix)
UMask           007

# Sign for example.com with key in /etc/dkimkeys/dkim.key using
# selector '2007' (e.g. 2007._domainkey.example.com)
Domain          smtpmail.rapidseohost.com
KeyFile         /etc/dkimkeys/smtpmail.private
Selector        smtpmail

# Commonly-used options; the commented-out versions show the defaults.
Canonicalization    relaxed/simple
#Mode           sv
SubDomains      yes

# Socket smtp://localhost
#
# ##  Socket socketspec
# ##
# ##  Names the socket where this filter should listen for milter connections
# ##  from the MTA.  Required.  Should be in one of these forms:
# ##
# ##  inet:port@address           to listen on a specific interface
# ##  inet:port                   to listen on all interfaces
# ##  local:/path/to/socket       to listen on a UNIX domain socket
#
Socket                  inet:8891@localhost
#Socket         local:/run/opendkim/opendkim.sock

##  PidFile filename
###      default (none)
###
###  Name of the file where the filter should write its pid before beginning
###  normal operations.
#
PidFile               /run/opendkim/opendkim.pid


# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer
# and the verifier.  From is oversigned by default in the Debian pacakge
# because it is often the identity key used by reputation systems and thus
# somewhat security sensitive.
OversignHeaders     From

##  ResolverConfiguration filename
##      default (none)
##
##  Specifies a configuration file to be passed to the Unbound library that
##  performs DNS queries applying the DNSSEC protocol.  See the Unbound
##  documentation at http://unbound.net for the expected content of this file.
##  The results of using this and the TrustAnchorFile setting at the same
##  time are undefined.
##  In Debian, /etc/unbound/unbound.conf is shipped as part of the Suggested
##  unbound package

# ResolverConfiguration     /etc/unbound/unbound.conf

##  TrustAnchorFile filename
##      default (none)
##
## Specifies a file from which trust anchor data should be read when doing
## DNS queries and applying the DNSSEC protocol.  See the Unbound documentation
## at http://unbound.net for the expected format of this file.

TrustAnchorFile       /usr/share/dns/root.key

##  Userid userid
###      default (none)
###
###  Change to user "userid" before starting normal operation?  May include
###  a group ID as well, separated from the userid by a colon.
#
UserID                opendkim
Mike avatar
gb flag
for example, DKIM will sign for root@[email protected], but not for [email protected]
Score:0
gb flag

I was able to resolve this by using information in the post below: DKIM with same key but different domains

Basically I added a root domain in opendkim.conf:

Domain                  smtpmail.rapidseohost.com,rapidseohost.com

and than added corresponding domain name TXT record the DNS.

Score:0
ua flag

You could also solve this using the SigningTable and KeyTable options.

Editing your example, I commented out the old Domain, KeyFile, & Selector options. This is not strictly required, since they are ignored when SigningTable and KeyTable are present:

# Sign for example.com with key in /etc/dkimkeys/dkim.key using
# selector '2007' (e.g. 2007._domainkey.example.com)
# These options are ignored if you use SigningTable / KeyTable
# Domain          smtpmail.rapidseohost.com
# KeyFile         /etc/dkimkeys/smtpmail.private
# Selector        smtpmail

# Use tables to map domain (host) names to keys
SigningTable      refile:/etc/opendkim/signing_table
# This doesn’t necessarily need to be a refile, a plain file works most of the time
KeyTable          refile:/etc/opendkim/key_table

Then you need to create /etc/opendkim/signing_table as a map from wildcard-emails to a key name:

# email                         key name
*@smtpmail.rapidseohost.com     smtpmail
*@rapidseohost.com              smtpmail

And create /etc/opendkim/key_table to map key name(s) to tuples of domain:selector:key_file

# key name  domain:selector:key_file
smtpmail    rapidseohost.com:smtpmail-2023-07:/etc/dkimkeys/smtpmail-2023-07.private

The domain portion of the KeyTable record can be replaced with a %. In that case the “apparent domain” (including any hostname) is substituted. A % in the key_file protion of the tuple is also replaced by the “apparent domain.” This could allow you to have a single record in the KeyTable for multiple domains and simply create key files for each one.

For illustration:

all_domains     %:dkim-2023-07:/etc/dkimkeys/%-2023-07.private

NOTE: It is recommended you rotate your DKIM keys periodically. The recommendation is every 6 months. That’s why I added the year & month on the selector and key files.

When it’s time to rotate, you can

  1. Replace this line with the new selector and key file.
  2. Add the new selector record to your DNS rather than replace the existing one.

Doing so should avoid any race conditions from downstream servers trying to validate on a key you have replaced.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.