Technolutions Slate SPF, DKIM and DMARC setup, step by step

For email sent through Technolutions Slate, use Database → DKIM Configuration to generate your domain's DNS records, publish the exact rows displayed, and select Validate Configuration. Slate manages SPF automatically on the envelope-sender subdomain chosen in that configuration. You do not need to add a Slate SPF include to your parent domain for this workflow. Without a DKIM configuration, Slate uses its provider-owned envelope domain instead. Slate DKIM setup and outbound-mail behavior.

Identify the Slate email route and domain

This guide covers outgoing email from a Slate database using Technolutions' documented mail service. It does not claim that every Technolutions product, an unrelated SMTP application or the institution's employee-mail system uses the same authentication records.

Before configuration, collect:

• The Slate database and an administrator who can access DKIM Configuration.
• Each domain actually used after @ in visible From addresses, including departmental subdomains.
• The DNS administrator and the authoritative zone for each domain.
• The proposed envelope subdomain and any existing use of that name.
• The institution's current SPF and DMARC policies and the other services that depend on them.
• A message owner and an approved controlled recipient for later verification.

An admissions address, an alumni address and a student-success address can have different domain requirements even within one institution. Make the domain list from actual message settings, not from the university's website address or the database login URL alone. Keep the sending domain, envelope subdomain and DKIM selector as separate fields in the change record.

Create the DKIM configuration and obtain its DNS values

The current official workflow is:

1. Open Database → DKIM Configuration, enter the email domain, and select Lookup.
2. For a new setup, select Create Configuration from the inactive configuration.
3. Use the default slate-mx subdomain unless IT identifies an existing use. Select Save.
4. Give IT every displayed DNS Records row, including its hostname, record type and value. Review any suggested DMARC TXT record with the existing policy rather than replacing it blindly.
5. After publication, return to the domain and select Validate Configuration. Slate's documented display uses black text for valid records and red for unresolved records. Successful validation enables its DKIM configuration. Current Slate procedure.

Use the values shown in your own database. Do not reconstruct selectors or targets from a screenshot, copy a neighboring institution's records, or publish a guessed slate-mx CNAME before generating the configuration. The subdomain is a configurable choice; its default spelling does not prove that a particular target belongs to this database.

Assign ownership before resolving a collision. If the proposed name already serves another application, reserve a different name through a planned configuration change. Do not delete the existing DNS record just because the onboarding screen expects a CNAME. Rebuilding a configuration can affect active mail, so save the current settings and plan the cutover with IT rather than repeatedly deleting and regenerating it.

Understand why parent-domain SPF is unnecessary

With Slate's configured route, the SMTP MAIL FROM uses the subdomain selected during DKIM setup, and Technolutions manages SPF there. Without that configuration, the documented envelope identity is mx.technolutions.net, also with provider-managed SPF. The provider's outbound IP list can change, and the message type does not choose a particular server. Technolutions outbound servers.

The practical consequence is important: a visible From address such as admissions@example.edu does not mean SPF is evaluated at example.edu. SPF follows the actual envelope identity. Adding an unnecessary parent include increases authorization and lookup complexity without proving anything about Slate's chosen identity.

Leave the parent SPF policy used by employee mail and other applications intact. Do not append a generic SendGrid include merely because you recognize a network behind a mail server. Follow Slate's account-generated records and its managed-envelope design.

At any owner that does publish SPF TXT, there must be one selected policy, not one per vendor. SPF permits a maximum of ten evaluated DNS-dependent terms, including nested processing, along the actual evaluation path; this is not a budget of ten visible include statements. Syntax errors, duplicate policies or excess lookup terms can cause permerror; DNS failures can cause temperror. A successful CNAME query does not evaluate these conditions for the delivered sender. SPF standard.

Publish the CNAME records without disrupting other mail

Check the authoritative zone before opening a DNS editor. If a departmental subdomain is delegated, publishing in the parent zone may not make the needed name visible. Retain the complete generated record list and a copy of pre-change records.

For each CNAME row:

• Enter the owner in the DNS host's expected format. A relative field may need only SELECTOR._domainkey; a full-name field needs SELECTOR._domainkey.example.edu. These are placeholders, not Slate's issued values.
• Copy the target hostname exactly. Do not add https://, a path or an email address.
• Keep issued CNAMEs DNS-only and unflattened, not proxied or redirected. At Cloudflare, leave Flatten off for these records and check whether zone-wide flatten-all settings hide the CNAME response. Coordinate any shared-setting change with the DNS owner. Cloudflare's CNAME verification guidance.
• Stop if another record occupies the same owner. A CNAME cannot ordinarily coexist with other record data at that name.
• Preserve unrelated MX records, verification TXT records and other services' DKIM selectors.

