Separate Concep SEND domain choice from signing activation
Concep's official domain selection guide, updated September 18, 2020, distinguishes corporate sending domains from subdomains. Its Signing with DKIM guide, updated July 2, 2020, describes a support-assisted key and activation workflow. These dated instructions provide a concrete starting point, but current product applicability remains open. This article does not claim that every present-day Concep SEND account uses the same infrastructure or controls.
The first decision is which domain the campaign will use in its sender address and whether a separate branded name is needed for hosted links. The domain guide says both corporate domains and subdomains can be used for sending, while only subdomains can host campaign links in its documented arrangement. Without that subdomain choice, links are hosted on emailcc.com. Do not treat a successful branded link as proof that the sender domain is authenticated.
Prepare an inventory with the intended sending domain, link domain, account and responsible DNS administrator. Identify existing uses of the proposed name before committing to it. A domain shared with employee mail or another marketing system requires coordination; it should not be reconfigured simply because a campaign owner can edit a From address. No account or DNS settings were accessed for this manuscript.
Review the historical subdomain and corporate-domain instructions
For the subdomain arrangement, the 2020 guide specifies a CNAME pointing to emailcc.com. For a corporate sending domain, it specifies SPF authorization using include:emailcc.com. Preserve the distinction rather than placing the subdomain alias at the organization's zone apex or assuming that the same record serves both purposes. Confirm the current provider-issued configuration before making a production change. Concep domain selection guide
The guide's wording about appending a complete SPF example should not be read literally as an instruction to concatenate two v=spf1 policies. Under RFC 7208, section 3.2, a domain must not publish multiple records that cause more than one SPF policy to be selected. Merge the approved authorization into the existing policy and preserve other legitimate senders. Do not insert a second version marker or silently replace the terminal qualifier.
A CNAME owner also needs a conflict review. The proposed record is not permission to overwrite existing mail, website or verification dependencies. Record the complete owner and target, and compare them with the DNS editor's naming convention. An editor that appends the zone name can produce an unintended duplicate suffix if the input is copied without checking its interpretation.
Confirm the sending domain before requesting DKIM
The DKIM guide says a subdomain or corporate domain must already be set up with Concep before the DKIM request. Support then coordinates with IT to generate a key, which the customer's DNS team publishes as a TXT record. The article does not supply a reusable selector or public key for all customers. Use the actual supplied owner and value for the intended domain, and keep the request reference attached to that change. Concep Signing with DKIM
A sensible proposed handoff identifies the sending domain, account scope, DNS operator and expected completion evidence. It need not include campaign recipients, confidential content or credentials. Sending a support request is an external communication and requires an authorized operator; this guide neither creates a ticket nor implies one has been submitted. The domain's current eligibility for the documented process remains unresolved until confirmed.
Review existing data at the requested selector before publication. An older key might still serve active traffic, and a replacement may require coordination. The public DNS key is not a request for the provider's private signing key. Keep the distinction explicit so a support handoff does not become unnecessary credential sharing or an unreviewed change in signing responsibility.
Retain the provider-side activation step
The historical DKIM workflow does not end when the TXT record is saved. It says the customer informs support after publication; Concep verifies propagation and switches the relevant accounts to its dedicated DKIM mail server arrangement. It then describes a provider test message from an account and a check for dkim=pass. Treat this as the documented sequence, not evidence that any current account has completed those actions. Concep Signing with DKIM
Record provider completion confirmation separately from DNS publication. The distinction matters because a correctly published key cannot cause an unrelated sending system to sign with it. If the provider says the current workflow differs, update the implementation plan against that account-specific evidence rather than forcing the historical sequence onto a new product version. Do not invent an Enable Signing control that the cited workflow does not document.
The provider's test description establishes a useful DKIM checkpoint, but dkim=pass alone does not prove alignment with the campaign's visible author domain. RFC 6376, section 3.5 identifies the signature's d= signing domain and s= selector. Capture those values through an authorized evidence process and relate them to the approved configuration. A successful signature belonging to another service identity is a different result.
Check SPF and DMARC on the actual route
SPF evaluates the SMTP identity, not merely the address displayed by the campaign editor. RFC 7208, section 2.4 describes the MAIL FROM identity, while section 4.6.4 sets limits on evaluated DNS-dependent terms. Review the actual envelope domain and the complete policy, including nested dependencies. A visible include string is neither proof that a receiver uses that policy nor a complete evaluation-budget assessment.
RFC 9989, section 4.4 adds alignment between the author domain and a passing authenticated identity. Passing aligned SPF or passing aligned DKIM can satisfy that authentication condition. Do not claim that Concep's historical provider test closes every DMARC requirement or that all domains in a multi-brand account share the same result. Each intended identity needs its own evidence boundary.
The source's broad reassurance about non-spam delivery is not a guarantee. Authentication, SMTP acceptance, folder placement and engagement are different observations. A campaign with no recorded views has not thereby been proved unauthenticated or blocked. Use actual diagnostic evidence and avoid broad recipient allow-list requests as a substitute for identifying the fault. No such request or test was made here.
Fictional diagnosis: published key, unfinished provider transition
A fictional professional association, Alder Council, receives a DKIM value from support and asks its DNS team to publish it. The campaign owner marks the project complete as soon as the change ticket closes. A later readiness review finds no confirmation that the provider-side account transition or described test has happened. The team therefore records DNS publication as complete evidence within the fictional case but leaves sending readiness unresolved.
The proposed next step is to obtain authorized provider confirmation, then inspect harmless message evidence for the intended sender identity. It is not to replace the key repeatedly or assume that waiting alone will activate signing. This example is fictional: it does not represent a real ticket, DNS observation, account migration or received message.
Blank acceptance worksheet and release boundary
- Current account, product route and applicability of the dated guides: ______
- Sending domain versus link-hosting domain and existing dependencies: ______
- Approved SPF authorization merged into one coherent policy: ______
- Support request reference and domain setup prerequisite: ______
- Issued DKIM owner, public value and DNS publication evidence: ______
- Provider activation or transition confirmation: ______
- Authorized message d=, s=, envelope domain and trusted results: ______
- DMARC alignment assessment, remaining exceptions and owner decision: ______
The catalogue's original implementation evidence, human review, source applicability, production routes, visual accessibility and owner release remain open. The historical public workflow supports this documentary draft; it does not establish current tenant execution or authorize publishing, support outreach or DNS changes.