Quick answer: For TargetX workflows that actually send through your institution's Salesforce org, configure the Salesforce DKIM route and audit the identities used by each automation. Verifying a domain, activating a DKIM key and proving a delivered message passes authentication are different milestones. This guide does not assume every TargetX communication uses this route.
This is a source-document review, not a hands-on TargetX deployment. No customer account, DNS zone, scheduled job or student message was changed or tested.
Identify the TargetX sending route first
Before editing DNS, build a route worksheet with your TargetX administrator. Name the triggering workflow, environment, institution-owned visible From address, running user, recipients and current evidence. Separate production from sandbox and administrative notices from applicant-facing messages. A staff member saying “the email comes from TargetX” is not sufficient evidence of which system signs it.
This article's configuration applies to the Salesforce-native route documented by Liaison. If a message uses a separate campaign delivery service, relay or another Liaison product, obtain that route's own instructions. Do not reuse Salesforce records merely because the same institution buys both products. Start with EmailAuth's Salesforce product-selection guide for the broader platform distinction.
Follow the documented native setup
Liaison's DKIM instructions specify Setup > DKIM Keys > Create New Key: choose RSA size, unique selector and alternate selector, domain and matching scope; save. Publish both issued CNAMEs, then Activate. Salesforce hosts the public TXT keys and rotates them.
Liaison's sender audit recommends an institution-owned shared address, not default @targetx.com. Verify Organization-Wide Addresses through the inbox link. Check:
| TargetX/Salesforce area | Identity to review |
|---|---|
| Process Automation Settings | Default Workflow User; Automated Process User Email Address |
| All Sites > site > Workspace > Administration > Emails | Each community's verified sender |
| Sites > site > Public Access Settings > Guest User | Institution email and org-wide address |
| Recommendation forms; events; Organization Events; Email Alerts; Flows | Verified sending address |
| Report/dashboard subscriptions | Scheduling user's verified address |
| Scheduled Jobs | Submitted By user's domain |
Affected Apex jobs need controlled rescheduling under the approved user; retain class and schedule first. After sandbox refresh, reverify using either a new DKIM key with both issued CNAMEs and Activate, or Setup > Authorized Email Domains > Add, enter the domain, publish its new issued TXT token, then Verify domain ownership. A verification TXT token is not DKIM signing.
Prepare a safe change packet
The documented controls above are the starting point, not authority to make an indiscriminate bulk change. Have the institutional owner approve the intended sender identities and the scope of each modification. Preserve current settings in a private operational record. Avoid collecting student names or applicant records when a workflow name and synthetic test case will answer the question.
For DKIM, record the exact generated owner names and targets for both CNAMEs. Treat them as issued values, not a reusable template. Keep the selectors unique across environments. Do not paste a private signing key, password or session token into DNS. A public DKIM record is intended to be public; account credentials are not.
At the authoritative DNS host, map each issued full owner to the zone being edited. For an illustrative owner SELECTOR._domainkey.admissions.example.edu, the relative name in example.edu would be SELECTOR._domainkey.admissions; in a separately delegated admissions.example.edu zone it would be SELECTOR._domainkey. An editor may expect the full name instead. Check the completed name to avoid appending the domain twice. If _domainkey itself is delegated, publish in that delegated namespace.
Do not delete an existing TXT or CNAME at the same owner just to make the editor accept the new value. Resolve collisions with the responsible mail administrator or obtain a different selector. Preserve unrelated selectors, MX records, nameservers and existing institutional mail services. Authentication CNAMEs must remain visible as DNS records, not HTTP-proxied website endpoints. If your DNS host flattens CNAMEs, inspect the exact returned record and its per-record or zone-level behavior; do not disable a shared feature globally without reviewing other dependencies. The required end state is the actual issued CNAME aliases published in DNS. If the host cannot expose those aliases, stop and escalate to its support team rather than accepting flattened address answers as equivalent.
Check publication before activation, then check messages
Query the actual authoritative server and compare the recursive result:
dig @AUTHORITATIVE_NAMESERVER CNAME SELECTOR._domainkey.admissions.example.edu +norecurse
dig CNAME SELECTOR._domainkey.admissions.example.edu
dig TXT EXACT_TARGET_FROM_THE_ISSUED_CNAME
These are placeholders, not records to publish. Repeat for the alternate selector. Confirm the exact CNAME target and a resolvable valid public-key record behind it. Investigate missing answers, incorrect suffixes, conflicting records and cached old answers before activation. A successful lookup alone proves neither that the application signs mail nor that the chosen From identity aligns.
Use controlled, non-sensitive test messages for each intended route. Obtain the full received headers and authentication results from within the receiving system's trusted processing boundary. Its administrator must establish how externally supplied Authentication-Results fields are removed or distinguished. A familiar header label or its position alone is insufficient; see RFC 8601.
Record the visible From domain, DKIM signing domain d=, selector s=, signature result, evaluated SPF identity and result, and DMARC result. For this branded DKIM configuration, require the intended signature to pass and align with the intended From domain, as well as receiver dmarc=pass. A pass using an unrelated signature or SPF alone does not prove this DKIM route works. Under RFC 9989, relaxed alignment uses the same Organizational Domain; strict alignment requires an exact domain match.
SPF: inspect the envelope, not just the campus domain
SPF evaluates the SMTP MAIL FROM identity, not automatically the address shown to a student. Identify that envelope domain from a trusted received message before proposing a DNS change. This guide deliberately provides no universal TargetX SPF include. Do not copy a corporate TargetX DNS record, a different Liaison product's value, or a marketing-platform example into institutional DNS.
If the actual sending service documents a customer-managed SPF requirement for the evaluated domain, merge it into the existing policy without removing legitimate senders. Maintain one SPF policy at that owner. Check the limit of ten evaluated DNS-dependent terms, including nested dependencies, rather than counting only top-level includes. redirect is ignored when all is present. These rules are specified in RFC 7208.
Distinguish an SPF fail (the sending host is not authorized under that policy), temperror (a transient evaluation problem) and permerror (an invalid policy or other permanent evaluation problem). Investigate each even if DKIM currently supplies a DMARC pass.
If a provider controls the envelope domain, changing your institution's root SPF cannot change that provider-owned identity. A passing but unaligned SPF result can coexist with a valid aligned DKIM result; conversely, seeing SPF pass does not prove DMARC passes.
Acceptance checklist and failure handling
| Check | Evidence required before marking this route complete |
|---|---|
| Correct workflow and environment | Named TargetX trigger and confirmed Salesforce-native path |
| Intended identity | Approved From domain and actual running/scheduling user |
| DNS | Both issued CNAME owners and targets resolve correctly |
| Application | Correct key is activated and intended sender scope is configured |
| Received message | Intended aligned DKIM passes; trusted receiver reports DMARC pass |
| Operational behaviour | Intended recipient and reply handling work; scheduled workflow still runs |
Do not delete scheduled jobs before documenting their class, timing, timezone, dependencies and recovery plan. Coordinate any stop/recreate window with the application owner, and check for both missed and duplicate executions afterward. DNS rollback alone cannot repair a wrongly rescheduled job. Keep a known-working permitted route available while investigating failures.
Maintain existing DMARC protection. Do not weaken policy merely to hide a failed test. One passing applicant notification does not establish that all institutional senders are ready for enforcement: retain the wider sender inventory and monitor failures across legitimate traffic.
If mail is absent entirely, investigate the application trigger, sender verification and job execution before diagnosing recipient-side authentication. If DNS passes but the intended DKIM signature is missing, inspect activation, scope and the real delivery route. If DKIM passes but DMARC fails, compare the actual signing and From domains against the alignment mode. If authentication passes but delivery is poor, investigate reputation, consent, content and recipient filtering rather than promising an inbox outcome.
Common questions
Does adding an Authorized Email Domains TXT record enable DKIM? No. Ownership verification and cryptographic signing are different functions. Check the signing configuration and the actual received signature separately.
Can one passing test close every TargetX workflow? No. Use the worksheet and acceptance checks for each distinct sending path and environment. Record any routes still outside this guide's evidence rather than declaring blanket TargetX coverage.
Should we publish our private signing key? Never. Use only the public DNS records issued for the approved setup. Keep credentials and private keys out of tickets, page content and DNS.
What should a support escalation contain? Workflow name, environment, sender-domain scope, relevant timestamps, generated record names, activation state and a redacted receiver result. Remove student content and secrets. Ask which stage failed and which team owns the correction.