eSputnik SPF, DKIM and DMARC setup, step by step

To authenticate email in Yespo, add the intended sending domain under Settings → Domain verification, choose Full, Full+ or Subdomain, and publish the records the account supplies. Complete verification, select a sender on that verified domain and inspect delivered headers. Check the warm-up limit as well: domain verification does not mean every message immediately carries your branded DKIM signature. Domain authentication · Warm-up behavior

This guide covers Yespo's campaign sending workflow associated with the eSputnik name, including current esputnik.com authentication targets. It does not configure unrelated SMTP providers, website domains or short-link branding. No customer account, DNS change or test send was performed.

For employee mailbox authentication, consult the separate Microsoft 365 guide when that is your mail service; those tenant controls do not authenticate a Yespo campaign.

Start with the sending identity

Use a company-controlled domain and arrange access to DNS, the sender mailbox and any required forwarding rules. Public addresses such as Gmail cannot be authenticated on your behalf. A working corporate mailbox is separate from a campaign's authenticated sending identity. Yespo authentication FAQ

Write down the visible From domain, selected authentication method, technical subdomain, mailbox domain and Reply-To address before changing records. The technical domain processes delivery failures and need not be the visible sender. Use an unused name rather than repurposing a website or existing CNAME.

The documentation does not specify a separate authentication plan tier. Confirm access in your own account rather than assuming a paid upgrade is necessary. Dedicated IP service is an optional paid arrangement; it is not a prerequisite for authenticating the normal shared-IP route. IP and warm-up scope

Choose Full, Full+ or Subdomain

For Full, choose New domain → Complex server configuration → Full, enter the domain and start verification. For Full+, enter the domain and an unused technical subdomain. For Subdomain, choose Complex server configuration → Subdomain and enter the intended sending subdomain. Copy the resulting record types, names and data; return to Verify domain after publication. Method-specific workflow

The exact From domain must be verified: a verified root does not automatically verify a sending subdomain. Different accounts using the same domain must use identical authentication configuration, including the technical subdomain. Domain configuration boundaries

Before selecting a method, ask who receives real replies and delivery failures. Test reply handling separately from DKIM. Avoid a change that makes a campaign appear authenticated while silently redirecting corporate inbound mail.

Publish SPF, DKIM and the correct MX owner

Yespo's Cloudflare guide documents include:spf2.esputnik.com, DKIM target dkim.esputnik.com, and technical MX trap.esputnik.com. The Full example uses selector owner esputnik._domainkey and a TXT policy containing v=spf1 include:spf2.esputnik.com ~all; Full+ places SPF and MX on the technical subdomain, with MX priority 10. Retrieve the complete current set from your account rather than treating this summary as every record required for every method. Official DNS examples

If the DNS host automatically appends the domain, use the appropriate relative owner. Confirm that the resulting fully qualified name has the domain only once. Do not proxy or flatten authentication CNAMEs, and do not replace the managed alias with a temporary public-key snapshot. Never publish a private signing key.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

A CNAME cannot coexist with MX or TXT at the same owner. Select a different unused name or obtain a supported alternative; do not remove a working website alias just to make the form accept another record. Configuration conflicts

The mailbox domain must have valid MX records pointing to its actual mail service. The Yespo technical MX is not a replacement for those records. MX troubleshooting

Before publishing or activating technical MX, obtain the routing owner’s separate approval of the complete route: full owner, every numeric priority and target. Receiving the account-issued packet alone is not approval of its inbound consequences. Reconcile the whole set with the authorized mail plan, preserve corporate MX, and compare all approved tuples at authoritative and public recursive DNS. Stop on an unexpected owner, priority, target or dependency rather than accepting a partial match.

Full-method forwarding and reply handling

Full requires forwarding for all matching bounce+* addresses. Obtain the exact destination from the current setup instructions or Support; do not infer it from an obscured screenshot. With plus addressing, a bounce mailbox may handle these variants. If a catch-all is needed, coordinate narrowly scoped routing with the mail administrator so unrelated inbound messages are not discarded. The account checks forwarding during verification. Full configuration

