Quick answer: For OCLC-hosted ILLiad notifications using your institution's domain, request DKIM signing from OCLC Support, publish the documented illiad1 selector CNAME, update the applicable SPF policy for ILLiad's sending service, then reopen ILLiad and test a notification. This is not a universal recipe for every OCLC product or a locally hosted ILLiad server.
No account access, DNS changes or live sends were performed for this article.
Confirm that this is your ILLiad sending route
OCLC's procedure specifically addresses hosted ILLiad notification delivery. Establish the institutional sender domain, current mailhost route, DNS administrator and authorized change owner before starting. A local SMTP service or another OCLC application may need different settings.
Inventory the From identities used by borrowing and document-delivery notifications, including routing rules and local configuration. Give OCLC the exact domains that need signing. Support enablement matters: a DNS key can exist while the service is not yet signing your domain. OCLC's hosted ILLiad DKIM procedure
Keep unrelated corporate mail working. If staff also send through Microsoft 365, preserve that route's authorization and use its separate Microsoft 365 DMARC guide.
Ask OCLC to enable signing
Contact OCLC Support and request DKIM signing for the actual institutional sender domain. Include a representative sender address and identify the hosted ILLiad environment. Ask for confirmation that the documented selector and target apply to your deployment, that signing has been enabled, and which signing domain will appear on messages. Do not submit credentials, private keys or patron information.
OCLC's support page distinguishes its Zendesk account from the normal institutional account and offers a guest request route. Use an authorized support channel, not an unsolicited address from an email. Contact OCLC Support
Publish the ILLiad DKIM CNAME
For the documented route, OCLC specifies:
| Field | Value |
|---|---|
| Type | CNAME |
| Selector | illiad1 |
| Full owner | illiad1._domainkey.<your-signing-domain> |
| Target | illiad1.illiad.oclc.org |
Replace only the signing-domain placeholder with the domain confirmed for your account. The target is the published OCLC service target, not a value derived from your institution's name. The CNAME points to the provider-managed TXT public key. Do not publish a screenshot key, an SMTP password or a private signing key. OCLC's DKIM record instructions
Map the owner to the correct DNS zone
For an illustrative signing domain mail.example.edu, the complete owner is illiad1._domainkey.mail.example.edu:
- In
example.edu, a relative-name editor normally needsilliad1._domainkey.mail. - In a delegated
mail.example.eduzone, it normally needsilliad1._domainkey. - In a delegated
_domainkey.mail.example.eduzone, it normally needsilliad1.
Check what your editor appends; do not duplicate the domain suffix. If it expects a full name, enter the full name in its supported format. A hostname is not an HTTP URL.
Before saving, inspect existing data at the owner. Do not overwrite a shared selector or place other record types beside a CNAME. Resolve ownership conflicts with the administrator and OCLC.
Preserve the required CNAME answer
Where a DNS host offers proxying, use DNS-only mode for the authentication CNAME. Disable per-record flattening where that control is available. Ensure applicable zone-wide settings do not suppress the required literal CNAME answer: an apex or same-zone exception can still prevent the required literal CNAME answer. If the actual authoritative service cannot return that answer at the requested owner, stop and resolve the supported configuration rather than substituting an address record. Cloudflare flattening settings and mandatory exceptions
Check the authoritative DNS response for the exact owner and target, then confirm that the target resolves to the intended public-key TXT data. Repeat through a normal recursive resolver after the relevant cache interval. A website loading successfully proves nothing about this record. DKIM key retrieval and selectors
Update SPF at the actual envelope domain
OCLC's linked SPF guidance asks customers to authorize ILLIAD.oclc.org, preferring its domain-based authorization so address changes can be accommodated. In SPF syntax, that domain authorization is an include:illiad.oclc.org mechanism. Treat this as a mechanism to merge into the correct existing policy, not as a complete replacement record. OCLC's ILLiad SPF guidance
First confirm the actual SMTP MAIL FROM domain for your hosted route with OCLC and delivered-message evidence. SPF evaluates that envelope domain, not automatically the visible From address. Do not add the mechanism to an unrelated apex merely because that domain appears in a user's signature.
At the evaluated owner, retain one v=spf1 TXT policy with existing legitimate senders and the approved qualifier. Review the full evaluation path against the ten DNS-dependent-term limit, including nested mechanisms. This is not a limit of ten written includes. An all mechanism causes redirect to be ignored. Avoid copying OCLC's fallback IPs as permanent constants when the documented domain-based method is appropriate. SPF specification
No MX change is required by this procedure. Keep incoming-mail routing untouched. If support proposes an additional routing change for your particular environment, obtain a separate exact-owner, priority and destination review before approving it.
Restart ILLiad and verify an actual notification
After DNS publication and OCLC signing confirmation, close ILLiad, reopen it, and resend a non-sensitive notification to an approved test recipient. OCLC specifies this restart-and-resend step and directs unresolved failures back to Support. Do not assume a DNS lookup or a successful client submission proves delivery. OCLC verification procedure
Inspect the receiver's message details using your receiving service's documented handling of external Authentication-Results. Trust results created inside the known receiving infrastructure after its boundary sanitization, not arbitrary headers or a matching authserv-id label. RFC 8601
For the branded DKIM route, require all of the following:
- The visible From remains the intended institutional address.
- The intended ILLiad signature passes, with the expected selector and confirmed
d=signing domain. - That signing domain aligns with visible From under the applicable DMARC policy.
- The trusted receiver reports
dmarc=pass.
A DMARC pass achieved through SPF alone does not prove DKIM works. Strict DKIM alignment requires identical domains; relaxed alignment uses the same Organizational Domain. Apply the same distinction to the actual SPF identity. A child envelope domain is not an exact match for its parent under strict alignment. DMARC identifier alignment
Preserve DMARC policy and reporting
Do not weaken an existing direct or inherited DMARC policy to accommodate an incomplete setup. Do not add a duplicate policy or change reporting recipients. Creating a first policy is a separate approved task, outside this guide.
For aggregate-report destinations, compare the destination's Organizational Domain with the policy domain's Organizational Domain. If they differ, the report-generating receiver must check DNS authorization; a destination within the same Organizational Domain is excepted. That protocol check does not replace approval for sharing reporting data. RFC 9990, section 4
Troubleshooting
| Finding | Next action |
|---|---|
| CNAME is absent or wrong | Check authoritative zone, duplicated suffix, conflicting data, proxy and flattening settings |
| Public key resolves but DKIM is absent | Confirm OCLC enabled signing for this exact environment/domain and that the tested notification uses the intended route |
| DKIM fails | Compare selector and signing domain, complete public-key retrieval and potential message modifications |
| SPF fail | Check whether the evaluated source is authorized at the real envelope owner |
| SPF temperror | Investigate temporary DNS lookup failure and retry appropriately |
| SPF permerror | Repair duplicate/invalid policy, syntax or lookup-budget problems |
| Authentication passes but DMARC fails | Compare authenticated domains with visible From under actual alignment settings |
| Only some notifications differ | Inspect configured sender identities and email-routing rules for that notification type |
Investigate SPF errors even when DKIM currently makes DMARC pass. Authentication does not guarantee inbox placement; preserve sanitized rejection details and timestamps for Support.
What about OCLC's emergency sender fallback?
OCLC documents an alternative provider-owned From address, donotreply@oclc.org, with corresponding Customization Manager, EmailRouting and LocalInfo changes. That changes the sender identity. It is not proof that your institutional domain now authenticates, and it can change how patrons recognize and reply to messages.
Do not apply that fallback automatically or report it as completion of this branded-domain task. If operational recovery requires it, obtain explicit approval, have the application owner follow the complete OCLC procedure, and keep institutional signing as an unresolved separate task. OCLC fallback scope