Exim can participate on both sides of an email exchange, but enabling one authentication feature does not configure the others. An outbound signature, an inbound verification result and permission to relay are separate decisions. Build a map of those decisions before editing the production configuration.
Establish the actual Exim build and route
Capture the installed version, package source, active configuration and the SMTP transport used for outbound mail. Distribution packages can split configuration across files or generate it from templates. Make changes in that supported configuration layer, not merely in a generated output that the next update will replace. Compare the installed build with its matching Exim specification.
The current Exim documentation places outbound DKIM signing in the SMTP transport and inbound DKIM processing in an ACL. It does not provide an automatic inbound rejection policy merely because signatures are verified. SPF, SRS and DMARC also have their own build and configuration dependencies. Inventory those dependencies before interpreting an absent result as a DNS error.
Configure an authorised signing identity
References: RFC 6376 §3.6.2, RFC 8301 §3.
Identify which authenticated users or applications may send for each domain. Maintain an explicit mapping from authorised sender context to signing domain and key. Do not derive unrestricted signing authority solely from a user-supplied From header. A valid signature on an unauthorised customer domain is an authorisation failure, not an authentication success.
In the appropriate SMTP transport, the relevant signing settings include dkim_domain, dkim_selector and dkim_private_key. Obtain their syntax and expansion rules from your installed-version manual. Generate and protect a suitable key, publish its public record at the chosen selector under _domainkey, and verify public DNS before enabling the signing path. Never put a private key into DNS or a diagnostic ticket.
Exim's dkim_strict option controls whether a signing failure defers a message or permits unsigned delivery. Choose this deliberately with the service owner: fail-closed signing may queue essential mail, while unsigned fallback may fail recipient DMARC checks. Test the selected outcome safely with a controlled missing-key scenario outside production. Strict mode is not a universal must-sign switch: the manual says an empty expanded domain or selector, or a private-key value of 0, false or empty, deliberately skips signing without an error even when dkim_strict is set. Test those no-sign paths separately from an actual signing failure.
Keep inbound policy and relay controls distinct
References: RFC 8601 §5.
Decide which sources are untrusted Internet peers, authenticated submissions and explicitly permitted relays. Preserve relay restrictions when introducing authentication checks. An SPF pass for some domain does not grant permission to use your server as a relay. Similarly, a failed DKIM signature alone does not establish that every message should be rejected; assess the complete authentication and local-policy context.
For inbound evaluation, document where trusted Authentication-Results are created and which upstream results are trusted. Prevent a sender-provided header from being mistaken for your own verification. If DMARC is implemented, verify that its inputs refer to the same message and receiving boundary.
Verify outcomes rather than settings
References: RFC 9989 §4.4.
Illustrative test: an authorised application sends From billing@example.org through the outbound SMTP transport. The receiver reports a passing signature with d=example.org and the configured selector. That is an aligned DKIM path. A second application without permission to use example.org must not acquire that domain's signing authority. These are proposed test cases, not observations from a running Exim server.
Retain tests for normal signing, key unavailability, unauthorised domain requests and any downstream content changes. Record queue effects and receiver results. After release, monitor signing failures, queue growth and authentication failures by route. Keep old public selectors long enough for legitimate in-flight signed mail, using actual queue lifetime and operational evidence to determine retirement. Restore the prior transport configuration if the rollout breaks delivery, without disabling relay controls.