On this page: Which Concep product and sending route does this cover? · Prepare the domains and change ownership · Set up the corporate-domain SPF authorization safely · Set up the dedicated subdomain without record collisions · Obtain the DKIM records and finish provider activation · Keep DMARC policy and alignment separate · Verify public DNS and a delivered campaign · Troubleshooting and frequently asked questions · Documentation review and testing boundary
To authenticate Concep SEND mail, first choose the corporate domain or dedicated subdomain you will send from. Publish the appropriate domain records, have Litera apply the domain and enable signing for the account, then verify the intended branded DKIM signature and the actual SPF identity in a delivered message. DNS publication alone does not complete the provider-side setup. Litera's domain configuration guide.
Which Concep product and sending route does this cover?
Litera now labels its EU and US login portals Foundation Marketing (formerly Concep). This guide follows the Concep sending-domain workflow retained in Litera's Foundation Marketing support documentation. It does not imply that every Litera product, account region or separately connected mail transport uses these records. Current product identity and login portals.
There are two documented domain choices:
| Choice | Purpose | Documented starting point |
|---|---|---|
Corporate domain, such as example.com |
Campaign sender address | Add the Concep authorization to the existing SPF TXT policy where required; arrange branded DKIM |
Dedicated subdomain, such as ecomms.example.com |
Campaign sender and branded campaign links | CNAME to emailcc.com, followed by Litera's account/domain setup |
Litera says only the subdomain arrangement hosts branded campaign links; otherwise links use emailcc.com. A working link proves neither DKIM signing nor DMARC alignment. The current guide requires a subdomain unused by another platform and says supporting A/MX infrastructure for this arrangement is managed on Litera's side. Do not transplant that CNAME onto your corporate domain. Domain choices and prerequisites.
Prepare the domains and change ownership
Record the account region, intended visible From address, campaign link hostname, expected envelope/return-path domain, and intended DKIM signing domain. Ask support to resolve any unknown identity rather than infer it from a product name. Include every account that will use the domain.
Have the DNS administrator export existing records and identify active mailbox, website and marketing uses. For a shared corporate domain, list other legitimate senders before editing SPF. Preserve existing DKIM selectors and the current DMARC policy, including subdomain policy and alignment settings.
For a new campaign subdomain, choose an unused name. A hostname already serving a website, inbound mail or another sending platform is not a clean replacement target. Agree on the scope of any migration and how ongoing links, replies and queued messages will continue to work before altering it.
Set up the corporate-domain SPF authorization safely
Litera's corporate-domain instructions identify this mechanism:
include:emailcc.com
That is an authorization term, not a complete replacement for your organization's existing SPF policy. The provider's example contains an entire policy string, but “append” must not be interpreted as adding a second v=spf1 record or concatenating two complete policies. Corporate-domain guidance, SPF record selection.
For illustration only, if a domain already authorizes the documentation-only IP address below, a merge preserves that sender and the existing ending:
Before: v=spf1 ip4:192.0.2.25 ~all
After: v=spf1 ip4:192.0.2.25 include:emailcc.com ~all
Do not publish the example IP. Use the actual existing policy, retaining every necessary authorization and the chosen final qualifier. If SPF uses redirect=, evaluate that existing design rather than casually appending terms or another all. An all mechanism causes redirect to be ignored, so adding all to a redirected policy can disable its intended authorization path. Review the evaluated design before merging. Preserve qualifiers; they do not guarantee delivery or rejection. SPF redirect semantics.
SPF checks the SMTP MAIL FROM domain, normally visible in the delivered Return-Path. It does not authenticate the visible From address merely because both contain your brand. Confirm which envelope domain Concep actually uses. An include at example.com cannot fix SPF evaluated at a different domain, and SPF at a parent is not inherited by its children. For a null reverse-path, SPF uses the HELO identity. SPF identity rules.
Evaluate the complete nested SPF path. The limit is ten evaluated DNS-querying terms, not ten visible includes. Nested include, a, mx, ptr, exists and redirect can consume that budget; ip4, ip6 and all do not. Do not flatten provider IPs manually without a maintenance process. SPF evaluation limits.
Set up the dedicated subdomain without record collisions
The documented Concep arrangement has this shape. ecomms.example.com is a fictional customer hostname, not a required label:
ecomms.example.com. CNAME emailcc.com.
In the example.com zone, an editor that automatically appends the zone usually expects ecomms. Check its preview: the final owner must be ecomms.example.com, not ecomms.example.com.example.com. The target is a hostname, not https://emailcc.com.
Do not add ordinary TXT, MX, A or AAAA data at that same CNAME owner. A CNAME cannot coexist with ordinary other data at its owner. DNS alias rules.
If Cloudflare hosts the record, use DNS only, with Flatten off for that record, and check that CNAME flattening for all CNAME records is off at zone level. DNS-only status alone is insufficient when flattening suppresses the alias. Coordinate any zone-wide change with the DNS owner and review other services that rely on it; do not silently change a shared setting for one campaign. If an NS delegation makes another provider authoritative, fix the record there instead of removing the delegation casually. If mandatory apex or same-zone flattening prevents a literal CNAME answer, stop and coordinate a supported hostname/design with Litera and the DNS owner; do not invent a switch or remove shared delegations. Then query the public CNAME again. Cloudflare CNAME verification troubleshooting, record-level and zone-wide flattening.
This is not an instruction to delegate all organizational DNS or move employee-mail MX records. A child zone delegated with NS records is a different arrangement from a CNAME. If ecomms.example.com is already a delegated zone apex, it has SOA/NS data and cannot simply become this ordinary CNAME. Resolve the design with the DNS owner and Litera, preferably using a clean hostname.
After the alias resolves, ask Litera to apply the branded subdomain to the intended accounts and complete DKIM setup. Before approving this arrangement, obtain Litera's exact provider-managed routing destinations and A/MX consequences for the chosen hostname and compare them with the authorized routing plan. Approve any inbound-mail/feedback or forwarding change explicitly; the fact that Litera manages those records is not approval to redirect existing traffic. Preserve corporate MX, parent nameservers and DNSSEC. The current page's “single CNAME” statement concerns applying that domain arrangement. It does not justify inventing a universal DKIM selector or disregarding account-specific signing instructions. Provider-side completion step.
Obtain the DKIM records and finish provider activation
Concep's detailed Signing with DKIM article, describes a support-assisted sequence: establish the sending domain first, request DKIM, publish the supplied public TXT key, notify support, and let support verify publication and switch the accounts to its signing infrastructure. It also describes a provider test for dkim=pass. Use this as the documented detailed sequence, with Litera confirming its applicability to your current account; the newer domain guide also retains a provider-controlled DKIM handoff. Concep DKIM workflow.
Obtain the exact record type, full owner, public value, signing domain and selector from support. Do not choose a selector or generate a replacement key independently. Publish only the public record; private signing material does not belong in DNS.
For an issued selector represented here as ISSUED_SELECTOR, these are naming examples, not provider-generated records:
| Intended signing domain | Full DKIM owner | Relative owner in example.com zone |
|---|---|---|
example.com |
ISSUED_SELECTOR._domainkey.example.com |
ISSUED_SELECTOR._domainkey |
news.example.com |
ISSUED_SELECTOR._domainkey.news.example.com |
ISSUED_SELECTOR._domainkey.news |
If news.example.com is instead an NS-delegated zone, publish in that zone using ISSUED_SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated to a DNS service, the record belongs in that service's zone at ISSUED_SELECTOR. These examples explain DNS ownership, not a request to create new delegations.
Keep a long TXT public key as one logical record. DNS can represent it as multiple character strings inside the same TXT record; do not create separate keys or insert spaces into the public-key material. Preserve existing selectors until the sending provider confirms their retirement. DKIM key storage, TXT format.
Track DNS publication and provider activation separately. Repeatedly replacing a valid key will not make an account start signing. Obtain Litera's completion confirmation, then perform your own controlled message check.
Keep DMARC policy and alignment separate
DMARC passes when at least one of these succeeds: SPF passes with an aligned envelope domain, or DKIM passes with an aligned signing domain. Relaxed alignment requires the same organizational domain; strict aspf=s or adkim=s requires an exact domain match. For a hypothetical visible From news.example.com, a passing signature with d=example.com aligns in relaxed mode but not strict mode. A passing signature with d=news.example.com exactly matches that From domain in either mode. These are identity examples, not observed Concep test results. DMARC alignment.
Do not lower an existing p=quarantine or p=reject policy just to begin Concep setup. Inspect the policy for the actual visible From domain and the applicable parent-domain policy when no exact-domain record exists. Preserve intentional subdomain controls.
For a domain with no existing applicable policy, an approved monitoring rollout can start with a record such as this fictional example:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
For the full owner _dmarc.example.com, use relative owner _dmarc in an editor that appends the example.com zone. Use a real, authorized reporting destination. Do not paste the example mailbox into DNS. If the From domain is news.example.com, an explicit policy for it belongs at _dmarc.news.example.com: use _dmarc.news in the parent zone or _dmarc in an independently delegated news.example.com zone. Avoid a second DMARC record at the same owner.
Aggregate reports help identify sending sources and alignment failures over time. Compare the Organizational Domain of the domain where the DMARC policy was found with that of the aggregate-report URI host. If they differ, the report-generating receiver must check the destination's DNS authorization; a destination within the same Organizational Domain is excepted, even if the hostnames differ. External reporting authorization, RFC 9990 section 4. That protocol permission is separate from the domain owner's approval to share report data with the recipient. Retain approved destinations and privacy controls; do not copy another organization's reporting address. Do not add failure-reporting addresses by default; those reports can expose message information. Increase enforcement only after checking all legitimate senders, not just one Concep test. DMARC reporting.
Verify public DNS and a delivered campaign
Replace the fictional domain and selector before running these read-only queries:
dig +short CNAME ecomms.example.com
dig +short TXT example.com
dig +short TXT ISSUED_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com
Use the corporate TXT query for the corporate-domain arrangement and the alias query for the subdomain arrangement. Query the actual envelope domain as well; a root-domain lookup is not enough when MAIL FROM differs. If support supplies a CNAME for a particular signing record, query that record type and verify the resolved key rather than forcing the TXT example onto it.
Expect the correct public owner and target/key, a single selected SPF policy where TXT SPF applies, and one applicable DMARC policy. Compare authoritative DNS and an independent recursive resolver if they disagree. TTL and negative caching can delay visibility; waiting does not repair an incorrect owner or unfinished activation.
After activation, send a harmless test through the same Concep campaign account, From domain and sender-personalization settings used for production to a mailbox you control. This is a step for an authorized operator; no message was sent for this guide. Inspect the receiving system's Authentication-Results and original headers. Use only results generated inside the receiving service's known processing boundary. Establish that boundary from the service's documented removal or isolation of externally supplied Authentication-Results, or use its authenticated message diagnostics/logs. A familiar authserv-id string or a header's position alone proves nothing; ignore attacker-inserted or otherwise untrusted result fields. Receiver trust and forged results.
Use this acceptance checklist:
- Record the visible From domain, Return-Path and
smtp.mailfromidentity. - Find the intended branded DKIM signature. Require
dkim=passfor its exactd=signing domain and expecteds=selector, and confirm thatd=aligns with From under the actual policy. - Require SPF to pass for the expected envelope identity on the direct route. If it passes for a provider domain but is unaligned, record that distinction; aligned DKIM can still satisfy DMARC.
- Require
dmarc=passfor the intended From domain. A DMARC pass through SPF alone does not prove that the DKIM setup being tested works. - Record campaign/account, recipient system and test time; test each intended domain/account route and review subsequent aggregate reports.
A rewritten unrelated From is not successful authentication of the intended brand. For interpreting a delivered message, see EmailAuth's raw DKIM results versus aligned DKIM policy results.
A real spf=fail, softfail, permerror, temperror or unexpected none is not “normal unaligned SPF.” Investigate fail as an authorization/route issue, permerror as a policy syntax, duplicate-policy or lookup-budget issue, and temperror as a temporary DNS/resolver issue. Review softfail/none against the intended route too. Compare a direct delivery with the forwarded path before changing sender policy. Even when DKIM preserves DMARC, an unresolved direct-route SPF error is not a clean acceptance result. SPF results, trusted authentication results.
Troubleshooting and frequently asked questions
The CNAME works, but DKIM is missing. What should I check?
Confirm that Litera applied the domain to the actual sending account and completed signing activation. Then compare the observed selector and signing domain with the issued record. A public alias or key cannot activate a different account's signing process.
SPF and DKIM both pass. Why can DMARC still fail?
The passes may belong to unrelated service domains. Compare smtp.mailfrom and every passing DKIM d= with the visible From domain. Also check strict alignment and whether sender personalization changed From after configuration.
Should I add include:emailcc.com everywhere?
No. Apply the supported corporate-domain authorization where required, preserve one SPF policy, and inspect the actual envelope identity. Do not add TXT SPF beside the dedicated subdomain CNAME or copy the include to unrelated domains.
Can I use the same hostname for another marketing platform?
Do not share the Concep CNAME owner with another platform's records. Litera asks for an unused dedicated subdomain. Use a distinct hostname or an explicitly coordinated migration rather than deleting an older platform's active dependencies.
Does p=none mean relaxed alignment?
No. p sets the requested treatment of DMARC-failing mail. aspf and adkim set alignment. A record can use p=none with strict alignment, or enforcement with relaxed alignment. A DNS policy lookup also cannot prove that an actual message aligns.
Does authentication guarantee inbox delivery?
No. Authentication establishes identities and policy outcomes. Receiving systems also consider reputation, content, complaints and local policy. A delivery or open-rate metric is not a substitute for message authentication evidence.
Documentation review and testing boundary
No customer account was configured, DNS changed, support request sent or message-delivery test performed. Confirm the current account-specific values and signing activation with Litera before implementation.