Scope Ex Libris authentication to Alma’s outgoing mail route
Ex Libris offers several products and delivery arrangements. This guide covers Alma letters and the Mail Handling integration profile described in the official documentation, not a universal configuration for every Ex Libris application. Begin by identifying whether Alma sends directly from the Ex Libris cloud, hands mail to an institutional relay, or uses another supported route. Those choices change who controls sending authorization, signing and the final outbound connection. A functioning library website or incoming mailbox is not evidence that Alma's outgoing messages are authenticated.
The Configuring Alma Letters documentation describes the relevant settings. The official Outgoing emails configuration article, updated February 24, 2026, gives additional direct-cloud DKIM details. Confirm current tenant applicability before changing a profile. No account, DNS zone, library patron record or real message has been inspected for this manuscript.
Inventory the author and envelope identities separately
Alma's documentation distinguishes the visible From address from SMTP EnvelopeFrom. The developer article describes one envelope address for the institution, while letter and library settings can supply different visible author addresses. Some resource-sharing letters use a library's preferred email address, and other letter categories have their own exceptions. Therefore, reviewing one generic test letter cannot automatically establish that every production notice uses the same author identity.
Create an inventory of the material letter categories, their effective From domain and the envelope domain used by the selected transport. Include operational exceptions such as resource-sharing correspondence, acquisition messages and patron notices where relevant. Do not copy patron addresses or circulation details into the inventory: the purpose is to map configuration and identity boundaries, not collect message contents. RFC 7208, section 2.4 identifies MAIL FROM as an SPF identity; the visible From domain is a separate input to DMARC alignment.
Choose the integration profile and route deliberately
The documented path is Configuration, General, External Systems, Integration Profiles, with Mail Handling as the integration type. Alma allows one mail-handling integration profile; an existing one should be reviewed rather than assuming a second independent profile can be added for a small experiment. The guide describes Send directly from Ex Libris and Send using institution mail relay, and it also lists an MS Graph API option. This article does not configure Graph applications, secrets or permissions.
For the institutional relay route, the institution's mail operators own the relay's authorization and signing policy. Confirm the handoff and resulting identities with them before applying cloud-specific DNS instructions. For the direct-cloud route, the Alma Letters documentation requires SMTP EnvelopeFrom and header.From to use the same domain. Check that exact domain equality for each effective letter author identity. This is an Alma implementation constraint, not a statement that DMARC generally requires exact equality: relaxed DMARC alignment can permit different domains within the applicable organizational-domain relationship. The developer configuration table does not support treating a provider envelope with a custom author domain as a working direct-cloud DKIM arrangement. Confirm the current tenant and route requirements rather than assuming a protocol-level alignment possibility makes an unsupported Alma combination valid. An approved route choice should identify who can change it, who will observe delivery continuity and how the previous configuration would be restored if the change fails. Publishing a DNS record does not itself switch the delivery route.
Configure direct-cloud DKIM from generated values
The Alma Letters guide describes selecting DKIM Setup, obtaining CNAME details, publishing the issued alias through the institution's DNS administrator, testing DNS setup, and then selecting DKIM Active after a successful check. The developer article adds an important prerequisite: keys are generated when the integration profile is active, DKIM Setup is selected and the profile is saved. Allow the service's documented generation process to complete before interpreting an immediate absence of key data as a permanent failure.
The public key is hosted in Ex Libris DNS, while the institution publishes the generated CNAME pointing to it. The official explanation describes two key pairs supporting rotation. Preserve the exact issued aliases and targets instead of inventing selector names or copying another institution's configuration. Delegating a key location through CNAME is an ongoing dependency on the provider's key management, not a one-time proof that all future messages will validate.
The two sources use Test DKIM DNS Setup and Validate DKIM DNS Setup wording. Treat this as interface wording to confirm in the current account, not evidence for two different mandatory validation systems. DNS validation and DKIM Active are distinct checkpoints. A record can be published while signing remains inactive. Conversely, enabling signing does not repair a wrong DNS owner or target. Retain the actual status and its time without calling it a receiver-level acceptance test.
Review SPF and alignment without importing protocol shortcuts
The Alma documentation says the appropriate SPF include depends on the customer's region. Obtain the applicable regional authorization from the current official account context and review it within the existing policy. This article does not supply an assumed universal include or reusable relay IP list. Keep legitimate senders represented until their ownership and continued use have been checked, and avoid creating a second competing SPF policy at the same owner.
RFC 7208, sections 3.2 and 4.6.4 govern multiple SPF records and evaluated DNS-dependent term limits. Some provider explanations use From terminology loosely; assess SPF against the actual envelope identity rather than applying that shorthand to the visible author field. RFC 6376, section 3.5 defines the signature's domain and selector. RFC 9989, section 4.4 supplies the alignment rule: a passing authentication result must relate appropriately to the author domain. A provider-owned default identity does not prove custom-domain alignment.
Treat Save and Test as a real message action
The official documentation explains that Save and Test sends a message to the logged-in user's preferred email address. The developer article identifies the Test letter and says its enabled state and addressFrom configuration matter. This is not a passive status refresh. Before an authorized operator runs it, confirm the destination, use harmless test content and understand whether the action also saves a configuration change.
A successful test can provide evidence for that profile and letter, but the acceptance plan should include other materially different production letter identities. Use trusted receiver results and record the actual route, signing domain, selector and author domain. Do not forward real patron notices to an external diagnostic service merely to obtain a score. Authentication success is narrower than inbox placement or proof that a patron read an overdue notice. No Save and Test action or other message transmission was performed here.
Fictional diagnosis: the test letter hides a library-specific author
A fictional institution, Cedar Vale Library, validates its direct-cloud DKIM aliases and activates signing. Its general Test letter uses the main institution domain, while a resource-sharing letter uses a branch library's preferred address on another domain. A reviewer initially accepts the whole mail portfolio from the test result. The identity inventory reveals that the branch letter was outside the tested author-domain scope.
The proposed response is to keep that category unresolved, confirm its effective address source and decide whether its identity should change or receive separately supported authentication configuration. It is not to assume that a successful alias lookup covers every library brand. This fictional case contains no real tenant state, patron information, message header or executed DNS observation.
Blank acceptance worksheet and release boundary
- Alma tenant, applicable documentation and selected transport: ______
- Existing Mail Handling profile and approved change scope: ______
- Envelope domain and effective author domains by letter category: ______
- Direct-cloud same-domain EnvelopeFrom/header.From check for each category and current Alma applicability: ______
- Generated CNAME owner/target references and DNS owner: ______
- Profile active/save state, DNS validation and DKIM Active evidence: ______
- Regional SPF authorization and complete-policy review: ______
- Approved test destination and harmless Test letter configuration: ______
- Trusted received-message evidence for each material identity: ______
- Exceptions, rollback owner and release decision: ______
Original implementation evidence, human subject-matter review, current applicability, production-route acceptance, visual accessibility and owner release remain open. The broader catalogue requirement still needs authorized implementation and message evidence. This Alma-scoped documentary guide does not claim all Ex Libris products are configured or that any actual deployment has passed acceptance.