Seismic Learning SPF, DKIM and DMARC setup, step by step

Quick answer: Authenticate your sending domain through Seismic Learning Support, not by copying Seismic's own DKIM keys into your DNS. Support prepares the domain authentication in its SendGrid account, sends your nominated contact the required DNS records, and verifies the configuration after you confirm publication. The confirmation link expires after 48 hours. Use the exact account-issued packet and prove the intended Learning signature passes and aligns with your visible From domain before treating setup as complete.

This is documentary guidance, not a tested customer deployment. No account, DNS record, support request or email send was performed for this article.

Which Seismic emails does this cover?

This guide covers Seismic Learning, formerly Lessonly, and its support-assisted domain authentication for learning assignment notifications. It does not establish the sending configuration of every Seismic product, a connected employee mailbox, or every future platform migration.

When an authorized assignor distributes learning content, the notification can appear to come from that person's email address even though Learning sends it. That distinction explains why authenticating the employee's normal mailbox alone may not authenticate the application notification. Confirm the actual Learning account, sending workflow, intended From address and domain with your administrator before requesting records. Keep production and test environments separate.

Seismic's domain-authentication procedure documents the support-assisted route. Its email-delivery article also describes provider-domain signing and an optional switch away from the assignor address. Those are different identity choices, not interchangeable proof that your own domain is authenticated.

Prepare the domain and approval packet

Choose an institution- or company-controlled domain for the intended From address. Confirm who administers its authoritative DNS, who can approve a new sending service, and who will receive and complete the support handoff. A website login or an employee inbox does not necessarily grant DNS authority.

Before changes, retain the current DNS records and relevant Learning notification settings in your operational change record. Include the requested domain, account identifier, purpose, nominated contact and rollback owner. Do not include employee or learner personal information when a synthetic test case will suffice. Never send passwords, private signing keys or recovery codes as part of an ordinary DNS request.

Have the domain owner approve the records actually supplied, including any delegated hostname or additional tracking records, rather than approving an unspecified change to the entire zone. Do not modify MX, nameservers, DNSSEC, existing DMARC enforcement or unrelated sender records merely to accommodate this setup.

Request and complete Learning domain authentication

1. Contact support@lessonly.com through your established Learning support process and request domain authentication for the exact Learning account and intended sending domain. The official procedure uses this address even though the product is branded Seismic Learning.
2. Nominate the person who can coordinate DNS publication and confirmation. Support creates the authentication in Learning's SendGrid account; do not create a separate personal SendGrid account and assume it controls Learning's messages.
3. Discuss selector collisions before issuance. Seismic documents lly as its default custom selector choice and permits a requested three-character alternative. This is not a complete DNS owner name or authorization to invent the final selector records. The issued packet determines every record's exact type, owner and value.
4. Obtain the DNS handoff from Support and verify it through that established support conversation. Record every issued tuple and its purpose. If the packet omits a type, owner, target, or publication requirement, resolve that omission before editing DNS.
5. Publish the approved records in the authoritative zone. Follow the field and collision checks below. Then confirm the requested publication using the support handoff within its 48-hour validity window.
6. Have Learning Support verify the configuration in its SendGrid account. Retain that confirmation. An expired link needs a renewed handoff; do not guess a replacement URL or assume DNS publication alone completed the provider-side process.
7. Validate a fresh, controlled assignment notification after Support confirms completion. Successful provider verification and successful delivered authentication are separate acceptance checks.

For background on the underlying service, see EmailAuth’s SendGrid domain-authentication guide. Its self-service procedure does not replace the Learning Support handoff above.

The official article does not publish a universal record count, complete customer record set, plan entitlement or custom return-path guarantee. This guide therefore does not prescribe a fixed set of CNAMEs, universal SPF include, or an invented Enable DKIM button.

Publish the issued DNS records safely

Copy values from the current Support-issued packet, not another customer's screenshot or a generic SendGrid tutorial. For each tuple, check the completed fully qualified owner name, record type, exact value or target, and the zone in which it belongs.

For an illustrative issued name SELECTOR._domainkey.training.example.com, a DNS editor for example.com may need the relative name SELECTOR._domainkey.training. In a separately delegated training.example.com zone, the relative name would be SELECTOR._domainkey. An editor requiring full names needs the entire issued name instead. If _domainkey.training.example.com is delegated separately, the relative owner in that zone is SELECTOR. SELECTOR and example.com here are placeholders, not Learning settings.

