Ex Libris SPF, DKIM and DMARC setup, step by step

For Alma letters sent directly from Ex Libris using your institution's domain, use the appropriate regional SPF include and configure native DKIM in the Mail Handling integration profile. Generate the account's CNAME records, publish them, validate the DNS setup, and then activate DKIM. Keep the SMTP envelope domain consistent with the From domain used by the letters. For an institutional relay or Microsoft Graph route, configure authentication at the system that actually sends the mail. Current Alma mail configuration and outgoing-email implementation notes.

Choose the Alma sending route first

This guide covers outbound Alma letters. Ex Libris and Clarivate operate other products with different sending behavior; an Alma result does not verify Primo Classic, Summon or every Clarivate service.

Record which route the institution uses:

• Direct from Ex Libris with your institution's domain: your DNS authorizes the relevant regional sending service for the customer-owned envelope domain, and Alma's native DKIM workflow supplies branded signing.
• Direct from Ex Libris with an Ex Libris domain: the provider manages that domain's SPF and DKIM. Publishing an include at your institution's unrelated root domain will not change these identities. Keep the provider-domain envelope and From combination consistent.
• Institutional SMTP relay: Alma hands the message to your relay. The relay's administrators own its final outbound SPF identity and DKIM signing configuration.
• Microsoft Graph: Alma submits mail through the configured Microsoft 365 application and user. Treat it as a Microsoft 365 sending route, with separate application access, mailbox authorization and outbound authentication checks.

The native-DKIM steps below are for the first route. Alma's current documentation recommends the institutional-relay approach where that fits the institution's infrastructure. Do not switch routes solely because a generic SPF guide lists an include. Alma route choices and Microsoft Graph integration.

Build the institution's identity and ownership worksheet

Assign an Alma administrator, DNS administrator and mail-system owner. Collect the institution's Alma region, active sending route, envelope address, actual From domains for representative letters, current DMARC policy and any existing integration settings. Save a pre-change copy before modifying anything.

Alma has one Mail Handling integration profile. Edit that profile rather than creating competing mail definitions. The envelope configuration is institution-wide, while visible sender details can vary by letter or library. The addressFrom label controls many letter senders, but some resource-sharing letters use a library's preferred email address. Inventory those exceptions before assuming every letter shares the same domain. Letter configuration and sender-field behavior.

For customer-domain direct sending, use a valid, monitored envelope mailbox for bounces and keep letter From addresses in the same domain. For example, library-bounces@example.edu and loans@example.edu share the domain while serving different purposes. A Reply-To address does not repair a mismatched From or envelope domain. Alma email-domain requirements.

Keep the product constraint separate from DMARC's general relaxed-alignment rules. A related subdomain may satisfy DMARC in some circumstances, but that is not permission to disregard Alma's documented same-domain configuration.

Select the regional SPF authorization for direct sending

SPF checks the SMTP envelope identity and sending IP. It does not simply check the domain displayed to the patron. First confirm that Alma's configured envelope address uses the customer domain whose SPF record you intend to edit. SPF identity specification.

The current Alma technical requirements list these mechanisms:

• APAC: include:spf-ap.exlibrisgroup.com
• Canada: include:spf-ca.exlibrisgroup.com
• China: include:spf-cn.exlibrisgroup.com.cn
• North America: include:spf-na.exlibrisgroup.com
• Europe: include:spf-eu.exlibrisgroup.com

Select the institution's actual service region, not the recipient's location. Use only the required regional authorization. Ex Libris recommends the maintained include rather than copying its current IP addresses, which can change. These entries are for the documented mail-relay gateways, not the much broader application-network ranges elsewhere on the same page. For an environment with special hosting requirements, obtain its current service-specific instructions instead of inferring them from a public-region table. Regional mail-relay table.

Merge the selected mechanism into the existing SPF policy at the actual envelope domain. Retain legitimate employee-mail and application authorizations, their intended ordering, and the final policy. Do not create a second v=spf1 TXT record or paste five regional policies alongside one another.

Evaluate nested DNS-querying terms against SPF's ten-term limit before deployment. Check actual syntax, duplicate policies and DNS dependencies, not merely the number of includes visible in the top-level string. A root SPF policy does not automatically cover an envelope subdomain. Use the SPF consolidation guide if the existing zone already contains multiple selected policies.

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Generate, publish, validate and activate native DKIM

For the customer-domain direct route, use this sequence:

1. Open Configuration → General → External Systems → Integration Profiles and edit the existing Mail Handling profile, or add the profile if none exists. Confirm Send directly from Ex Libris and the intended valid SMTP envelope address.
2. Ensure the profile is active. Select DKIM Setup and save. The developer instructions state that key generation requires all three conditions: an active profile, DKIM Setup selected, and a saved profile.
3. Copy the generated CNAME owner-and-target pairs and give every issued row to the DNS administrator. Ex Libris hosts the public keys behind those aliases and manages key rotation. Do not replace the account output with a universal selector or another institution's values.
4. Publish the CNAMEs. Allow the documented few minutes for generated keys to become available, and check DNS publication separately.
5. Run the DKIM DNS test, labeled Test DKIM DNS Setup in the current help and Validate DKIM DNS Setup in the developer notes. Resolve any reported failure.
6. After successful validation, select DKIM Active and save the profile. Reopen it to confirm the intended active state before scheduling approved message verification.

