Yandex SPF, DKIM and DMARC setup, step by step

For a custom domain in Yandex 360 for Business, configure one SPF policy and publish the domain's generated DKIM public key at mail._domainkey. Yandex documents v=spf1 redirect=_spf.yandex.net for its sole-sender setup and include:_spf.yandex.net inside a combined policy when other servers also send. Obtain the DKIM value from the organization's Domains page, not a tutorial's example key. Yandex SPF instructions and DKIM instructions

This guide covers custom-domain corporate mail through Yandex 360 for Business. Consumer @yandex addresses, a website that merely delivers notifications to a Yandex inbox, and separate sending products are different routes. No tenant, customer DNS or delivered-message test was performed.

Confirm the organization, domain and sending path

Use the organization's administrator account and confirm that the exact domain is connected and verified. The domain list is under General settings → Domains. Use the account-issued ownership evidence if verification is incomplete; that ownership token is separate from SPF and DKIM. Yandex domain verification

Before changing anything, inventory:

• The From addresses and domains employees actually use, including aliases or subdomains.
• Mail sent through Yandex versus invoices, newsletters or application notices sent by other services.
• The person controlling authoritative DNS and the nameservers currently delegated.
• Existing SPF, DKIM, MX, DMARC and reporting records, with a recoverable copy.
• Any outbound gateway, automatic forwarding or message modification on the route.

The English-language corporate documentation used here does not prescribe a region-specific SPF include or separate regional DKIM template. Use the current organization's generated key and supported route; do not manufacture a regional hostname from the Yandex brand or a user's location.

If newsletters use Mailchimp rather than Yandex mailboxes, follow the Mailchimp domain-authentication guide for that campaign route. Its generated records and message tests remain separate from the corporate-mail setup below.

Is DNS hosted by Yandex or somewhere else?

Yandex states that SPF and DKIM are configured automatically for a domain delegated to its nameservers. Its DNS-management workflow is General settings → Domains → Manage DNS records for the relevant domain. If DNS is hosted elsewhere, publish the records there. Automatic setup still needs public DNS and delivered-message checks. Yandex DNS setup

You do not need to transfer nameservers merely to add authentication records. Delegation affects the whole zone and can disrupt websites and other services if records are missing. Keep an existing working delegation unless a separate DNS migration is intended and authorized.

Choose the correct SPF policy

If Yandex is the only authorized sender

For an exclusively Yandex sending domain, the documented TXT value is:

v=spf1 redirect=_spf.yandex.net

Publish at the relevant domain owner, normally @ for the configured zone root. Yandex specifies a TTL of 21600 seconds when required. Do not overwrite a multi-sender policy with this record merely because the mailbox moved to Yandex. Official SPF value and TTL

If other services also send

Use one combined policy that retains the other verified authorizations and includes Yandex. A hypothetical domain using Microsoft 365 and Yandex during a controlled transition could have:

v=spf1 include:spf.protection.outlook.com include:_spf.yandex.net -all

This example is valid only for those authorized senders and a deliberately retained -all policy. Your invoice or marketing service may need a different mechanism, or may use its own envelope domain and require no change at this owner. Yandex's official mixed-sender example uses ip4 mechanisms plus its include; the general principle is to preserve every legitimate route in one reviewed policy.

Why redirect and include are not interchangeable

redirect hands evaluation to another SPF policy if no mechanism matches; it is not an SMTP routing instruction. An all mechanism always matches, so combining a terminal all with a redirect prevents the intended redirect evaluation. Do not “improve” the Yandex-only redirect record by appending ~all or -all. When converting to a combined include-based policy, review the full change and the intended terminal result. SPF redirect processing

Keep only one v=spf1 TXT record at an owner. Other verification TXT records may coexist. Evaluate all nested DNS-lookup-causing terms against the limit of ten, not just visible includes. Do not use +all, remove a legitimate sender to pass a checker, or silently weaken an established qualifier. SPF publication and lookup rules

