For Kagoya Secure Basic, Dedicated type R2s and Enterprise R2s custom-domain mail, configure SPF in the sending-domain authentication settings, generate a domain-specific DKIM public key, publish it in authoritative DNS, then separately enable signature addition and click Update. Outgoing mail must use SMTP AUTH to receive the documented DKIM signature. A published key alone does not turn signing on. Kagoya SPF manual, Kagoya DKIM manual.
Check your mail plan and sending route first
This guide covers the overlap between Kagoya's SPF and DKIM manuals: メールプラン セキュアベーシック, メールプラン 専用タイプ R2s, and メールプラン エンタープライズ R2s. The DKIM manual also discusses KAGOYA MAIL, but that does not establish the same SPF interface for every newer MAIL plan. Shared-mail service is not supported by the documented DKIM workflow. Do not apply this guide to shared mail, an address ending in @kagoya.net, a Kagoya select-domain address, an arbitrary VPS mail server, or a separate external email service.
Your custom domain must already be configured for Kagoya mail. The documented location is Control Panel → Mail → Domain settings → Custom domain management. You need access to the relevant account controls and permission to edit the authoritative DNS zone. The manuals do not establish a universal named administrator role or a region-independent entitlement for unrelated products. If the controls are absent, confirm your plan rather than substituting another provider's menu.
Identify the real outgoing route. A mailbox using authenticated Kagoya SMTP is different from a website application that sends through another relay or uses an IP-based permission without SMTP authentication. Kagoya specifically requires SMTP AUTH for this DKIM feature. Active! gate has additional SPF behavior and is outside the ordinary route covered here. Eligibility and SMTP AUTH requirement.
Save the existing DNS and authentication configuration
Before selecting any creation or update action, record the current authoritative nameservers, relevant TXT records, DKIM selectors, applicable DMARC policy and legitimate sending services. Keep a timestamped copy of the affected records and account settings for rollback.
Kagoya's DNS changes apply when the domain uses its documented nameservers, ns0.kagoya.net and ns1.kagoya.net. If another provider is authoritative, publish there. Registration with Kagoya alone does not establish DNS authority. Do not migrate nameservers, change MX, alter DNSSEC or move mailboxes just to make this tutorial's controls applicable. DNS authority requirements.
SPF authenticates the SMTP envelope MAIL FROM domain, not automatically the visible From address. In relevant empty-return-path cases it uses HELO. A child envelope domain does not inherit its parent's SPF policy. A provider-owned envelope can pass SPF without aligning with your brand; changing your apex SPF cannot fix a policy evaluated at an unrelated domain. These manuals do not promise a universal Return-Path. Verify the actual identity in delivered mail. SPF identities.
Configure the account's SPF policy without overwriting other senders
In the Kagoya control panel, open Mail → Sending-domain authentication → SPF record settings. Select the domain. For an appropriate first-time configuration, the manual describes Set SPF record, followed by OK. Its documented default has this shape:
v=spf1 a:ACTUAL_MAIL_SERVER_HOSTNAME ~all
ACTUAL_MAIL_SERVER_HOSTNAME is a placeholder. Use the mail-server name supplied for your account, not a sample from a screenshot and not an invented include:kagoya.net. The manual's example section contains an includ: typo; that is not a valid SPF mechanism to copy. Creation and update instructions.
The a: mechanism authorizes the applicable A/AAAA addresses of that hostname. Confirm those resolved addresses are the approved account's outbound servers rather than assuming any similarly named website or inbound host should send. SPF a mechanism.
If an SPF policy already exists at the required owner, do not invoke initial creation blindly. Compare the account suggestion with that policy and the full sender inventory first. Preserve all still-authorized services and the intended unmatched-sender qualifier. If the creation action's effect on your existing record is unclear, stop and have Kagoya or the DNS administrator resolve it before saving.
The update screen displays both the currently configured record and the record generated from the current selections. It supports IPv4, IPv6, hostname and include inputs; the plus controls add entries. Review the resulting policy, choose the appropriate DNS reflection setting, then Update and confirm. The manual states that Do not use for DNS reflection does not make the record effective on the internet. With external DNS, reconcile and publish the exact approved policy at the external authority instead of assuming this setting changes that zone.
Keep one TXT record beginning v=spf1 at each evaluated owner. Merge mechanisms before the terminal all; never concatenate two complete SPF policies or add a second one. Preserve unrelated TXT verification records. ~all means softfail for unmatched senders, not pass or a guarantee of delivery. Never use +all as a repair. An all mechanism causes redirect to be ignored. SPF processing rules.
Kagoya's editor documents a 250-character limit. This is an interface constraint, not SPF's protocol-wide size limit. Do not truncate a policy, discard other senders, or split it into multiple SPF records to fit. Coordinate a supported representation with the provider when the reconciled policy exceeds the interface limit. Separately evaluate the SPF budget of ten DNS-dependent terms, including nested includes and other evaluated lookup-causing mechanisms; counting only visible includes is insufficient.
Generate DKIM and enable signing separately
Open Mail → Sending-domain authentication → DKIM signature settings. Select the custom domain, enter a selector and select 新規追加 (Add new). Use a simple, unique lowercase-alphanumeric selector accepted by the current interface; do not reuse an active selector owned by another sender. Registration generates the public key for that domain and selector. Kagoya DKIM steps.
For external DNS, the public record has this structural form:
Owner: YOUR_SELECTOR._domainkey.example.com
Type: TXT
Value: COMPLETE_PUBLIC_DKIM_VALUE_FROM_KAGOYA
Replace every placeholder with the account-issued data. Copy the complete tagged public value, including the full key, without ellipses or line-number labels. Never copy the manual's sample key, expose a private key or create an unrelated key pair in a third-party generator. Kagoya's signer must hold the private key matching this published public key.
Confirm that the generated key is publicly available at the exact owner. Then return to the selector row, select the signature addition checkbox, and click Update. The manual shows a completion message after the update. This is a distinct step after record generation/publication, not something a DNS lookup can perform. The manual describes approximately an hour for DNS reflection in part of this flow, with other cautions allowing longer; verify actual authoritative and resolver answers rather than treating elapsed time as success.
For this documented route, send through SMTP AUTH. If a client or application relies only on IP-based SMTP permission, publishing a key and selecting the checkbox does not satisfy that prerequisite. Do not change application credentials or routing without the account owner's approval.
Kagoya permits up to five keys per domain and two signing keys simultaneously in this interface. For rotation, publish the new key before enabling its signature and validate it before retiring the old one. The manual recommends retaining old keys for 7–30 days; account for queued mail and the actual sender's rotation plan. Do not delete an active selector merely to clear a limit. A separate statement about KAGOYA MAIL Silver's 2048-bit DKIM and ARC is not evidence that every plan covered here has identical capabilities. Signing and rotation guidance.
Publish at the correct DNS owner
For YOUR_SELECTOR._domainkey.example.com in the example.com zone, many editors expect the relative label YOUR_SELECTOR._domainkey. An editor that appends the zone automatically must not receive the full name twice. For a signing domain of news.example.com, the label is YOUR_SELECTOR._domainkey.news in the parent zone, but YOUR_SELECTOR._domainkey in a separately delegated news.example.com zone.
Inspect any delegation of _domainkey or a narrower namespace. Publish at the actual authoritative destination; do not remove a delegation to force a local TXT record to appear. A TXT record cannot coexist with a CNAME at the same owner. If the selected owner already points elsewhere, resolve ownership and dependencies before changing it. Preserve other services' selectors. Multiple quoted chunks within one TXT record can represent one complete key; separate conflicting key records are not equivalent.
For the exact illustrative full owner YOUR_SELECTOR._domainkey.news.example.com, a separately delegated _domainkey.news.example.com zone uses relative YOUR_SELECTOR. A full-name field uses the complete owner. Replace that placeholder with the selector registered in Kagoya, and preserve the existing delegation. DNS zone boundaries.
Preserve DMARC and approved reporting
DMARC passes when SPF passes with an aligned envelope domain or DKIM passes with an aligned signing domain. Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality. For example, news.example.com and example.com can align in relaxed mode but not strict mode. Read the effective aspf and adkim settings rather than promising strict alignment from a child domain. Current DMARC standard.
Preserve existing direct and inherited DMARC policies and approved report destinations. Do not replace quarantine or reject with none, duplicate the policy, or use obsolete percentage-based rollout advice as part of Kagoya onboarding. Only when no direct or applicable inherited policy exists, and the owner approves a monitored first-policy rollout, this is an illustrative starting record:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none;
For that policy in the parent zone, the relative owner is _dmarc. A deliberately chosen child policy at _dmarc.news.example.com uses _dmarc.news in the parent zone or _dmarc in the delegated child zone. The example deliberately omits a reporting recipient: agree an authorized destination or another defined monitoring arrangement rather than copying someone else's address.
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 the policy domain is excepted; a different hostname alone does not make it external. This protocol check does not replace the owner's separate approval to share report data. RFC 9990 section 4.
Verify DNS, then an actual authenticated SMTP message
These are read-only command examples, not test results. Substitute your real zone, authoritative nameserver, SPF owner and selector:
dig +short NS example.com
dig @ns1.dns-host.example TXT example.com +noall +answer
dig @ns1.dns-host.example TXT YOUR_SELECTOR._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT YOUR_SELECTOR._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer
Repeat the queries against each authoritative nameserver. Query the actual child SPF owner if the account uses one. Expect one correct SPF policy, the exact issued public key and the preserved DMARC policy. NXDOMAIN means the name does not exist; SERVFAIL, timeout and conflicting authoritative answers need investigation. Cached negative answers can outlive a correction. Waiting cannot fix a wrong label.
With signing enabled, send a newly authorized test to a controlled valid recipient through the actual Kagoya SMTP AUTH path and intended From identity. Test website applications separately if they use a different route. No messages were sent while preparing this guide.
Open the received original message using the receiving service's documented tools. Establish which Authentication-Results fields were produced within its known processing boundary and how that system removes or treats externally supplied result fields. Ask the receiving administrator if that boundary is unclear. A familiar authserv-id string or header position alone is not proof; ignore attacker-supplied and otherwise untrusted results. Authentication-Results security.
Acceptance requires the intended branded visible From, the intended Kagoya signature with dkim=pass, matching expected d= and s=, alignment under the effective policy, and trusted dmarc=pass. A DMARC pass achieved only through SPF or an unrelated signature does not prove this DKIM deployment works. Record actual smtp.mailfrom and assess SPF independently: investigate fail, softfail, neutral, none, temperror and permerror even if aligned DKIM rescues DMARC. Kagoya documents DKIM authentication results, but no dashboard state guarantees inbox placement. Kagoya result meanings.
Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.
If Microsoft 365 is another legitimate sender, retain its separate configuration and test that route independently; Kagoya's authorization does not cover it. See the Microsoft 365 authentication guide for that distinct sending path.
Troubleshooting and safe rollback
- Key is visible but no Kagoya signature: check the signature-addition checkbox and saved Update, then verify SMTP AUTH and the actual sending route.
- SPF editor rejects the change: compare the generated policy with the 250-character UI limit and syntax; do not remove legitimate senders just to save it.
- Record appears only inside the panel: confirm DNS authority and reflection state. External DNS is not updated by a Kagoya-only change.
- DKIM fails rather than being absent: compare message
d=ands=with the exact public key, then investigate rotation mismatch or message modification. - DKIM passes but DMARC fails: compare signing and visible From domains under the effective alignment mode, including strict settings.
For rollback, restore only the affected record or setting after checking for intervening legitimate edits. Do not restore the whole zone or delete selectors used by queued mail. If a new selector is faulty, coordinate returning signing to the last verified key before retiring anything. Recheck unaffected senders and the preserved DMARC policy.
Sources and testing limits
The cited Kagoya manuals and relevant screenshots were inspected; no provider publication/update date is asserted where none was established. This is documentary guidance, not a tested customer deployment. Account entitlement, DNS changes, delivered-message results, visual CMS rendering, publication, indexing, rankings and inbox placement remain untested.