Source currency: the retained Adestra Authenticated Domains page was last modified 16 April 2019; the Delegated Domains page was last modified 6 April 2020. These publication dates are distinct from the source-capture date. Confirm current account applicability with Adestra before acting.
Choose the domain model before editing records
Adestra’s official current-path documentation describes two distinct domain models in the MessageFocus interface: authenticated domains and delegated domains. They should not be combined into one generic checklist. An authenticated domain retains a different configuration relationship from a subdomain delegated to the service through CNAME or NS records. First identify which model the account uses and why the organization selected it.
Record the product, account, campaign route, intended From address and business owner. A vendor name alone does not establish the exact envelope or signing identity of a received message. This article describes the retained product documentation and a proposed verification process; it does not claim access to a live Adestra account or prove that every available account uses the same settings. Adestra Authenticated Domains; Adestra Delegated Domains
Review authenticated-domain SPF without replacing other senders
The authenticated-domain guide instructs organizations with an existing SPF record to include msgfocus.com in that policy. It also warns that a new policy must account for other legitimate sources. Treat the documented mechanism as product-specific evidence, not permission to replace an organization’s complete policy with a sample. Preserve the original record, ownership and all intended routes before proposing an edit.
The source uses legacy SPF/Sender-ID vocabulary. The manuscript’s interpretation uses current SPF concepts and does not turn that wording into a recommendation to deploy a separate historical Sender-ID policy. SPF evaluates its specified identity, while DMARC additionally depends on alignment. An application status saying the SPF record looks acceptable does not independently establish aligned authentication on the final message.
The documented workflow adds the configured domain through the Domains interface in the Admin area and exposes configuration status. Capture the actual account-generated or validated state during a later authorized review. Do not claim that a status was observed here. Adestra Authenticated Domains; RFC 7208, section 2.4 and 3.2
Treat custom DKIM as the documented assisted feature
For authenticated domains, the retained guide labels custom DKIM an On Demand feature and directs customers to their account manager or support for setup. It states that each authenticated domain used for signing needs its DNS configured. That does not justify inventing a universal selector, key or self-service activation sequence.
Prepare the exact domains and route inventory before a support request, but do not send the request without authorization. Use the public values supplied for the actual account and maintain a clear distinction between public DNS material and private signing keys. Never upload or disclose a private key merely because a generic tutorial suggests generating one elsewhere.
After setup, the guide describes domain-overview indications of configuration problems. Those indications are useful account evidence but do not replace received-message verification. DKIM is a signature mechanism, not message encryption; descriptions suggesting that recipients decrypt the message with the public key should not be used to explain its security properties. Adestra Authenticated Domains; RFC 6376, section 1 and 3.5
Review the delegated route as a control-boundary change
The delegated-domain guide requires ownership of the chosen name and checking that it is not already used for another purpose. It recommends a subdomain so the parent domain can continue serving other functions. It documents CNAME and NS delegation and advises coordination with the account manager. These are changes to DNS control and dependencies, not merely cosmetic branding choices.
For the delegated model, the source says the service supplies the relevant MX/TXT/SPF records and warns that adding extra records can cause problems. Do not apply the authenticated-domain SPF instructions blindly to the delegated name. Inventory existing records and understand what the chosen delegation method permits before seeking approval.
The guide says campaigns default to signing with msgfocus.com when custom DKIM is not configured, and describes public-key viewing and activation controls for custom configuration. A default signature is not automatically aligned with an organization’s visible From domain. Retain that identity distinction when planning verification. Adestra Delegated Domains
Acceptance worksheet for the exact campaign route
Use a worksheet with domain model, account, route owner, From domain, intended envelope identity, intended signing domain, selector, relevant DNS owners, current state and proposed state. For delegated domains, include the existing services that could be affected and the supported recovery route. For authenticated domains, include the confirmed support-assisted DKIM configuration and the complete SPF policy review.
The message-evidence section should record an authorized received sample’s From domain, Return-Path or applicable envelope identity, DKIM d= and s= values, trusted receiver authentication results and the sending workflow. Distinguish raw SPF and DKIM success from DMARC alignment. Keep unrelated recipient data and message content out of the retained sample where possible.
Acceptance requires evidence that the intended production route uses the expected identities, not only that the DNS values were entered. A preview or another campaign path may not represent the route being approved. Record unknowns and do not infer account-wide success from one unexplained message.
Fictional diagnosis: familiar signing domain, wrong conclusion
Imagine a fictional organization that adds an authenticated domain and sees an acceptable SPF status. A later hypothetical message still carries a default service signing domain rather than the expected custom domain. No actual message or account was inspected for this example. The correct diagnosis is not that all authentication is complete merely because a DKIM signature exists.
The reviewer would confirm whether custom DKIM was requested and configured for that specific domain, then inspect alignment and the actual envelope identity. If the organization instead uses a delegated subdomain, the reviewer would follow that model’s DNS and account workflow rather than adding records from the authenticated-domain checklist.
A proposed next step is an authorized, narrowly scoped account/support review and received-message comparison. It is not to invent a selector or replace the organization’s SPF record with a third-party example. The fictional case demonstrates why model selection and message evidence must remain linked.
Operational evidence remains open
The catalogue requires current first-party setup evidence and a received-message identity table from the exact product and route. The retained guides support the documentary workflow, but no account applicability, DNS answer or received-message table has been verified. No support contact, record edit, domain delegation or message send occurred.
All six release gates remain open. A qualified reviewer should confirm that the current account follows the described route, that any assisted configuration is complete and that the final message evidence supports alignment. The draft must not be presented as a successful Adestra implementation until those artifacts exist.