Obtain and publish the domain's DKIM key

For a manually configured domain:

1. Sign in to the organization's admin account and open Domains.
2. Choose Add DKIM beside the correct, connected and verified domain.
3. In Configure DKIM signature, copy the complete public-key value.
4. At authoritative DNS, publish a TXT record at mail._domainkey relative to that sending domain.
5. Use 21600 seconds if the DNS editor requires a TTL.
6. After publication, return to Domains → Verify your domain → Check to refresh the configuration status.

Yandex's current manual guide describes that workflow, not an additional generic “Enable DKIM” switch. Its stated DNS-update window is up to 72 hours. Check the authoritative answer first rather than repeatedly regenerating a key or waiting for an incorrectly named record to repair itself. Current Yandex DKIM procedure

The public record worksheet should look like this, with the value copied from the account:

Type: TXT
Full owner: mail._domainkey.example.com
Value: COMPLETE_PUBLIC_DKIM_VALUE_FROM_YANDEX
TTL: 21600

example.com and the uppercase value are placeholders. Never publish the documentation's shortened p=... key or another organization's key. Publish the entire generated value, including any tags Yandex supplies. The mail selector identifies this configuration; the actual signing domain still needs to be verified in the delivered message.

If mail._domainkey already belongs to another active service, stop before overwriting it. Coordinate selector ownership or a supported migration. Do not invent an alternative Yandex selector unless the current service explicitly supports that choice.

Place records safely at apex and child domains

For a sending domain that has actually been connected in the account, the DNS owner is determined by that domain, not by the provider name:

These are naming examples, not proof that a particular account has added or authorized the child domain. In an editor requiring a full hostname, use the full owner and confirm the zone is not appended twice. At a delegation boundary, edit the child nameservers' zone, not an ineffective parent copy.

At an existing delegated _domainkey.staff.example.com authority, full owner mail._domainkey.staff.example.com maps to relative mail. Preserve NS delegation and other selectors, and publish only the complete public key generated for that connected Yandex domain. Relative names.

A CNAME cannot share its owner with an ordinary TXT record. Preserve unrelated selectors, verification tokens and working web records. A long key can be represented as multiple quoted strings within one TXT record, but not as separate independent TXT fragments. Never publish a private key. DNS aliases and DKIM DNS records

MX controls incoming delivery, not outbound SPF authorization. Yandex's mail setup lists mx.yandex.net for mailboxes hosted there, but an authentication repair is not permission to replace an organization's working MX route or remove a security gateway. Treat any inbound migration separately. Yandex email DNS roles

Verify DNS and account status

Replace uppercase placeholders in these read-only checks:

dig +short NS DNS_ZONE
dig @AUTHORITATIVE_NS TXT ENVELOPE_DOMAIN +noall +answer
dig +short TXT ENVELOPE_DOMAIN
dig @AUTHORITATIVE_NS TXT mail._domainkey.SIGNING_DOMAIN +noall +answer
dig +short TXT mail._domainkey.SIGNING_DOMAIN
dig +short TXT _dmarc.FROM_DOMAIN

Use the correct authoritative nameserver for each domain, especially if a child zone is delegated. For SPF, expect one policy consistent with the real sender inventory. For DKIM, expect the full generated public key at the exact mail._domainkey owner. Compare values rather than just the existence of a TXT answer.

If authoritative DNS is correct but a recursive resolver is old, check caching and remaining TTL. NXDOMAIN or an empty authoritative answer suggests a naming or publication problem. SERVFAIL requires DNS-resolution investigation, including possible DNSSEC problems. Do not keep making edits simply because one cached answer lags.

Refresh Verify your domain → Check after the public records are correct. A green status supports publication, but does not establish the route or identities of every sent message. Yandex's mail troubleshooting guide provides separate MX, SPF and DKIM checks; use the one matching the symptom.

Verify a real message and its alignment

