Scope and preparation
This procedure covers outgoing Technolutions Slate mail. Obtain a Slate administrator and the institution's DNS owner. Record every intended From domain, including admissions and alumni flows that may use different domains. Preserve current DNS and the old configuration before changing an established route. No tenant access or actual message test was performed for this guide.
Generate and validate the domain configuration
Open Database > DKIM Configuration, look up the email domain and create its configuration. Use the suggested slate-mx subdomain only if it is unused. Save, then pass every generated DNS row to IT, including any DMARC row for review against existing policy. Return to Validate Configuration after publication. The provider uses black entries for valid records and red for unresolved ones. Additional domains outside the permitted scope need the Allowed Service Domains List under Configuration Keys; validation errors may require support. Follow the current Slate configuration source below.
Keep SPF changes on the correct identity
Technolutions says the configured subdomain supplies the envelope sender and has provider-managed SPF. Without DKIM setup, the envelope uses mx.technolutions.net. Its outbound-server article says parent-domain SPF additions are unnecessary for that route. Do not hard-code the listed server IP addresses into the institution's SPF merely because they appear in a source: the provider says that list can change.
Original institutional test design
Create separate worksheet rows for admissions and alumni messages. For each, record the requested From, actual From, envelope, DKIM signing domain, selector and trusted receiver results. A validation screenshot alone does not demonstrate which domain the message used. These are test instructions, not captured Slate outputs.
One useful negative case is an allowed-domain configuration that has not yet become available in the application. Retry the lookup after the provider's documented propagation interval, but distinguish application availability from DNS cache expiry. Do not delete a working setup just to make the status change. Have IT identify the conflict first and preserve a rollback route.
Prove the identity at the receiver
Use a controlled external mailbox and send through the production workflow, with harmless content and no customer data. Save the raw message, timestamp and the receiving system's Authentication-Results. Ignore authentication assertions inserted by an untrusted sender. Record the visible From domain, Return-Path or authenticated envelope identity, and every DKIM d= and s= pair. A display name or Reply-To address is not the DMARC identity.
SPF pass authorizes the connecting server for the evaluated envelope identity. DKIM pass validates a signature for its signing domain. DMARC needs a passing method whose domain aligns with the visible From: strict alignment requires the same domain; relaxed alignment permits the applicable organizational-domain relationship. A provider-owned signature can pass without authenticating your visible From. One passing aligned DKIM signature can satisfy DMARC even when another signature fails. These protocol rules come from RFC 7208, RFC 6376 and RFC 9989, listed below.
Check authoritative DNS before diagnosing caches. Ask an authoritative server for the exact name and type, then compare a recursive resolver after its cached lifetime. For DKIM, follow any CNAME to its public-key TXT response. Never publish a private key. Keep one SPF policy at each evaluated name and check the ten DNS-lookup-causing-term limit across nested includes. Do not replace a shared SPF policy with a provider example.
Recovery and acceptance
Pause the affected workflow if tests show a new regression. Compare the changed record with the saved version and undo only that change after checking other senders. Recheck DNS and resend after recovery; reverting a value does not flush every resolver immediately. Keep old DKIM verification records available while previously signed messages may still be in transit, unless a security incident requires revocation.
Accept the change only when DNS, application state and a real received message agree. Record the flow owner, evidence timestamp and next review trigger. Inbox placement alone is not proof of authentication, and successful authentication does not guarantee inbox placement. Do not tighten a shared domain's DMARC policy on the strength of one provider's test. Inventory the other legitimate sources first.
Follow an additional-domain state ledger
Written case SL-01 assumes the institution needs alumni@example.org, but that domain is outside its instance’s permitted scope. The administrator has saved example.org in Allowed Service Domains List; the illustrative elapsed time is five minutes, configuration availability remains unknown, and no DKIM record has been generated for it. The documented 15–20 minute application propagation window is distinct from DNS caching. The Slate owner should wait that interval, retry the lookup and follow the generated-domain validation workflow before testing alumni mail. From, envelope and all receiver results remain unknown. Do not remove an unrelated working admissions configuration. No institution data, configuration key or message was accessed.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.