Choose the sending identity before the configuration method
An eSputnik authentication project starts with the address readers will see. A main-domain newsletter, a promotional subdomain and a technical subdomain can belong to the same business while serving different purposes. Confusing those purposes can produce an apparently complete DNS worksheet that authorizes the wrong sending route. Start the review with a named campaign, its intended From address and the people responsible for replies and delivery failures.
This guide covers the email-domain and sender workflows in the current accessible eSputnik documentation. It does not establish what a particular account supports or how its messages are signed today. Treat every generated record, account status and message result as evidence still to obtain. A successful planning review is permission to prepare a bounded change, not evidence that the change has happened.
Distinguish Full, Full+ and Subdomain
The official domain configuration guide offers Full, Full+ and Subdomain methods through Settings, Domain verification and New domain. Full includes bounce-address forwarding. Full+ uses an unused technical subdomain. Subdomain supports a dedicated sending subdomain. The selected method determines the account-generated record set; copy its names, types and data rather than assembling values from unrelated examples.
The same guide distinguishes the visible sending domain from the technical subdomain. Verifying a parent does not automatically verify a From subdomain. Each sending domain needs its own entry, and cross-account use of the same domain requires matching configuration, including the technical subdomain. These are product requirements, separate from DMARC's protocol definition of alignment.
Before selecting a method, write down which name serves each purpose and whether another system already depends on it. Do not approve a change based solely on the label “marketing domain.” That label could mean the visible From domain, a tracking host or a technical mail-processing name, each with different consequences.
Protect incoming mail while preparing DNS
eSputnik's troubleshooting guide cautions against replacing normal mailbox-provider MX records with the platform's technical configuration. It also identifies wrong record types, duplicate domain suffixes and records placed in the wrong zone as verification problems. Compare the intended complete DNS owner with the editor's entry convention before proposing publication.
Make the mail-routing review explicit. A technical subdomain can be appropriate for platform processing while the main domain must continue receiving staff and customer mail elsewhere. Preserve the existing configuration and identify the business flow affected by every proposed difference. A bounce-forwarding arrangement also needs an approved recipient and data-sharing scope; this manuscript supplies no destination or authority to create one.
For a failed verification, save the account's requested values and the observed public answer as separate evidence. Determine whether the difference is an owner-name error, a missing value or an incomplete observation before changing anything again. Waiting is useful only when the published change is known to be correct; it cannot repair a record submitted to the wrong zone.
Confirm the sender used by the message
The sender guide describes adding an existing corporate address through Settings, Senders, Email and confirming the email sent to it. This does not create the mailbox. The selected sender belongs to each message, so checking the account's list alone is insufficient preparation for a campaign. Inspect the intended message configuration as well.
Dynamic sender use deserves a separate review because the provider requires the substituted addresses to have been added and confirmed. A successful test of one sender cannot establish readiness for every address a workflow may select. Record the approved sender population and assign someone to maintain it when personnel, domains or workflows change.
Assess signing across the intended sending conditions
The authentication and reputation FAQ describes a warm-up limit on messages signed with the customer's DKIM domain. Other messages may use a platform signing domain, with behavior depending on DMARC policy. Therefore a verified-domain badge or one signed sample should not be extrapolated to every message in a larger campaign. Obtain the current account limit and review the intended volume before release.
Keep the protocol conclusions precise. RFC 6376 section 3.5 defines signature fields including the signing domain and selector. A valid signature covers the signed material under its specified rules; it does not certify every displayed field or the sender's business trustworthiness. RFC 7208 section 2.4 evaluates SMTP identities, not the visible From address by itself.
RFC 9989 section 4.4 ties authentication to the Author Domain through alignment. One qualifying aligned passing mechanism can satisfy DMARC. A platform-domain signature alone does not establish customer-domain alignment. Record SPF and each DKIM result first, then determine alignment rather than treating several green indicators as interchangeable.
Define evidence before approving a send
The proposed acceptance record should identify the account, method, exact sender, workflow and relevant sending conditions. After separately authorized configuration and testing, it should link authoritative DNS observations to a controlled message received through the actual eSputnik route. Capture the visible From domain, envelope identity, every DKIM domain and selector, and the trusted receiver's results. Mark unavailable observations plainly.
Use harmless test content and an approved recipient. Restrict access to raw headers and message samples, and retain only what the reviewer needs. Include a mailbox-routing check in the acceptance plan so authentication work cannot silently break replies. Neither that check nor a campaign test was performed for this manuscript.
Fictional review and the remaining gate
In a fictional retailer's plan, Full+ is proposed for the main From domain, but a later promotional message uses a different From subdomain without its own verification entry. The reviewer catches the mismatch and holds the plan. No record was changed and no message was sent; the example demonstrates a planning decision, not an observed provider failure.
The exact requirement remains open: Current eSputnik first-party setup evidence and a received-message identity table from the exact product and route. The commissioning gate is: Confirm current product identity and provider-owned documentation; test a real message or published records. State unsupported custom-domain features honestly. Documentary research supports this bounded draft; tenant applicability, original testing, SME review, live visual review, owner release and publication approval remain outstanding.