During an authorized implementation test, send a fresh external message from the intended custom-domain mailbox to a separate recipient you can inspect. Repeat for each supported application or alias route. Do not use a Sent-folder copy as evidence of what the recipient authenticated.

Inspect the trusted receiving system's Authentication-Results, visible From, Return-Path, connecting IP and all DKIM d= and s= values. An arbitrary sender-inserted header is not trustworthy evidence. Authentication-Results trust boundary

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.

Acceptance requires:

• The intended branded DKIM signature passes and aligns. Confirm its d= matches the intended domain relationship and its selector corresponds to the configured key.
• SPF is checked separately. Record the receiver's evaluated smtp.mailfrom, result and connecting IP. Correct real direct-route failures rather than relying on DKIM to hide them.
• DMARC passes under the applicable policy. Confirm the aligned mechanism, not just a generic pass label.
• The sample used the intended route. A successful Yandex webmail message does not certify a website sending directly from its hosting server.

SPF evaluates the SMTP envelope MAIL FROM, not the display name, Reply-To or visible From; with an empty reverse-path it uses HELO. There is no universal customer-configurable custom Return-Path workflow established by the primary sources used here. Observe the actual identity instead of creating an assumed bounce CNAME.

DMARC needs either aligned SPF pass or aligned DKIM pass. Strict alignment requires exact domain equality; relaxed alignment permits the same organizational domain. From: employee@example.com and d=example.com align exactly. A passing signature for an unrelated provider domain does not. A generic DMARC pass through SPF alone is insufficient to accept this branded DKIM setup. DMARC alignment

For acceptance, match the intended active Yandex signature’s d= and s= to the connected domain and generated mail key. Require its passing alignment under the effective adkim setting with the unchanged intended visible From, together with trusted receiver dmarc=pass. Another aligned signer or an unexpected rewritten From does not complete this deployment.

Test forwarding separately from direct delivery. A forwarded copy may authenticate a different envelope or arrive after signed content changes. Do not add arbitrary forwarders to your original domain's SPF policy to repair their route.

Set DMARC reporting without weakening existing protection

Inspect the applicable DMARC policy, including parent inheritance for a child domain. Preserve existing enforcement and report recipients. Do not replace a working p=reject or p=quarantine policy with p=none merely to make a new sender appear less disruptive.

If no applicable policy exists and the domain owner approves a monitoring rollout, a starting pattern is:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use an approved, working reporting mailbox in place of the example. For an external report destination, ensure any required recipient-domain authorization is in place. External reporting authorization Review aggregate source IPs, volume, authentication and alignment across Yandex and every other sender. Reports complement message tests; they do not guarantee every receiver reports or every route was sampled. DMARC aggregate 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.

Current DMARC is RFC 9989, which supersedes RFC 7489 and removes pct. Do not plan a new rollout around percentage sampling. Its enforcement guidance also calls for valid DKIM when publishing p=reject; one aligned SPF test is not sufficient readiness evidence. Current DMARC standard

Troubleshoot the observed result

If webmail works but a website form fails, first identify its real SMTP path. Yandex's troubleshooting guidance notes problems with site-generated mail, including PHP mail(). DNS for the corporate mailbox does not automatically authenticate that separate web-host sender. Yandex mail troubleshooting

If authentication passes but mail is rejected or filtered, retain the recipient response and examine sending limits, reputation and content separately. Do not disable security settings or weaken domain-wide policy to conceal a local application error.

Keep a clear completion and recovery record

Save the sender inventory, DNS before/after values, verification status, selector identity and external-message results. If a change fails, pause the affected sender or restore the previously approved records through the DNS owner; preserve other services and public keys still needed by in-flight messages. Retest after migration, key changes or outbound gateway changes.

This guide describes documented procedures and proposed acceptance checks. It does not claim that an account was configured, DNS changed, a message sent, or recipient acceptance verified. Authentication improves identity verification but does not promise inbox placement.