CNAME delegation lets the service maintain the target data, but the institution still owns the names it delegates. Keep the account and domain association in the change record so that future staff know which database uses them. DNS CNAME rules.

For an issued full owner SELECTOR._domainkey.admissions.example.edu, use relative SELECTOR._domainkey.admissions in the parent example.edu zone, SELECTOR._domainkey in delegated admissions.example.edu, or only SELECTOR in delegated _domainkey.admissions.example.edu. An apex-domain key in delegated _domainkey.example.edu also uses relative SELECTOR. Substitute each actual Slate-issued selector, retain NS delegations and publish at the correct authoritative service. DNS zone authority.

Never place a DKIM private key in DNS or a support ticket. Public lookup reaches public verification material; the signing system retains the private key. A selector's existence alone does not show that Slate has begun using it. DKIM verification model.

Also account for mandatory flattening: Cloudflare flattens apex CNAMEs automatically and same-zone targets regardless of the flattening setting. A per-record option cannot override whole-zone flattening. If these behaviors prevent an issued owner from returning its required literal CNAME, stop and coordinate a supported arrangement with the DNS host and Slate rather than inventing a switch or removing delegation. Verify exact issued CNAME answers at authority and recursive resolvers before accepting the configuration. Cloudflare flattening behavior.

Add an additional sending domain deliberately

If a domain is outside the database's permitted domain scope, use Database → Configuration Keys → Allowed Service Domains List. Enter the additional domains as a comma-separated list, save, allow the documented 15–20 minutes for the key change to reach the web servers, then configure each domain in DKIM Configuration. If validation of an additional domain still errors, the official instructions direct you to the Support Desk for completion. Additional-domain instructions.

This application-setting interval is not a promise that DNS caches update in 20 minutes. Keep the two stages separate: application permission to configure a domain, and public availability of its issued DNS records. Adding a domain to an allowlist also does not activate a DKIM signature by itself.

For each new From domain, record whether its identity should be the exact domain or a deliberately aligned related domain. Do not assume that a working admissions configuration covers an unrelated alumni domain.

Keep DMARC enforcement and alignment intentional

DMARC evaluates the visible From domain against authenticated identities. It passes with at least one passing aligned mechanism, SPF or DKIM. Relaxed alignment permits the applicable organizational-domain relationship; strict alignment requires identical domain names. Current DMARC standard.

Consider an illustrative message with From admissions@example.edu and an envelope domain slate-mx.example.edu. An SPF pass can align under relaxed mode, assuming the applicable organizational-domain relationship. It does not meet strict SPF alignment with example.edu. A passing DKIM signature with an aligned d= can still make DMARC pass. Confirm the actual message and policy rather than assuming both mechanisms align.

A provider-owned mx.technolutions.net envelope does not align with an institution's unrelated From domain. Raw SPF success on that fallback identity must not be reported as successful custom-envelope setup. See the custom MAIL FROM verification guide for interpreting this distinction.

Before publishing any DMARC row suggested by Slate, inspect the current applicable policy. Preserve existing enforcement, reporting destinations and strictness settings. Do not create a duplicate record or replace quarantine or reject with none merely to complete the setup screen. For a genuinely new policy, an approved monitoring phase can use p=none and a working aggregate-report destination before a planned enforcement rollout. Confirm receiving-domain authorization when reports go to an external organization.

Only when no direct or applicable inherited policy exists and the domain owner approves an appropriate monitoring plan, a first illustrative record is TXT at _dmarc.example.edu with value v=DMARC1; p=none. In the example.edu zone use relative name _dmarc. For a deliberately separate admissions.example.edu policy, use full owner _dmarc.admissions.example.edu, relative _dmarc.admissions in the parent zone or _dmarc in its delegated child zone. Keep one policy and preserve established protection; do not copy a suggested row over inherited policy.

Before adding a report recipient, separately approve data sharing and retention with the domain owner. Compare the report destination host’s Organizational Domain with the Organizational Domain where the applicable policy was discovered. If different, the receiver generating reports must check external DNS authorization; a destination within the same Organizational Domain is excepted. A different hostname alone is not external, and protocol authorization does not replace owner approval. RFC 9990 section 4.

Verify public DNS, then validate in Slate

