JustClick documents a support-assisted custom DKIM workflow for its Guru plan: support prepares a unique public DNS record, you publish and check that record, and support then enables signing and confirms completion. Publishing the record alone does not turn signing on. Use the approved sender address on your own domain when testing the result. Official JustClick DKIM instructions.
This guide covers native JustClick mailing with an existing, approved SPF sending route, adding branded DKIM without replacing that route. It does not configure a new bounce mailbox, an external SMTP connection, or a new custom SPF service. It also does not authorize a paid upgrade. If the prerequisite route or your current entitlement is unclear, resolve it with your administrator and JustClick before changing DNS.
The currently accessible official article includes illustrations from 2016–2017; they explain the process but do not prove that your current account uses identical screens. Confirm the current account-specific requirements with support. No account access, DNS changes or message tests were performed for this guide.
What you need before starting
Confirm that you are configuring the intended JustClick account, native mailing route and authorized sender address. The official instructions require the sender email to be on a domain you control and identify Guru as the plan with custom DKIM. Other plans may use the service’s shared signature. A passing shared signature does not establish alignment with your own visible From domain.
Use an existing authorized mailbox for that sender. Do not create a new mailbox, move staff email or change MX records merely to complete DKIM. Make sure you have permission to edit the relevant DNS zone and to request the provider’s account-side configuration. Keep a record of the existing sender, SPF policy, DKIM selectors and effective DMARC policy before the change.
Ask support to confirm that the documented custom-domain procedure applies to your current account. Historical screenshots show a default selector, but the full owner and public value supplied for your account govern the change. Do not assume that every customer receives the same selector or key.
The official article contains general claims about punctuation in sender names and delivery improvements. Neither is a reason to change a working address or promise better inbox placement: DKIM verifies a signature, not a sender’s trustworthiness or the legality of a mailing.
SPF: preserve the approved sending path
An SPF record authorizes the actual SMTP MAIL FROM domain used during delivery, not automatically the address a recipient sees in From. Record the envelope domain used by your existing JustClick route and retain its approved configuration. Do not add a guessed JustClick include at the root domain simply because you are enabling DKIM.
The separate JustClick SPF instructions describe a different, provider-assisted bounce-processing arrangement. They are not a universal record that can be copied into every customer domain. This guide deliberately does not reproduce that onboarding process or its credential-sharing instructions. If you need a new SPF arrangement, obtain current secure onboarding requirements through an approved channel and have the owner assess the access and routing consequences first.
For an existing policy, maintain one v=spf1 TXT record at each applicable owner. Preserve all legitimate senders and policy qualifiers. SPF does not automatically inherit from a parent to a child domain. Its processing budget is ten evaluated DNS-dependent terms, including nested mechanisms, not ten top-level includes. An all mechanism makes redirect ineffective; adding a mechanism after all will not authorize it. Do not create a second SPF policy or remove unrelated senders to satisfy a checker. SPF evaluation rules.
If the existing route cannot be verified, stop the rollout. Branded DKIM is not a justification for ignoring a known SPF error or inventing an envelope domain.
Request the account-specific DKIM record
Use the support route in your JustClick account. The official DKIM procedure asks for the account login identifier, intended sender email and domain. A login identifier is not a password. Share only the information needed for this authorized request; do not send mailbox passwords, API keys or private signing keys.
Make the request specific: ask support to provision custom DKIM for the named account and approved native sender, confirm eligibility, and provide the complete DNS record type, full owner and public value. Also ask which sender addresses or domains the activation will cover and how they will confirm that signing is enabled. Do not assume that provisioning one identity automatically covers every future domain.
JustClick’s instructions say its team prepares the configuration and returns a unique public TXT record for the customer to publish. The sample public key printed in the article is explicitly an example. Never use that value, a key from another customer’s screenshot or a private key generated by an unrelated tool. Record issuance and activation procedure.
Retain the issued record and support reference. If the response is incomplete or conflicts with your existing DNS, ask for clarification rather than filling in a selector or changing the record type yourself. A promised completion window is not activation evidence; wait for the actual confirmation.
Publish the TXT record in the correct DNS zone
Find the authoritative DNS host for the issued full owner. It may differ from the registrar, website host or mailbox provider. Check for delegated child zones and a separately delegated _domainkey namespace before choosing where to publish.
For a hypothetical issued owner selector._domainkey.mail.example.com, an editor managing the parent zone example.com might require selector._domainkey.mail. An editor managing the separate mail.example.com zone might require selector._domainkey. These are mapping examples, not JustClick record values. Use your DNS editor’s actual convention so that it does not append the domain twice. Preserve any existing delegation and publish through its responsible operator. DNS zones and delegation.
Select TXT and paste the complete public tagged value supplied by support. Do not paste a BIND zone-file line, the owner, record type or presentation quotes into a value-only field. The official example shows a value beginning with v=DKIM1; retain the full issued content, including its public-key data. If an editor splits a long value into multiple quoted strings within one TXT record, the resulting logical value must remain intact. Do not split it into unrelated TXT records or truncate it. DNS TXT representation.
Inspect the owner before saving. An existing selector may still sign queued mail or belong to another service. Do not overwrite it without a coordinated replacement plan. If a CNAME already occupies that owner, do not add the TXT record alongside it: a CNAME cannot coexist with ordinary TXT, A, AAAA, MX or another CNAME at the same owner. Ask the DNS administrator and JustClick for a supported resolution rather than deleting a dependency.
This documented route uses a public TXT record, not a website proxy or a guessed CNAME target. HTTP proxy and CNAME-flattening switches do not repair a malformed DKIM TXT value. If support now issues a different record type, confirm the revised procedure before applying it; do not silently adapt an old screenshot. No nameserver takeover, MX change, DNSSEC change or inbound forwarding is required by the documented DKIM publication step.
Check DNS, then obtain separate signing activation
Query the complete owner and compare the authoritative TXT answer with the current support-issued value. Confirm the correct zone, selector and full public content. The official article illustrates a TXT lookup; the fact that a tool returns any answer does not prove it returned the right key.
If the answer is missing or different, inspect the owner suffix, record type, delegation and saved value. Allow for the relevant cache lifetime after a legitimate update, but do not promise a fixed propagation deadline. Preserve the working record while investigating; repeated deletion and recreation is not a verification method.
Once publication is correct, reply to the same authorized support request that the record is ready. JustClick explicitly says it then enables DKIM and writes back to confirm. Until that confirmation arrives, classify the setup as published but awaiting activation, not complete. Do not invent an activation toggle that the source does not document.
Confirm the approved native sender remains selected for the mailing you will test. DNS verification, support-side signing activation and the actual message’s signature are three separate checkpoints.
Keep DMARC policy and reporting intact
Inspect the intended visible From domain’s direct and applicable inherited DMARC policy. A missing TXT response at one child name does not prove that no policy applies. Keep existing enforcement, alignment settings and approved report recipients. Do not duplicate a policy or weaken quarantine or reject to make a test look successful.
Only when no direct or applicable inherited policy exists, the owner approves and monitored introduction is appropriate, an initial TXT value may be v=DMARC1; p=none. For From mail.example.com, the full policy owner is _dmarc.mail.example.com; in the parent zone the relative name is _dmarc.mail, or _dmarc in a separately delegated mail.example.com zone. This example is not a JustClick-issued record and does not request reports. Do not copy the vendor article’s malformed alignment values or impose its enforcement example without assessing all legitimate senders. Do not use obsolete pct rollout advice. Current DMARC specification.
For aggregate reporting to a different Organizational Domain from the domain where the DMARC policy was found, the report-generating receiver must check DNS authorization. A destination in the same Organizational Domain is excepted. That technical check does not replace the owner’s privacy and data-sharing approval. Preserve approved recipients and do not copy someone else’s reporting address. Report authorization rules.
Verify a controlled native mailing
After support confirms activation, use a harmless authorized message from the configured JustClick sender to a controlled valid recipient on the actual intended native path. Do not enable an automation or send to the full subscriber list merely to test authentication. A preview or message sent from an unrelated mailbox cannot establish the native route’s signing behavior.
Obtain the recipient’s original message and results generated inside its receiving service’s known processing boundary. Check the service’s documented handling of externally supplied Authentication-Results or obtain an administrator trace. A familiar authserv-id, header position or copied dkim=pass line alone is not trustworthy; ignore attacker-supplied result fields. Authentication-Results trust boundary.
Record the actual From, SMTP MAIL FROM, intended DKIM signing domain d= and selector s=, and trusted SPF, DKIM and DMARC results. Accept the newly configured route only when the intended JustClick signature passes and aligns with your intended brand From, with trusted dmarc=pass and support activation confirmed. A provider-rewritten From or another passing signature does not satisfy that branded-DKIM goal.
DMARC needs either aligned SPF or aligned DKIM, not necessarily both. Relaxed alignment compares Organizational Domains; strict aspf or adkim requires exact domain equality. A child envelope domain can align under relaxed SPF alignment but not strict alignment. A DMARC pass through SPF does not prove the new DKIM signature works. See raw DKIM results versus aligned DKIM policy results.
Investigate SPF fail, temporary errors and permanent policy or lookup-budget errors separately even if DKIM makes DMARC pass. Authentication success does not guarantee inbox placement, delivery or permission to contact a recipient.
Troubleshooting without damaging working mail
TXT exists but no intended signature: check the exact sender and route, then confirm that support completed the separate activation. Do not assume a DNS lookup enabled signing.
Key or selector differs: compare the message’s s= and d= with the current issued record. Ask support which active key belongs to that route. Do not replace another sender’s selector or remove an old key before queued messages and dependencies are accounted for.
DKIM passes but DMARC fails: compare the intended d= with the actual visible From under the effective alignment mode. Passing with the shared service domain is not proof of branded alignment.
DKIM fails after downstream processing: have the responsible administrators investigate signature selection and message modification. Do not disable required security or legal controls to preserve a signature.
For unresolved issues, provide necessary redacted account identifiers, domain, selector, DNS answer, support activation reference and trusted diagnostic results. Keep credentials, private keys, recipient lists and message contents out of routine support copies. Coordinate any rollback with the owner rather than silently removing authentication from an active mailing route.