The mail-routing owner must separately approve the exact forwarding recipient and narrowly scoped matching rule before activation. Compare the actual configured destination with that approved address, not an obscured example, and test authorized bounce variants and unaffected ordinary inbound mail. Stop if the proposed rule would redirect or discard unrelated messages; an issued address alone does not authorize sharing mail with that recipient.

For Full+ and Subdomain, establish a monitored reply address outside the technical mail-processing destination. Test a normal reply and an unsubscribe request. Successful DNS verification is not evidence that a human is reading either mailbox.

Resolve SPF errors without weakening the policy

SPF evaluates the SMTP MAIL FROM identity, not the visible From header. Query that actual owner. A clean root-domain SPF result says little about a message using a technical subdomain.

Keep exactly one v=spf1 record per owner, preserve legitimate existing authorizations and retain the established terminal policy. Do not paste a second complete policy or append an include after all, where it cannot be evaluated. Count nested DNS-triggering terms actually evaluated: include, a, mx, exists, ptr and redirect share the ten-term limit. Multiple SPF records, syntax problems and excess terms can produce permerror; temporary DNS failures require a different diagnosis. SPF standard

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Use an SPF evaluator on the complete expanded policy. Remove only authorizations confirmed obsolete. Do not manually flatten the provider include into current IP addresses, which can become stale. If a provider-controlled include fails, preserve the exact error and DNS evidence for Support rather than repairing its policy locally.

For Cloudflare-hosted DNS, use DNS-only authentication records and leave their CNAMEs unflattened. Proxying obscures the intended DNS target, and flattening can prevent third-party verification from seeing the expected alias. Cloudflare proxy status · CNAME flattening guidance

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Finish verification and account for warm-up

Return to Domain verification and resolve warnings before selecting the sender for a campaign. Allow up to 48 hours for DNS propagation. Campaigns are not sent until the domain is verified. Verification prerequisite and timing Inspect public DNS as well as the account result. Incorrect record types, a duplicated domain suffix, copied column labels and publication at a non-authoritative DNS host can all prevent verification. A transient resolver timeout can also justify retrying a check without changing correct DNS. Verification troubleshooting

After domain verification, open Settings → Senders → Email → New sender. Enter the sender name and existing corporate email address, click Add, then confirm through the email from Yespo Support. Wait for status Available and select that sender in each message. A new address on the same verified domain does not require another DNS setup. For dynamic senders, add and confirm every address the variable can produce before launch; contact Support to enable that feature. Reply-To must also use your authenticated corporate domain and a monitored receiving mailbox. A newly confirmed sender can take up to one hour to become available through the API because of caching; this is separate from DNS propagation. Sender setup and confirmation

Warm-up limits apply to branded-domain signing across campaign types, including trigger and transactional messages. Below the applicable limit, messages can carry your domain signature as well as Yespo's. Above it, provider-only signing can occur when policy permits. With quarantine or reject, the documented workflow stops further sends at the limit and resumes the next day. Inspect Settings → Domain verification → Daily sending limit; ask Support if the relevant status is unavailable. Do not lower DMARC to bypass that safeguard. Domain warm-up

A small test can therefore pass while a larger campaign behaves differently. Record the sending limit and expected signing behavior for the actual launch volume. The FAQ also explains that the provider can suspend branded signing when continuing DNS checks detect invalid settings. Monitor account warnings rather than treating verification as permanent. Authentication FAQ · Ongoing checks

Retain DMARC and prove aligned branded signing

DMARC passes with either aligned SPF or aligned DKIM. Under relaxed alignment, compare organizational domains; under strict alignment, compare exact domains. A Yespo-domain signature alone does not align with your own From domain. Technical-subdomain SPF may align under relaxed mode but fail strict mode. Inspect both mechanisms instead of assuming a DKIM pass is branded. DMARC standard

