Contents
Why DKIM signing must be right
DKIM is one of the three pillars of email authentication, and in 2026 it is mandatory: the major mailbox providers require bulk senders to DKIM-sign their mail, and mail that is not properly signed fails the bulk sender requirements and is rejected. Beyond being required, DKIM is the most robust of the authentication mechanisms for satisfying DMARC, because a DKIM signature survives forwarding where SPF breaks. So DKIM signing is both a requirement to meet and the foundation that good DMARC compliance is built on, and configuring it correctly in PowerMTA is essential.
This guide exists to cover PowerMTA DKIM signing configuration thoroughly, including the parts operators get wrong. The structure of this guide: why DKIM signing must be right, what DKIM signing does, generating the key pair and publishing the public key in DNS, the selector concept, configuring the domain-key directive on the virtual MTA, the critical point of signing with the sender's own domain so DKIM aligns for DMARC, which headers to sign and the key length, verifying the signing works, and the diagnostic workflow when DKIM signing is not producing valid signatures.
What DKIM signing does
DKIM signing attaches a cryptographic signature to an outgoing message that lets a receiving server verify the message genuinely came from the signing domain and was not modified in transit.
When PowerMTA DKIM-signs a message, it computes a signature over the message body and a selected set of headers, using a private key, and adds that signature to the message as a DKIM-Signature header. That header also names the signing domain, the d= value, and a selector, the s= value.
A receiving server that wants to verify the signature:
- Reads the DKIM-Signature header, getting the signing domain and selector.
- Looks up the corresponding public key, which the signing domain has published in DNS.
- Uses the public key to check the signature.
If the signature verifies, the receiver knows two things: that the message was signed by someone with access to the private key for the named domain, and that the body and signed headers have not been altered since signing.
DKIM is one of the three core authentication mechanisms, alongside SPF and DMARC, and it is required for bulk senders. It is also the most robust mechanism for satisfying DMARC, because the signature travels with the message and survives forwarding. For a PowerMTA operator, configuring DKIM signing correctly serves both purposes: meeting the mandatory requirement, and providing the durable DKIM alignment that DMARC is best built on.
Generating the key pair and publishing the public key
DKIM uses a public/private key pair. The private key signs; the public key verifies. Setting up DKIM signing begins with generating the pair.
The key pair is generated with a cryptographic tool, openssl being the common choice:
# Generate a 2048-bit DKIM private key
openssl genrsa -out dkim_private.pem 2048
# Extract the public key from the private key
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pemThis produces two files: the private key, which PowerMTA uses to sign and which must be kept secret and secure on the PowerMTA server, and the public key, which goes into DNS.
The private key is placed on the PowerMTA server, in a location PowerMTA's configuration will reference, with file permissions that keep it readable only by PowerMTA. The private key is a secret; anyone with it could forge the domain's DKIM signatures.
The public key is published in DNS as a TXT record. The record's location is derived from the selector and the domain, at selector._domainkey.domain, covered in the next section, and the record's value contains the public key in the DKIM TXT record format, typically including the key type and the public key data.
Publishing the public key in DNS is what allows any receiver in the world to verify the domain's DKIM signatures. The private key never leaves the PowerMTA server; only the public key is published. Once the key pair is generated, the private key is in place on the server, and the public key is published and has propagated in DNS, the cryptographic foundation for DKIM signing is ready.
The selector
A DKIM selector is a short label that identifies which DKIM key a message was signed with. It exists so that a domain can have multiple DKIM keys in use at once.
The selector appears in the DKIM-Signature header as the s= value, alongside the d= signing domain. The receiver uses both to find the public key, because the public key is published at a DNS location derived from the selector and the domain:
# For domain example.com with selector "sel1",
# the public key TXT record is published at:
sel1._domainkey.example.comSo a domain example.com signing with a selector sel1 publishes its public key in a TXT record at sel1._domainkey.example.com, and a receiver verifying a signature naming d=example.com and s=sel1 knows to look exactly there.
The selector mechanism's value is that a domain is not limited to one DKIM key:
- It makes key rotation possible. A domain publishes a new selector with a new key, switches signing to it, and later removes the old selector, with no signing gap because both keys are in DNS during the transition.
- It allows different streams to sign differently. Different sending systems or streams can sign with different keys under the same domain, each with its own selector.
For a PowerMTA operator, the selector is simply part of the configuration: the operator chooses a selector name, publishes the public key at the selector-derived DNS location, and configures PowerMTA to sign with that selector so it names it in the DKIM-Signature header. The selector name itself is arbitrary, any short label, and operators often use a name that encodes a date or a purpose for clarity.
The domain-key directive
In PowerMTA, DKIM signing is configured with the domain-key directive, which ties together the selector, the signing domain, and the private key file.
The domain-key directive is placed on the virtual MTA, in the virtual-mta block:
<virtual-mta mta-ip-1>
smtp-source-host 203.0.113.10 mail1.example.com
domain-key sel1,example.com,/etc/pmta/keys/dkim_private.pem
</virtual-mta>The domain-key directive takes three values: the selector, the signing domain, and the path to the private key file. In this example, mail sent through mta-ip-1 is DKIM-signed with the selector sel1, the domain example.com, and the private key at the given path.
The three values correspond exactly to what the receiver needs and what was set up earlier: the selector and domain together are how the receiver finds the public key in DNS, and the private key file is the key PowerMTA signs with, whose public counterpart is published at sel1._domainkey.example.com.
Placing the domain-key directive on the VMTA means the DKIM signing is associated with the sending IP. This has a useful consequence for a deployment sending for multiple domains: different VMTAs can carry different domain-key directives, so each stream signs with the domain appropriate to its mail, which the next section shows is essential.
Once the domain-key directive is configured and PowerMTA reloaded, PowerMTA DKIM-signs the mail sent through that VMTA, adding the DKIM-Signature header with the configured selector and domain.
Signing with the sender's own domain
The most important correctness point in DKIM signing configuration: PowerMTA must DKIM-sign with the sender's own domain, the domain that appears in the message's From header.
DKIM on its own only requires that the signature verifies against whatever domain signed it; the signing domain does not have to be the From domain for DKIM itself to pass. But DMARC adds the alignment requirement: for DKIM to satisfy DMARC, the signing domain, the d= value, must align with the From header domain.
If PowerMTA DKIM-signs with some domain other than the From domain, a generic domain, an unrelated domain, the signature will verify, DKIM passes, but it will not align with the From domain, so it will not satisfy DMARC. Since DMARC compliance is a bulk sender requirement and DKIM alignment is the recommended way to achieve it, PowerMTA must sign with the sender's own domain, the one matching the From header. The domain in the domain-key directive must be the sender's From-header domain. A DKIM signature that merely verifies is not enough; only a DKIM signature that aligns with the From domain satisfies DMARC, and only the aligned one meets the requirements.
The practical implication for the domain-key directive: the domain value in domain-key must be the sender's domain that appears in the From header of the mail that VMTA sends.
For a deployment sending mail for multiple From domains, the DKIM signing must be set up so each message is signed with the domain matching its own From header. This typically means using different VMTAs, or different configuration, for the different domains' streams, each VMTA's domain-key directive naming the domain of the mail it carries. A deployment sending for example.com and example.net needs the example.com mail signed with d=example.com and the example.net mail signed with d=example.net, which means the two streams go through VMTAs with the appropriate domain-key directives.
Getting this right, signing each message with its own From domain, is the difference between DKIM that satisfies DMARC and DKIM that does not.
Which headers to sign and the key length
Two further configuration considerations: which headers DKIM signs, and the key length.
Which headers to sign. A DKIM signature covers the message body and a selected set of headers. The headers signed should include the important identity headers, above all the From header, since DMARC alignment is based on From, and typically Subject, Date, To, and others. PowerMTA signs a sensible default set of headers, and the From header must be among the signed headers for the signature to be meaningful for DMARC. A point of caution: signing a header that an intermediary commonly modifies, or signing headers that may be added later, can cause verification failures, so the signed header set should be the stable, important headers. The default PowerMTA behavior is generally appropriate, and an operator does not usually need to customize the header list, but should be aware that the From header signing is what matters most.
The key length. DKIM keys are RSA keys, and the key length matters for security. The recommendation in 2026 is a 2048-bit key. Older 1024-bit keys are considered weak by current standards, and some receivers may treat a 1024-bit DKIM key less favorably. A 2048-bit key is the current standard and should be used for new DKIM keys. The key generation example earlier used 2048 bits for this reason. The one practical constraint with 2048-bit keys is that the public key is large enough that the DNS TXT record may need to be split into multiple strings, which is a normal DNS handling matter the operator's DNS setup accommodates.
Verifying the signing works
After configuring DKIM signing, the operator must verify it is actually producing valid, verifiable signatures, rather than assume it.
The verification steps:
- Confirm PowerMTA reloaded the configuration. After adding or changing the domain-key directive, confirm pmta reload was run so the configuration is active.
- Send a test message. Send a test message through the configured VMTA to a mailbox where the operator can inspect the received message's headers and authentication results.
- Check the DKIM-Signature header. Confirm the received message has a DKIM-Signature header, and that it names the expected selector and the expected domain, the sender's own domain.
- Check the Authentication-Results header. Many receivers add an Authentication-Results header recording the DKIM verification outcome. Confirm it shows DKIM passing, and, for DMARC, that DKIM aligns with the From domain.
- Use a DKIM validation tool. A DKIM validation or email-authentication testing tool checks that the signature verifies correctly, that the public key is found in DNS, and that the configuration is sound.
The verification confirms the whole chain: PowerMTA is signing, the signature names the right selector and domain, the public key is published and found, the signature verifies, and it aligns for DMARC. An operator should perform this verification when first setting up DKIM signing and after any change to the DKIM configuration or keys, because a DKIM signing problem is invisible until a receiver rejects the mail, and a deliberate test catches it before production mail is affected.
When DKIM signing fails
When DKIM signing is not producing valid, verifying signatures, the diagnostic workflow:
Step 1: confirm PowerMTA is signing at all. Check a sent message for the DKIM-Signature header. If there is no DKIM-Signature header, PowerMTA is not signing, the domain-key directive may be missing from the VMTA the mail went through, or the configuration was not reloaded.
Step 2: confirm the selector and domain in the signature. If there is a DKIM-Signature header, confirm it names the expected selector and the sender's own domain. A wrong domain means a signing-with-the-wrong-domain problem and a DMARC alignment failure.
Step 3: confirm the public key is in DNS. Look up the TXT record at selector._domainkey.domain. If the public key is not there, or is malformed, verification cannot succeed. A common cause is the DNS record not being published, not having propagated, or being entered incorrectly.
Step 4: confirm the public key matches the private key. If both the signature and the DNS record exist but verification fails, the published public key may not correspond to the private key PowerMTA is signing with. Confirm the public key in DNS was extracted from the private key in use.
Step 5: check for body modification. If the signature is correct and the key matches but verification still fails on some mail, something may be modifying the message body or signed headers after signing. An intermediary altering the message breaks the signature.
Step 6: check the key length. If DKIM verifies but receivers seem unimpressed, confirm the key is 2048-bit, not an old weak 1024-bit key.
Step 7: verify with a test after each fix. After any change, send a test message and confirm the DKIM-Signature header and the Authentication-Results, as in the verification section.
An operator we worked with had what they believed was a working DKIM setup. They had generated a key, published it in DNS, configured the domain-key directive in PowerMTA, and confirmed, with a DKIM validation tool, that their DKIM signatures verified correctly. The validation tool showed DKIM passing, and they considered DKIM done. But their DMARC was failing for a large portion of their mail, and they could not understand why, since DKIM, they were sure, was passing. We looked at the actual messages and the authentication results. DKIM was indeed passing, the validation tool had been right, the signature verified cleanly against the published public key. But the DKIM-Signature header told the rest of the story. The d= value, the signing domain in their DKIM signature, was not their own sending domain. When they had set up DKIM, they had configured the domain-key directive with a domain that was not the domain appearing in their mail's From header, in their case a leftover domain from an earlier configuration that was not the From domain. So every message was being DKIM-signed, the signature was valid, DKIM passed, but the signing domain did not match the From domain. And DMARC requires DKIM alignment, the signing domain matching the From domain, not just DKIM passing. Their DKIM signatures verified but did not align, and so they did not satisfy DMARC, and because their SPF was also not aligning for that mail, DMARC failed. The DKIM validation tool had not caught this because the tool was checking whether the signature verified, which it did; it was not checking whether the signing domain matched the From domain, which is the DMARC alignment question. The fix was to correct the domain in the domain-key directive to the sender's actual From-header domain, generating and publishing a key for that domain, and configuring PowerMTA to sign with it. Once PowerMTA was signing with the From domain, the DKIM signature aligned, DMARC passed, and the failure rate dropped away. The lesson is the central correctness point of DKIM signing configuration: a DKIM signature that verifies is not necessarily a DKIM signature that satisfies DMARC. DMARC requires the signing domain to align with the From domain, and a setup that signs with any other domain produces a valid-but-non-aligning signature that passes DKIM and fails DMARC. Verification testing must check not just that DKIM passes but that the signing domain is the sender's own From domain, because only the aligned signature meets the requirements.
DKIM signing is a mandatory part of email authentication in 2026 and the most robust foundation for DMARC compliance, and configuring it correctly in PowerMTA is essential. The setup runs from generating a 2048-bit key pair, keeping the private key secure on the PowerMTA server and publishing the public key in DNS at the selector-derived location, through configuring the domain-key directive on the virtual MTA with the selector, the domain, and the private key path. The selector mechanism lets a domain run multiple keys, which is what makes rotation possible. The single most important correctness point is that PowerMTA must DKIM-sign with the sender's own domain, the one in the From header, because DMARC requires DKIM alignment and a signature that verifies but signs with the wrong domain passes DKIM yet fails DMARC. The signed headers must include From, the key should be 2048-bit, and the configuration must be verified with a test message that confirms not just that DKIM passes but that the signing domain aligns with the From domain. Operators who generate proper keys, sign with their own domain, and verify alignment, get DKIM that both meets the requirement and satisfies DMARC; operators who confirm only that the signature verifies, as the case shows, can have valid DKIM that never aligns and never satisfies DMARC.