This guide covers own-domain messages sent through the native Rakuraku Jidootai service, formerly Mail Dealer. It does not configure external SMTP, Rakuten masked-address delivery, forwarding, or other RAKUS products. No account configuration, DNS changes or test sends were performed.
Quick answer
Use the actual service hostname for native SPF authorization and configure an author signature (作成者署名) for branded DKIM. Creating a key is not enough: publish its public DNS record and assign the signature to the intended From address. Do not assume the built-in third-party signature authenticates your own domain for DMARC.
RAKUS confirms the change from Mail Dealer to 楽楽自動応対. We retain the familiar Mail Dealer name to help existing customers find the correct product, not to imply that old screenshots establish a current account's values.
SPF authorizes servers for an envelope domain; DKIM verifies a signature associated with a signing domain. DMARC requires a passing authentication domain to align with the visible From. These are separate from connecting an inbox or adding a visible text signature to an email.
Choose the right sending route
Record the actual outgoing service and every approved From address before editing. An existing external SMTP connection is a different route: do not switch it merely to follow this guide. Its server administrator must supply current authentication instructions. For Microsoft-hosted mail, see our Microsoft 365 DMARC guide.
The provider FAQ distinguishes the built-in third-party signature from an author signature with your own public key. It also warns that system notifications and automatic replies differ from manually sent messages for SPF and directs users toward author signing. Do not extend a successful manual-message test to those flows.
The environment manual explicitly excludes DKIM for Rakuten Anshin masked-address delivery. That route is outside this article. It is not fixed by copying these records into your ordinary domain.
Before changes, obtain the domain owner's approval for exact records and affected From addresses. Save the existing signature assignments, defaults, DNS values and inherited DMARC policy. Verify actual DNS authority and any child or _domainkey delegation. Do not change account permissions, nameservers, mailbox MX or sender routes as a shortcut.
Create the author signature and publish its public key
In the environment settings workflow, open the gear icon → 管理設定 (administration) → 環境設定 (environment) → 電子署名の設定 (electronic signatures).
Choose 電子署名の追加登録 → 電子署名の新規登録 to create a signature. In the documented registration form:
- セレクタ is the selector. The form specifies up to 20 half-width characters. Choose an unused DNS-safe alphanumeric label and record it; do not overwrite another sender's selector.
- ドメイン is the approved signing domain, normally the intended From domain. It must be a domain whose public DNS you control.
- For 秘密鍵, select 自動生成する, the automatic key-pair option. The alternative manual field accepts a private key; this guide does not ask you to import or disclose one.
Use 登録 to register. Obtain the generated public record from the account before making DNS changes. The provider describes TXT publication at the signing domain's DNS. Publish only the public record, never the private key. If the full DNS owner and value are not available, stop for the current account instructions rather than constructing a key from a screenshot.
Registration is not activation for every From address. After DNS publication, return to 電子署名の利用条件設定 → 利用条件の新規登録 and assign the new signature to each approved From address. Choose the intended entry in 電子署名(FQDN), then 登録. These conditions are per address, not a domain-wide rule.
Review 電子署名の利用に関する基本設定 separately. Its default can affect unmatched messages and other flows. Change it with 変更 only when the owner approves the full impact; do not globally replace a working default with a signature that aligns with only one domain. The default-selection screenshot also warns that selecting 使用しない disables signing.
Put each record in the authoritative zone
The DNS service hosting public authoritative answers may differ from your registrar. Follow existing delegations rather than deleting them. For an illustrative full owner SELECTOR._domainkey.news.example.com:
| Authoritative zone | Relative owner if the editor appends this zone |
|---|---|
example.com |
SELECTOR._domainkey.news |
Separately delegated news.example.com |
SELECTOR._domainkey |
Separately delegated _domainkey.news.example.com |
SELECTOR |
These are owner-mapping examples, not a ready-to-publish customer record. Replace the example with the actual complete name. This documented route publishes a TXT public key. Preserve its entire generated value; keep selector/domain components in the owner field, not in the key value. Confirm whether your editor accepts full or relative names. Do not append the zone twice. DNS name rules and DKIM key lookup explain the distinction.
Do not put the TXT key at an owner already occupied by a CNAME. A CNAME cannot coexist with ordinary conflicting data at the same owner. Stop and investigate a conflict rather than deleting a working selector, TXT record or delegation. Preserve unrelated and standby selectors. An inactive-looking selector may be needed for rotation or queued mail.
Configure native Mail Dealer SPF
The native SPF manual specifies an include using your actual service hostname, which it identifies from the service URL:
include:YOUR_ACTUAL_SERVICE_HOSTNAME
The documentation's md.maildealer.jp is a placeholder, not a universal record. Copy only the genuine account hostname, without https://, a slash or a path. If your current hostname does not match the documented pattern, ask RAKUS to confirm the supported SPF include rather than guessing after a rebrand. The provider recommends hostname-based authorization because server IPs can change.
Confirm the actual SMTP MAIL FROM domain for the intended native message before editing SPF. The visible From does not alone establish the SPF owner. Do not alter your domain to fix an envelope domain controlled by the provider, or attempt to publish records for a free shared mailbox domain. Notifications and automatic replies need their own route-specific checks.
For an applicable customer-controlled envelope domain, merge the confirmed include into that owner's single existing SPF TXT policy, with approval. Preserve other legitimate senders and the intentional final qualifier. Never publish a second v=spf1 record. Do not copy the manual's placeholder IP, curly quotes or complete one-sender example. If there is no policy, inventory every authorized sender before approving a new complete policy.
Evaluate nested includes against SPF's ten DNS-dependent-term limit. Preserve policy structure: a redirect is ignored when all is present, and an include after a matching all will not authorize this service. Neither a lookup success nor an SPF pass establishes DKIM alignment. SPF protocol rules.
Preserve DMARC protection and reporting controls
Read the policy applicable to the visible From domain, including inheritance and alignment settings, before editing. Do not overwrite enforcement with monitoring to make this sender pass. Adding a child policy can change inherited protection, so it requires explicit review.
Only when no applicable policy exists and the domain owner approves an initial monitoring policy, an illustrative TXT value is:
v=DMARC1; p=none
For From domain example.com, publish at full owner _dmarc.example.com, or relative _dmarc in that zone. For news.example.com, the full owner is _dmarc.news.example.com: relative _dmarc.news in the parent zone, or _dmarc in a separately delegated child zone. Do not create a child monitoring exception to an existing protective parent. This example requests no reports and provides no enforcement.
If reporting is separately approved, confirm the destination and permission to disclose report data. External report authorization is a distinct protocol check: compare the report destination's Organizational Domain with the policy domain's Organizational Domain. If they differ, the receiver generating the report must check DNS authorization before sending it; if they are the same, that external-destination authorization check is excepted. RFC 9990 section 4 defines this rule. Where required, have the report destination operator provision the correct authorization record. A DNS authorization record is not the user's privacy approval.
Verify three separate layers
Public DNS
Compare the complete public TXT key at the exact selector owner with the account-generated record. Query the authoritative server first, then a recursive resolver. Example placeholders, not tests already performed:
dig @AUTHORITATIVE_SERVER TXT SELECTOR._domainkey.SIGNING_DOMAIN
dig TXT SELECTOR._domainkey.SIGNING_DOMAIN
dig TXT CONFIRMED_ENVELOPE_DOMAIN
dig TXT EFFECTIVE_DMARC_POLICY_OWNER
Confirm the SPF policy is unique and resolves without errors. Waiting can clear cached old data; it cannot correct an incorrect authoritative record. Do not split a long public key into separate TXT records. If the editor requires multiple quoted character strings, they must form one logical TXT record and reconstruct the exact generated value.
Saved account configuration
Reopen the signature and intended From-address condition to confirm the correct entries were saved. Record the approved default and affected flows. The reviewed manual does not establish a universal green DNS-verification badge; do not invent one. A saved form does not prove that a message is signed.
A controlled delivered message
Use a harmless new message to a controlled mailbox with the approved From. The sending manual documents メール作成, selection of To/From, 次へ, composition, 送信確認, review and 送信. A visible footer signature in this composer is not the DKIM signature. Keep recipient, route and From explicit; follow any existing send-approval controls.
The provider FAQ recommends checking original message details at Gmail. More generally, inspect original headers at the controlled receiver, not a forwarded copy. Trust Authentication-Results only from the receiving service's established processing boundary and its documented handling of externally supplied fields. Header order or a familiar authentication-server identifier alone does not prove trust. Authentication-Results rules.
Acceptance requires the intended author DKIM signature to pass and its signing d= domain to align with the unchanged approved visible From, plus trusted dmarc=pass. A passing built-in third-party signature or an SPF-only DMARC pass is not proof that the new author signature works. A provider-rewritten From is not success for your original branded address.
Under DMARC alignment rules, relaxed alignment compares Organizational Domains and strict alignment requires an exact domain match. Apply adkim to DKIM and aspf to SPF separately. Retest each approved From address; a single working address does not establish all per-address conditions.
Troubleshoot the failing layer
| Symptom | What to examine |
|---|---|
SPF fail |
The evaluated source is not authorized by the evaluated policy. Confirm the actual envelope domain and approved sending source; repair only the intended policy, not an unrelated visible-From domain. |
SPF temperror |
A temporary DNS lookup problem prevented evaluation. Investigate DNS availability and retry after recovery; do not weaken the policy to bypass the error. |
SPF permerror |
Repair the invalid policy, duplicate SPF records or excessive DNS-lookup budget, as indicated by the diagnostic; then retest. |
| DNS key absent | Actual authoritative zone, delegated child, duplicated suffix and full selector owner. |
| Key found but signature fails | Complete public key, actual selector and signing domain, route and possible message modification. |
| Only third-party DKIM passes | Author-signature registration, exact From condition and default selection. |
| DKIM passes but DMARC fails | Intended signing domain versus visible From and effective alignment policy. |
| One address works, another fails | Per-address assignment and actual outgoing route, not just shared branding. |
| Notification or automatic reply differs | Separate message flow; manual-mail SPF evidence is not transferable. |
| Rakuten masked-address mail fails | Unsupported DKIM route in the cited manual; do not force this recipe onto it. |
Investigate these SPF failures even when aligned DKIM allows DMARC to pass; that pass does not repair SPF.
Keep previous and new DNS values, signature assignments, defaults, timestamps and minimal header evidence. If rollback is needed, restore only the erroneous approved change and account for subsequent shared dependencies. Retain old public keys needed for queued mail and authorized rotation. Never publish private keys or disable DMARC protection to silence an error.
Common questions
Is Mail Dealer the same product as Rakuraku Jidootai?
The official product page confirms this name transition. It does not make Rakuraku Seisan, RAKUS marketing tools or Rakuten merchant services the same sender.
Can I authenticate every From address with one default?
Not safely by assumption. Verify each address's signature selection and alignment. Defaults can affect additional flows, so changes require a scope review.
Is the built-in standard signature enough for branded DMARC?
A valid third-party signature is not proof of alignment with your branded From. Inspect the intended author signature on the delivered message.
Does this guarantee inbox placement?
No. Authentication is one layer; receiver policy, reputation, content and user preferences still matter. This guide is documentary evidence, not a live deployment result.