Quick answer: Rakuraku Seisan (楽楽精算) documents include:spf.rakus-cloud.jp for its native notification-sending infrastructure. Add that authorization only to the appropriate existing SPF policy after confirming the actual SMTP envelope domain. Do not paste the vendor's sample IP placeholder or create a second SPF record. If the existing sender setting uses the fixed provider address keihi-no-reply@rakus-cloud.jp, the provider says it manages SPF for that address: do not add its include to your own domain merely because you receive those notifications.
This is a focused SPF implementation guide, not a customer-domain DKIM setup guide. It covers native Rakuraku Seisan notifications, not Rakuraku Hanbai, Mail Dealer, marketing services or external SMTP. It does not establish customer-domain DKIM issuance, activation or successful brand authentication.
Identify the sender before touching DNS
Open 管理 (Management) → システム設定 (System settings) → その他 (Other) and inspect 送信者アドレス設定 (Sender address setting). The current system-settings manual describes two choices:
| Existing choice | Meaning | SPF action in this guide |
|---|---|---|
| 社員マスタのアドレス | Address stored in the employee master; an action by an employee can cause their address to appear as the notification sender. | Establish the actual sending flow and evaluated envelope domain before authorizing native infrastructure. |
| 固定のアドレス | Fixed provider address, identified in the SPF FAQ as keihi-no-reply@rakus-cloud.jp. |
Provider manages SPF for this address. No customer-domain include is required solely for this route. |
Read the selected option without changing it. Switching to a fixed address changes the visible sender identity and is not a DNS repair. It requires a separate decision about business expectations and workflows. This article does not ask you to change employee addresses, notification recipients or application settings.
The official SPF FAQ states that native notifications use Rakuraku Seisan's sending servers rather than the customer's contracted mail server. However, visible From and SMTP MAIL FROM are different identities. SPF evaluates MAIL FROM, or HELO for relevant empty-envelope cases, not automatically the address displayed to the reader. Obtain a controlled notification's trusted receiving results or product-specific vendor confirmation identifying the actual envelope domain. Do not assume it always equals the employee address or your apex domain.
If the evaluated domain belongs to the provider, you cannot repair its SPF by adding a record under your domain. If you cannot establish the actual identity, pause the DNS edit rather than guessing.
Prepare the exact change
You need read access to the sender setting, authorized management of the relevant DNS zone, the current full SPF TXT value and approval for the precise modification. Retain the current record and TTL, the evaluated envelope identity, the provider route and legitimate services already authorized.
- Query TXT records at the actual evaluated domain. Separate SPF from unrelated TXT data.
- If one SPF policy exists, plan an edit to that policy, not an additional policy.
- If multiple
v=spf1records exist, reconcile them into one valid policy with the domain administrator before adding anything. - If no SPF policy exists, inventory all legitimate sending services first. A new policy must not accidentally reject another system.
- Confirm native Seisan notifications are meant to use this domain. Do not broaden an unrelated parent domain just because its name looks familiar.
If your existing corporate mailbox is Microsoft 365, preserve its separate authorization and follow the Microsoft 365 authentication guide for that route. The Seisan include does not replace Microsoft 365 or another mail provider.
Add the documented native SPF authorization
The SPF FAQ supplies this include:
include:spf.rakus-cloud.jp
Its full example contains an ip4: placeholder for the customer's own sending-server IP, not a universal Rakuraku Seisan IP. Do not copy the Japanese placeholder or invent an IP address. The provider's infrastructure is represented by the include above.
Add the include to the approved single policy while preserving legitimate mechanisms and qualifiers. Put applicable authorizations before the final all mechanism; material after all is not a usable authorization. Do not copy the source's ~all ending over an existing -all or otherwise change policy intent without approval. SPF qualifiers do not guarantee what every receiving system will do.
Check the evaluated DNS-dependent term budget: the limit is 10, including nested mechanisms and modifiers that count, not simply ten text strings beginning include. The vendor FAQ describes a current nested-include count, but that is not a permanent budget guarantee. Inspect the complete evaluated policy chain, including other providers. If the policy uses redirect, review its intended behavior: redirect is ignored when an all mechanism is present. Do not flatten changing provider IPs into a hand-maintained list merely to bypass an error.
Put the TXT record at the correct owner
Use the actual evaluated domain, not these illustrative names:
| Full evaluated owner | Authoritative zone | Typical relative TXT owner |
|---|---|---|
example.com |
example.com |
@ or the host's apex representation |
notify.example.com |
Parent example.com zone |
notify |
notify.example.com |
Separately delegated notify.example.com zone |
@ or the host's apex representation |
DNS interfaces vary: confirm the resulting full owner before saving. Avoid an accidental name such as notify.example.com.example.com. If a child zone is delegated, edit the authoritative child zone instead of leaving a non-authoritative TXT record in the parent. Preserve NS delegations, DNSSEC and existing mail routing.
Use TXT and the complete approved SPF value. Do not add SPF as a CNAME or place it beside an existing CNAME at the same owner. An owner conflict requires a supported design decision, not deletion of the alias. Do not change MX, IP routes or nameservers for this task.
Save only the approved record change in your DNS host. This guide does not claim a universal DNS-host Save button, a Seisan verification badge or a native SPF activation switch.
Verify DNS and an actual notification separately
First query authoritative DNS and an independent resolver for the exact owner. Confirm there is one SPF policy, the new include is present in the intended place, the other authorizations remain intact and the lookup budget is valid. Allow existing TTL caches to expire where needed. A published TXT record alone is not a delivered-message test.
Then use an approved, non-sensitive test notification through the actual intended Seisan workflow to a controlled valid recipient. Do not submit a real expense, approve a payment or trigger broad employee notifications merely to generate test mail. If no safe existing test workflow is available, coordinate one with the administrator or vendor; this guide does not invent a dedicated test-send button.
Inspect results generated inside the receiving service's known processing boundary, using that service's documented handling of externally supplied Authentication-Results. Header position and a familiar authserv-id string are not proof of trust. Ignore attacker-supplied result fields.
For this narrow SPF task, verify spf=pass for the intended envelope domain and route. Record the actual smtp.mailfrom, visible From and receiving result. A provider-owned envelope SPF pass is not evidence that your brand's SPF alignment works.
Under DMARC's current alignment rules, relaxed SPF alignment compares Organizational Domains; strict SPF alignment requires an exact match. A child envelope domain may meet relaxed alignment but not strict aspf=s. Inspect the effective policy, not a presumed default. Authentication, alignment and DMARC outcome are separate checks.
Customer-domain DKIM is unresolved by the primary Seisan instructions reviewed here. Do not copy Mail Dealer or Hanbai selectors, keys or menu paths. A future branded DKIM implementation must obtain actual public records and signing instructions, then prove the intended signature passes, aligns under adkim, and yields trusted dmarc=pass; an SPF-only DMARC pass does not prove DKIM works.
Troubleshoot without weakening protection
| Result | Action |
|---|---|
SPF fail |
The evaluated source is not authorized. Recheck the real envelope owner, sending route and intended source authorization. Do not patch an unrelated visible-From domain. |
SPF temperror |
Investigate temporary DNS lookup availability and retry after recovery. Do not weaken policy to bypass it. |
SPF permerror |
Repair invalid syntax, duplicate SPF records or an exceeded lookup budget identified by the diagnostic, then retest. |
| SPF passes but DMARC fails | Check envelope-to-From alignment and the effective policy. This narrow guide cannot certify a missing aligned DKIM route. |
| Fixed provider address is selected | Do not add customer SPF just to fix provider-owned identity. Retain headers and ask the provider to investigate its route if needed. |
Investigate SPF errors even when aligned DKIM independently lets DMARC pass. Keep before-and-after records and minimal test evidence. Roll back only the erroneous approved change after accounting for subsequent shared changes.
Preserve DMARC and reporting decisions
Do not add, weaken or duplicate DMARC records as a side effect of SPF setup. Preserve direct and inherited policies and authorized reporting destinations. This guide does not create a first DMARC policy or configure reports.
If report destinations are reviewed separately, compare their Organizational Domain with the policy domain's Organizational Domain. A different Organizational Domain requires the report-generating receiver to check DNS authorization before sending; the same Organizational Domain is excepted. RFC 9990 section 4 defines this distinction. DNS authorization does not replace the owner's permission to disclose reporting data.
Common questions
Do I need this include when Seisan uses its fixed address?
The official FAQ says customer SPF setup is unnecessary for the fixed keihi-no-reply@rakus-cloud.jp choice because the provider configures it. Do not edit provider-owned DNS or your own unrelated policy.
Can I use a personal Gmail or shared email domain?
You generally cannot publish SPF for a domain you do not control. The vendor lists shared-domain restrictions. Do not attempt to authenticate gmail.com in your DNS zone or change employees' addresses without authorization.
Does SPF setup complete all Rakuraku Seisan authentication?
No. This article completes only the documented SPF task for the qualified native route. It does not establish customer-domain DKIM setup, a successful DMARC deployment or guaranteed inbox placement. Seisan's 2024 Gmail notice is historical guidance, not a current universal sender-policy guarantee.