Look up the From domain's existing policy and applicable inherited policy before adding anything. Preserve enforcement and reporting destinations. Do not copy a vendor's first-policy example over an established configuration.

Only if no established or inherited policy applies, and a monitored rollout is approved, add one TXT record at _dmarc.YOUR-FROM-DOMAIN containing v=DMARC1; p=none. Replace the placeholder. To request aggregate reports, add rua=mailto:YOUR-APPROVED-REPORT-ADDRESS with a real authorized destination and any required external authorization. Without rua, this record requests no reports. Review all legitimate streams before enforcement. Do not use the obsolete pct tag to promise a percentage rollout. Policy · Aggregate reporting

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Monitoring is not disabled by p=none; reports depend on reporting configuration and receiver participation. Failure reports can expose message-level information, so ruf requires a separate privacy decision. Failure reporting

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Validate DNS and real message acceptance

Replace these illustrative names with the exact owners from Yespo and your actual From policy:

dig +short TXT technical.example.com
dig +short MX technical.example.com
dig +short CNAME esputnik._domainkey.example.com
dig +short TXT esputnik._domainkey.example.com
dig +short MX example.com
dig +short TXT _dmarc.example.com

Expect the generated alias/technical MX values, a single valid SPF policy at its intended owner and unchanged corporate MX. Follow a DKIM alias to its public-key answer. Compare authoritative and public-recursive answers if caches disagree; these queries do not themselves test signing.

After verification, send an authorized sample through the actual campaign or automation to an external mailbox. Capture the trusted receiver-added Authentication-Results (receiver trust boundaries), visible From, Return-Path, each DKIM d= and s=, message ID and timestamp. Require:

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

1. SPF passes for the observed envelope identity.
2. The branded DKIM signature passes and aligns with the intended visible From.
3. The receiver reports DMARC pass for that From domain.
4. Replies and failure handling reach the intended destinations.
5. Campaign volume remains consistent with the documented signing limit.

If a message is rejected before delivery, retain the complete SMTP response and provider event instead of claiming a receiver-header test passed. Acceptance does not guarantee inbox placement.

SPF must be investigated independently even when aligned DKIM makes DMARC pass. For an actual fail, compare the observed sending IP and MAIL FROM policy; for permerror, inspect syntax, duplicate policies and evaluated DNS terms; for temperror, check transient DNS availability and repeat the same-route test after recovery. Preserve the receiver result and timestamp rather than weakening DMARC to mask the error. SPF result definitions

Troubleshooting and FAQs

Why does the account report another configuration for this domain?

Check other accounts and the technical subdomain already assigned. Reuse the matching configuration or coordinate a planned reconfiguration with Support; do not delete an active entry as a casual repair. Configuration conflict

Why did DKIM change midway through a campaign?

Compare messages before and after the branded-signing limit. Also check DNS warning emails. Provider-only signing and broken branded-key DNS are different causes and require different remedies.

Why did adding MX break corporate mail?

The technical MX may have been published at the corporate owner. Restore the approved mailbox routing with the DNS administrator, then apply the method-specific records only at their intended owners.

Why does SPF pass but DMARC fail?

A passing envelope identity may not align with the visible From, particularly with strict alignment. Find a passing aligned branded DKIM signature rather than repeatedly adding SPF includes.

Are old eSputnik DNS names wrong now that I use Yespo?

Not automatically. Current Yespo documentation still supplies esputnik.com authentication targets. Use the current account values; do not rename DNS targets to match the interface branding.

Does a custom short-link domain authenticate email?

No. Link branding is separate from the sender's SPF, DKIM and DMARC. Short-link boundary

Review boundary

This is public-documentation guidance. Actual account values, forwarding destinations, verification, launch-volume signing and received-message results remain to be checked. No live implementation or delivery outcome is claimed.