For an issued CNAME, preserve its exact target. Check that no other data already occupies its owner. Resolve a collision with the mail administrator and Support; do not remove another sender's record. Use DNS-only behavior where a DNS host offers HTTP proxying. Ensure flattening settings do not replace a required literal CNAME response with address answers. Where a per-record flattening control is available, turn it off for the issued CNAME. Ensure the applicable zone-wide and same-zone rules also preserve the required literal CNAME answer. Some hosts impose default or mandatory apex flattening, or flatten same-zone targets even when a general switch appears off. If the host cannot preserve the required literal CNAME at the issued owner, stop and resolve the supported publication route with the DNS host and Learning Support. Do not disable shared zone behavior without assessing its other users.

For an issued TXT value, preserve the complete contents and publish it only at the specified owner. TXT verification tokens are not automatically DKIM keys or SPF policies. Query the authoritative nameservers and then independent recursive resolvers to confirm the records exist at the intended names; allow for cache expiry. A successful DNS lookup still does not prove Learning has started signing with your domain.

SPF: avoid the conflicting generic recipe

Seismic's general delivery article shows an SPF example using include:em9009.seismic.com, then identifies seismic.com in its explanatory line. Because those are different names, this guide does not choose one, combine them, or recommend either as a universal customer recipe. Use the current support-issued authentication packet and obtain clarification for any required customer-managed SPF change.

SPF checks the SMTP MAIL FROM identity, or HELO in the applicable empty-envelope case, not automatically the address displayed in the From field. Determine which envelope domain a fresh Learning message actually uses. If it is provider-controlled, editing the SPF policy of your visible From domain does not alter that provider domain's SPF result. Ask Support to confirm the envelope scope; do not assume a custom return-path is available.

Where a confirmed customer-managed SPF change is required, merge the authorized mechanism into the one existing SPF policy at that owner, retaining other legitimate senders and the approved policy ending. Check the ten evaluated DNS-dependent-term limit, including nested includes and redirects. An all mechanism causes redirect to be ignored. Do not replace your policy with an illustrative example or add a second SPF policy. These evaluation rules come from RFC 7208.

DKIM and DMARC: check your domain, not just a green result

The general Seismic article describes keys under Seismic's domain. These are not keys to copy into your company's DNS. A valid provider-domain signature is also not proof of alignment with your company From address. Domain authentication must be evaluated on the actual emitted message.

Use a trusted receiving system that identifies its own authentication evaluation and strips or clearly distinguishes untrusted incoming Authentication-Results headers. Header position or a familiar-looking server identifier alone is insufficient trust evidence. For the controlled message, retain:

Relaxed alignment compares organizational domains; strict alignment requires the relevant domains to match exactly. DKIM and SPF alignment modes are independent. A DMARC pass achieved only through SPF does not prove your intended DKIM setup succeeded. Nor does rewriting From to a provider domain prove your original branded identity is working.

Preserve existing direct or inherited DMARC enforcement while onboarding Learning. If your domain has no effective policy, plan an approved monitoring-first deployment with your mail administrator rather than blindly replacing existing records. If adding aggregate reports, authorize who receives them; a destination in a different Organizational Domain from the policy domain requires the receiver's DNS authorization under RFC 9990 section 4. A destination in the same Organizational Domain as the policy domain is exempt from that external authorization requirement. Compare against the policy domain, not an arbitrary subdomain. Do not send reports to a third party without privacy approval.

Troubleshooting and rollback

Seismic documents Settings > Notifications > Send assignment emails from assignor as the control for changing away from assignor-address notifications. Disabling it switches to a documented provider-address mode. That is an identity-changing fallback, not completion of your branded domain authentication. Obtain business approval, confirm the actual From and reply behavior on a controlled message, and assess user expectations before using it.

For rollback, coordinate the sending state with Support before removing newly issued records. Restore only the approved changes from your saved baseline; do not remove shared selectors or another service's SPF authorization. Pause affected notifications if you cannot establish a safe authenticated route. DNS caching means restoration is not necessarily immediate.

Sources

• Seismic Learning: How to Authenticate a Domain; support issuance, selector choice, 48-hour handoff and verification.
• Seismic Learning: Improve Email Deliverability; notification identity, general SPF guidance, provider signing and fallback control.
• RFC 7208: SPF, RFC 6376: DKIM, RFC 9989: DMARC, and RFC 9990: DMARC aggregate reporting, for protocol evaluation and reporting boundaries.