Use the generated full owners and targets. The examples below contain placeholders and perform only DNS reads:

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-DKIM-TARGET.example.net +noall +answer
dig CNAME slate-mx.example.edu +noall +answer
dig TXT slate-mx.example.edu +noall +answer
dig TXT _dmarc.example.edu +noall +answer

Choose a nameserver authoritative for the actual zone. Repeat the selector checks for every issued DKIM record, and replace the sample envelope name if your configuration uses another name. Expect each owner to resolve to its issued target and the DKIM path to reach usable public key data. At the envelope name, inspect any alias chain and the resulting SPF policy.

If the authoritative answer is correct but a recursive resolver still returns the old value, investigate caching. If the authoritative answer is wrong, repair publication rather than waiting a fixed number of hours. Repeated DNS errors, an empty DKIM key, a broken target or a duplicated owner suffix are not successful propagation.

Once DNS matches, use Slate's validation action. Retain its result and time, but keep the change open until the message-level checks below pass.

Require branded DKIM success on a received message

After an authorized implementation, send a controlled message through the actual Slate workflow. Do not use an employee mailbox as a substitute for a Slate message. Inspect the original source at the receiving mailbox and use authentication results added by that trusted receiver. Authentication-Results trust model.

Establish the actual receiving service’s known authentication-processing boundary from its documentation or mail administrator and confirm its documented removal, ignoring or distinction of externally supplied Authentication-Results. Ignore attacker-supplied results. Matching authserv-id text or header position alone is not proof. If provenance cannot be established, leave acceptance open and obtain receiver-controlled diagnostics or an administrator-confirmed trace. Forged-header safeguards.

Record these acceptance criteria for each distinct From domain:

1. Expected identity: the visible From domain is the one configured, and the actual smtp.mailfrom uses the intended envelope subdomain rather than the provider default.
2. Intended DKIM pass: identify the custom signature's d= and s=; the receiver reports dkim=pass for that signature, and d= aligns with From under the applicable policy. Another passing signature does not complete this requirement.
3. Raw SPF result: the receiver reports the result for the observed SMTP identity and connecting IP. Investigate fail, softfail, neutral, none, temperror and permerror. Do not hide these behind a DKIM-based DMARC pass.
4. Alignment and DMARC: record SPF alignment separately, then confirm DMARC success for the intended From domain. A raw SPF pass with an unexpected envelope is not proof of custom-envelope success.
5. Operational evidence: retain the message time, recipient system, domain configuration and relevant headers. Repeat for materially different paths and after later changes.

DNS publication, application validation and delivered-message acceptance are three separate checkpoints. Inbox placement is a fourth observation influenced by reputation, recipient policy and content; authentication does not guarantee it.

For SPF fail or softfail, check whether the actual connecting sender is authorized at the observed envelope owner and whether the intended Slate route was used. This differs from transient DNS/evaluation temperror and permanent syntax, duplicate-policy or lookup-budget permerror. Diagnose each even when intended aligned DKIM supplies DMARC pass; an unaligned SPF pass is not the same error. SPF results.

Troubleshoot common Slate failures

Records remain red after IT published them

Compare the account-generated owner, type and target with the authoritative answer. Check the DNS zone, doubled domain suffixes, CNAME collisions, proxying and stale answers. Do not replace all records with static examples from a third-party guide.

The additional domain is refused or will not validate

Review Allowed Service Domains List, allow its documented propagation interval and retry the correct domain. If validation still fails, provide the Support Desk with the exact domain, issued record list, current answers and error. Keep private credentials out of the ticket.

SPF passes but the envelope is still mx.technolutions.net

Check whether DKIM Configuration was completed and validated for the relevant domain. Preserve the received evidence: passing provider SPF is different from the configured institutional envelope. Do not try to solve that identity mismatch by adding another parent SPF record.

DMARC passes but the branded DKIM signature fails

SPF may be carrying the DMARC result. Confirm that the intended selector is active, its public key resolves and no downstream system modifies signed content. The DKIM work remains incomplete until the intended signature both passes and aligns.

Only one department reports failures

Compare its actual From domain and workflow with the working department. Check additional-domain authorization, per-domain DKIM configuration, inherited DMARC policy and strict alignment. Preserve message evidence before changing a shared institution-wide policy.

Documentation and verification limits

This is documentary guidance. No Slate account, DNS zone or DMARC policy was changed, and no message was sent or examined from a live institution. Generated values, access permissions and actual delivered results remain implementation checks.