Do not start with a generic ClickSend SPF record or DKIM selector. ClickSend’s August 6, 2026 notice says its Transactional and Marketing Email products are moving to end of life and recommends Mailjet. Email-to-SMS is explicitly unaffected. Its July 13, 2026 troubleshooting page also says Transactional Email is no longer offered to new customers. First establish which service sends your messages and what migration arrangements apply to your account. ClickSend migration notice, transactional email status
This is a current applicability and authentication-handoff guide, not a new ClickSend DNS setup recipe or a Mailjet migration tutorial. Do not infer that every existing sender has already stopped, or that continued account access guarantees continued email sending.
On this page: Identify the service · Check the lifecycle facts · Prepare the authentication handoff · Protect existing DNS · Validate the actual replacement route · Diagnose without guessing · Frequently asked questions · Sources and maintenance
Identify the service
A ClickSend account can be involved in different message paths. For this task, distinguish:
- Transactional or marketing email delivered to an email mailbox: this is the scope of the email lifecycle notice.
- Email-to-SMS: an email is an input to an SMS workflow. The notice explicitly excludes this service from the email migration. Do not apply an outbound email-platform change merely because its name contains “email.”
- A replacement email provider: after migration, its own account, transport and domain-authentication records govern the new email route. An old ClickSend dashboard entry does not establish the current sender.
Have the application owner identify the actual integration, intended From address and recipient channel. ClickSend’s notice suggests locating transactional integrations by searching the codebase for its email-send API endpoint or the SDK’s TransactionalEmailApi reference. Treat that as an inventory clue, not permission to edit code, rotate credentials or call the endpoint. Check the deployed configuration too: a dormant reference is not proof that a stream is still active. Official integration-identification guidance
Build a small inventory of active streams: password resets, receipts, alerts, newsletters and any separate email-to-SMS workflow. Assign an owner to each. Record whether the stream is still on ClickSend, already migrated, paused or unknown. Do not test a password-reset workflow against a real customer merely to identify its transport.
Check the lifecycle facts
The migration notice preserves important distinctions: accounts are not automatically deleted, credits remain usable for other products, and SMS/MMS access is unaffected. It says sent-email history remains available for four months after the email was sent. That is a retention window, not an email shutdown timetable. Preserve the evidence you legitimately need before it expires, through your organization’s approved retention process. Account, history and other-product FAQs
For an existing email sender, obtain account-specific answers before scheduling a cutover:
- What is the supported last sending date for this account and each email product?
- Which currently deployed integrations still use ClickSend, and who owns their queues or retries?
- Which provider and account will replace each stream, and which DNS names will it request?
- What happens to delivery events, suppression handling and records needed for audit or troubleshooting?
- What is the approved recovery route if the replacement fails? A legacy service approaching retirement must not be assumed available for rollback.
These are preparation questions, not claims that the public notice answers every one. Keep an unresolved date marked unresolved rather than borrowing a date from an unrelated ClickSend product announcement.
There is also a documentation inconsistency worth catching before onboarding: the notice describes Mailjet but includes Mailgun signup and log links. Do not treat those links as interchangeable services or enter credentials in the wrong product. Use independently confirmed instructions for the replacement your organization actually selects. The notice recommends Mailjet; it does not make an unreviewed account creation, purchase or data transfer part of DNS troubleshooting. Migration source containing the mixed-product links
Prepare the authentication handoff
If an existing ClickSend stream needs investigation, ask its administrator or ClickSend support for the current account-specific authentication arrangement. A useful response identifies the supported product, From domain, SMTP envelope domain, DKIM signing domain and selector, exact public DNS records, and whether a provider-side activation step remains outstanding. No universal current ClickSend include, selector or customer-domain activation sequence is established by the lifecycle documents cited here.
Do not fill that gap with another customer’s public DNS, an old blog’s record, or a value associated with Mailjet. A provider relationship or common corporate owner does not make account-specific DNS records portable.
For the replacement, prepare a separate change record containing:
- The selected provider and account, the application or campaign route, and approved From address.
- The complete newly issued DNS packet, including record type, full owner, target/value and purpose.
- Which records concern DKIM, envelope/bounce handling, tracking or domain ownership. These functions are not interchangeable.
- Existing consumers of each requested hostname, the authoritative DNS host and any delegated child zone.
- Provider verification and activation requirements, a controlled receiver test, and an approved recovery decision.
Mailbox-address verification demonstrates control of an address. It is not, by itself, proof that the provider signs with your domain or that the SMTP envelope aligns with it. DNS publication also does not prove that the application has switched to the new transport. Keep ownership verification, authentication configuration and application cutover as separate gates.
Protect existing DNS
A lifecycle announcement is not an instruction to delete DNS records. Preserve current records until the responsible owners establish that no active sender, queued message, retry or other dependency still needs them. A shared SPF policy may authorize services unrelated to ClickSend; a DKIM key may still be needed to verify delayed mail. Do not erase an entire policy or selector set just because one stream is moving.
Before a separately approved change, save the relevant DNS baseline and identify who can restore it. Preserve inbound MX, website records, NS delegations, other active selectors and the effective direct or inherited DMARC policy. An occupied CNAME owner is a dependency conflict to resolve, not a reason to overwrite another service.
SPF evaluates the SMTP MAIL FROM identity, not simply the visible From address. For a null reverse path, the HELO identity is used as specified by SPF. An SPF include cannot turn an unrelated provider envelope domain into your branded domain. Diagnose the actual envelope rather than adding authorization to the apex by habit. SPF identity selection
If the replacement’s verified instructions require an SPF edit, its provider-specific guide must establish the owner and mechanism. Keep one SPF policy at that owner, preserve other authorized senders, and review the complete evaluated DNS-lookup chain. The ten-term limit includes nested evaluated mechanisms and modifiers that trigger lookups. A short-looking record can still exceed it. Do not publish a second full SPF policy or flatten a provider include into a stale IP list. Preserve existing redirect= semantics: an all mechanism causes redirect to be ignored. SPF processing limits, redirect semantics
Do not weaken DMARC to make a migration appear successful. Retain the policy’s reporting destinations, alignment choices and enforcement while resolving the affected sender. This guide supplies no new policy record and no instruction to override an inherited policy. DMARC alignment relates authenticated domains to the visible From domain; changing Reply-To does not repair it. Current DMARC specification
Validate the actual replacement route
Complete the selected provider’s domain verification and signing activation first. Then, after authorization, send harmless content through the actual application or campaign stream to a controlled recipient. A provider-console test is useful but cannot establish that the application stopped using its old transport. Test materially different streams separately.
Retain a bounded acceptance record:
- Application, environment, provider account, message type and configuration revision.
- Intended and received From address, actual SMTP envelope domain, and every DKIM
d=signing domain ands=selector. - SPF result, each DKIM result, applicable alignment mode and the receiver’s DMARC verdict.
- Provider verification state, receiver, timestamp and the approved next action.
Use authentication results established by the receiving service’s trusted boundary. Confirm provenance with receiver-controlled logs, documented header handling or its mail administrator. A familiar authserv-id, a first-position header or an upstream result copied into the message is not sufficient. If provenance is unclear, obtain the receiver’s own verdict before accepting the test. Authentication-Results security considerations
For a replacement commissioned to send branded mail, require the intended replacement provider’s DKIM signature to pass and align with the intended From domain, plus a trusted dmarc=pass, alongside the correct provider/account and DNS state. Another aligned signature alone does not establish that the replacement’s signing configuration works. This is an acceptance requirement for the intended signing setup; DMARC itself can pass through either aligned SPF or aligned DKIM. Investigate unexpected SPF errors even when DKIM supplies the DMARC pass. Raw DKIM versus aligned results
Under relaxed alignment, the authenticated domain and visible From domain must share the same Organizational Domain. Under strict alignment, they must match exactly: compare DKIM’s d= for adkim=s and the SPF-authenticated MAIL FROM domain for aspf=s. A child envelope domain is not automatically a strict match for its parent From domain. Retain the effective policy’s modes rather than assuming relaxed alignment. DMARC alignment rules
Do not accept a provider-rewritten From address as proof that your intended brand domain authenticated. Record the actual result and resolve the supported sender configuration. A successful receipt also does not guarantee inbox placement, consent compliance or future delivery.
Diagnose without guessing
A new account has no Transactional Email controls: ClickSend states that the service is not offered to new customers. Adding DNS records cannot create product access. Confirm the supported replacement instead. Current product availability
An old integration stops sending: establish its lifecycle status and application/provider errors first. Do not assume every failure is DNS. If retirement or access is the cause, obtain the account’s migration instructions rather than publishing guessed keys.
The dashboard says Delivered: ClickSend defines this as delivery to the recipient’s mail server. It is not evidence of inbox placement or aligned DKIM. Obtain receiver-side authentication evidence. Processed means queued, while Deferred indicates temporary rejection. Use the precise status and event context in the investigation. Status definitions
The replacement verifies DNS but messages still show the old sender: compare actual deployed transport, account and stream routing. Do not delete old records as a method of forcing the application to change providers.
SPF or DKIM fails after cutover: compare received identities with the newly issued account packet. Separate SPF authorization failure, temporary DNS failure and permanent configuration errors. For DKIM, check the actual selector/signing-domain pair and whether downstream processing changed signed content. Do not publish private keys or disable receiver filtering as a workaround.
The cutover fails operationally: pause the affected stream where safe, preserve the failed sample privately and escalate to the application and domain owners. Restore only an approved, still-supported route. Do not retry business-triggered messages indiscriminately, which can create duplicate receipts or alerts.
Sources and maintenance
The full migration body was checked, including its account/history FAQs and mixed Mailjet/Mailgun links. Recheck product availability and account-specific timing before planning a change. No customer account, live DNS, codebase, credentials or delivered message was accessed or tested, and no migration or publication was performed.