These stages are documented in Alma's current DKIM procedure and the key-generation and activation notes. A DNS test succeeding before activation does not prove that outgoing messages have started carrying the signature.

Keep all issued rotation-related records. The provider's key-rotation design is a reason to preserve the generated set, not to publish only the selector observed on one message. Private keys remain with the signing system; publish only the issued public aliases. DKIM public-key verification model.

Handle DNS names and collisions safely

Identify the authoritative DNS host for the actual zone. If library.example.edu is delegated separately, its records may belong with a different team from example.edu. The zone's authoritative service, rather than the registrar's branding, determines where a change must be made.

For a hypothetical full owner SELECTOR._domainkey.example.edu, a DNS editor with a relative-name field may need SELECTOR._domainkey; an editor expecting a fully qualified name needs the whole owner. These are placeholders. Verify the published result so the domain suffix is not duplicated.

For an issued signing domain such as library.example.edu, a full owner SELECTOR._domainkey.library.example.edu is SELECTOR._domainkey.library relative to the parent example.edu zone, or SELECTOR._domainkey in a separately delegated library.example.edu zone. If _domainkey.library.example.edu itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

A CNAME value is a hostname, not an https:// URL. Keep issued CNAMEs DNS-only and unflattened. At Cloudflare, leave Flatten off for these records and check for zone-wide flatten-all settings that hide the alias. Coordinate shared-setting changes with the DNS owner. Cloudflare's CNAME verification guidance. If another record already occupies the issued owner, stop and coordinate the conflict; do not remove a working selector or application record without establishing its owner and dependency. A CNAME cannot ordinarily coexist with other data at that name. DNS alias requirements.

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Preserve unrelated TXT verification records and inbound MX records. Adding outbound authentication does not require changing where patrons' replies or employee mail arrive.

Keep institutional relay and Microsoft Graph authentication separate

Institutional SMTP relay

If the profile selects Send using institution mail relay, configure the institution's domain and SMTP host with the mail-system owner. Review required authentication, encryption and permitted connectivity through the institution's normal security process. The relay controls the final envelope and must sign outbound mail with the intended institutional DKIM identity. Alma relay configuration.

Apply the relay provider's current SPF and DKIM requirements. Authorize the systems that actually send to external recipients, rather than adding Ex Libris's direct-sending include by reflex. Inspect a message after the final outbound hop: a relay can rewrite identities or modify signed content. A successful Alma-to-relay connection alone does not establish final SPF, DKIM or DMARC success.

Microsoft Graph

The supported Graph integration uses an application registration, an application-type Mail.Send permission with administrator consent, and the tenant, application and sending-user configuration in Alma. A different From address may also need Send As authorization. Official Graph integration guidance.

Have the Microsoft 365 administrator follow the linked implementation guide, review the permission scope and manage secrets through approved channels. Do not paste client secrets into DNS, article examples or support screenshots. App consent authorizes submission; it does not publish DKIM or establish DMARC alignment. Verify the Microsoft 365 custom-domain signing configuration and inspect the final delivered message on this route. Do not treat Alma's direct-relay CNAMEs as its authentication setup.

Preserve DMARC and establish useful reporting

DMARC passes when SPF or DKIM both passes and aligns with the visible From domain. Relaxed alignment permits the applicable organizational-domain relationship; strict alignment requires an exact domain match. A cryptographically valid provider-domain signature does not establish your institution's branded DKIM alignment. Current DMARC standard.

Read the applicable DMARC policy before editing, including inherited policy for a subdomain. Retain existing enforcement, reporting destinations and alignment modes. Do not replace an established p=reject or p=quarantine policy with p=none merely to make a new letter deliver. Correct the route or signing configuration first.

Where no applicable policy exists, the institution can approve a monitoring rollout using p=none and an aggregate-report destination with a named owner. Confirm authorization for an external reporting destination before expecting reports there. Move toward enforcement only after reviewing all legitimate senders, not just Alma.

Only when no direct or applicable inherited policy exists and the domain owner approves first-time monitoring, publish one TXT policy with v=DMARC1; p=none at the intended From domain’s DMARC owner. For example.edu, the full owner is _dmarc.example.edu, entered as _dmarc in that zone. For library.example.edu, use full owner _dmarc.library.example.edu: _dmarc.library relative to the parent zone, or _dmarc in the separately delegated child zone. Do not create a child monitoring exception to an existing protective policy. The minimal value requests no reports; append ; rua=mailto:APPROVED_REPORT_ADDRESS only after replacing the placeholder with a provisioned, approved destination. DMARC policy publication.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Use EmailAuth or your chosen reporting platform to correlate observed sources and signing identities with the library's actual mail route. Preserve the reporter and reporting interval. Aggregate reports are grouped observations from participating receivers, not a complete ledger of every letter Alma generated. DMARC report interpretation.

Verify authoritative DNS and the provider's validation result

These are read-only query examples with placeholders. Replace the domain, selector, target, envelope domain and authoritative server with the values for your institution:

dig NS example.edu +short
dig @ns1.example.net CNAME SELECTOR._domainkey.example.edu +noall +answer
dig CNAME SELECTOR._domainkey.example.edu +noall +answer
dig TXT GENERATED-TARGET.example.net +noall +answer
dig TXT ENVELOPE-DOMAIN.example.edu +noall +answer
dig TXT _dmarc.example.edu +noall +answer

Check every generated DKIM alias. The authoritative answer should match its issued target, and the target should resolve to usable public key data. At the actual envelope domain, confirm one selected SPF policy and the correct regional authorization for direct sending. If that identity is provider-owned, inspect its policy without changing customer DNS to imitate it.

Compare authoritative and recursive answers. A stale recursive result can lag a correct publication; a wrong authoritative result means the change itself needs correction. Do not treat SERVFAIL, a broken CNAME chain or an empty key as successful propagation. Avoid a fixed “wait 72 hours” rule when the evidence already identifies an error.

Retain the Alma DKIM DNS-test result separately from these queries. Neither verifies a delivered signature, and neither evaluates SPF for the actual connecting sender by itself.

Accept each material letter route with delivered headers

Once implementation and sending are authorized, verify a controlled letter through the selected route. Save and Test sends the Test Letter to the logged-in user's preferred email. Before using it, check that recipient and customize the Test Letter's addressFrom rather than retaining the example address. It is an actual send, not a read-only DNS check. Alma test behavior.

For a branded institutional route, require all of the following:

1. The received visible From uses the intended domain, and the observed envelope identity matches the route's intended configuration.
2. The intended institutional DKIM signature appears. Record its d= and s= values, require the trusted receiver's dkim=pass for that signature, and confirm alignment under the actual DMARC policy.
3. Record the raw SPF result for the real smtp.mailfrom and connecting IP. Investigate fail, softfail, neutral, none, temperror and permerror, even if DKIM makes DMARC pass.
4. Record SPF alignment separately and verify DMARC success for the intended From domain. A different provider signature or unrelated SPF pass is insufficient evidence of branded success.
5. Retain the timestamp, profile route and relevant headers. Include representative material exceptions such as resource-sharing letters and library-specific sender addresses; one Test Letter does not prove their identities.

Use authentication results added by the trusted receiving system, not an arbitrary sender-supplied header. Authentication-Results trust requirements.

Diagnose SPF at the actual smtp.mailfrom owner independently, even when aligned DKIM supplies DMARC pass. fail or softfail means the evaluated policy did not authorize the connecting sender; check the intended route and approved authorization. temperror is a transient evaluation failure, such as a DNS timeout. permerror is a permanent evaluation problem, such as malformed syntax, duplicate SPF policies or an exceeded evaluated DNS-term budget. Repair the specific cause instead of broadening SPF or weakening DMARC. SPF result meanings.

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

For a deliberately provider-domain route, verify its intended provider identities and describe that result honestly. Do not label it customer-domain authentication. Compare direct delivery and any relevant forwarding or relay path separately; later message modification can affect DKIM. Authentication also does not guarantee inbox placement.

Troubleshoot Alma-specific failures

• DKIM controls are missing: verify the selected direct-sending route, active Mail Handling profile and institution's feature availability with Ex Libris. Do not fabricate CNAME values or assume a different product's controls apply.
• DKIM Setup did not produce usable keys: confirm that the profile is active, DKIM Setup is selected and the profile was saved. Allow the generation interval, then inspect the generated records and rerun the DNS test.
• DNS validates but the message has no branded signature: check DKIM Active and saved state, the actual route, and the actual letter's From domain. A relay or Graph message needs that route's signing verification.
• SPF fails after changing the envelope: confirm the valid mailbox domain, authoritative SPF owner and correct region. Check for duplicate policies, excess lookup terms, DNS errors or a provider-owned identity different from the one edited.
• A resource-sharing letter fails while the Test Letter passes: inspect the library's preferred email address and that message's real From value. A label-only review can miss the exception.
• DMARC passes but DKIM fails: aligned SPF can hide a signing defect. Keep the custom DKIM work open until its intended signature passes and aligns.
• Mail reaches the institution but not an external recipient: investigate the final recipient's authentication and delivery evidence. An internal relay acceptance or local filtering exception does not demonstrate the same external result.

Documentation and verification limits

No Alma profile, Microsoft application, DNS record or mail-security setting was changed. No letter was sent and no live institution's delivered headers were tested. Generated values, account availability, permissions, DNS behavior and real-message acceptance remain implementation checks.