This guide covers Onamae.com Rental Server Basic/RS native email, a specific GMO service. It is not a group-wide GMO configuration guide, an Onamae Mail plan guide, or an external sender setup recipe. No customer account, DNS change or test message was used in preparing it.
Quick answer
For Onamae.com Rental Server Basic/RS native mail, SPF and DKIM are initially configured according to Onamae's authentication help. Verify those defaults on your actual domain rather than adding a second SPF policy or inventing a DKIM key. DMARC is configured separately in the hosting control panel. If you use external authoritative DNS, publishing the generated records there remains your responsibility. Registration at Onamae alone does not mean its hosting DNS is authoritative.
This guide takes you through the safe native-mail route: identify the product and DNS authority, inspect existing authentication, make an approved DMARC change, and verify a real message. Third-party campaign senders need their own issued records and signing setup. DNS publication cannot make an unrelated service sign your messages.
Confirm the product before copying any setting
GMO is a group of different services, not one universal sending platform. Its service-by-service authentication announcement distinguishes Onamae from ConoHa, WADAX and other offerings. Use current product documentation for configuration, not a group name as an SPF include.
This article's operative instructions are for Rental Server Basic/RS. Onamae's current help distinguishes these plans from Shared Server SD and Onamae Mail Light/Standard, for which it documents different DKIM/DMARC support limitations. Do not apply this panel recipe to those products. Onamae Mail Economy/Basic also has separately linked instructions. Confirm the exact product in your contract or ask support; a provider logo is not enough to identify it. Product and nameserver decision guide.
Record the intended visible From domain, every application sending as it, the domain used for bounces, and who controls its DNS. Include website forms, billing systems and marketing platforms, not only staff mailboxes. Obtain authorization for any DNS, policy or reporting change before proceeding.
Find the DNS that actually answers
Check the domain's current delegation with your DNS administrator and a public NS lookup. Inspect delegated child zones separately. A parent domain's nameservers do not automatically control a delegated sending subdomain or delegated _domainkey zone.
Onamae's help identifies hosting DNS separately from the registrar's 01.dnsv.jp through 04.dnsv.jp service. Do not move nameservers simply to configure authentication. The provider explicitly warns that a registrar DNS workflow can change delegation if its nameserver-change option is selected, breaking mail or the website. Onamae troubleshooting advice.
Export the current zone and note nameservers, MX, website records, authentication records and TTLs. Preserve all unrelated records. If the panel's records differ from the public authoritative answers, resolve that mismatch before editing. An unused zone can look correct in a dashboard without affecting delivery.
Inspect SPF and DKIM before changing them
In the hosting control panel, open Domain and select DNS beside the intended domain to view its record list. This is an inspection step, not an instruction to delete or recreate the zone. Official DNS-list procedure.
Compare the current SPF policy and DKIM publication with the live authoritative records and a message sent through the intended native mailbox. The defaults are a starting point, not evidence that your own domain is correctly aligned today. If external DNS is authoritative, use the provider's exact domain-specific records; if any record or signing detail is missing, obtain it from support rather than copying another customer's configuration.
SPF is evaluated at the envelope MAIL FROM domain, with HELO relevant in applicable cases; it does not simply authenticate the visible From address. Keep one v=spf1 policy at each evaluated owner. Existing legitimate senders must remain authorized. Adding another TXT record containing a second SPF policy creates a configuration error, not extra coverage. A DNS owner may still legitimately have unrelated TXT records.
If you also use another sender, assess the whole SPF policy before merging its documented authorization. Respect the ten DNS-dependent-term evaluation limit, including nested processing. A policy with an all mechanism does not use its redirect modifier. Do not change ~all to -all as a cure for missing authorization, and do not describe either qualifier as a guarantee of receiver delivery. SPF standard.
For DKIM, use the actual signing domain and selector from the intended provider's signature. The public key lookup normally uses selector._domainkey.signing-domain. Never publish a private key, guess a selector, or reuse a public-key example. TXT and CNAME instructions are not interchangeable. A CNAME must not conflict with other data at the same owner; when an external DNS service offers proxying or CNAME flattening, disable proxying and per-record flattening where supported; ensure applicable zone-wide settings preserve the issued alias, including apex or same-zone exceptions. If mandatory behavior cannot preserve that required DNS answer, stop and obtain a supported configuration rather than proceeding. DKIM standard.
A record appearing in DNS does not establish that a particular sending application signs correctly. Keep signing verification and DNS verification as separate checks.
Check existing DMARC policy before opening the switch
Look up the applicable DMARC policy for the actual From domain, including parent-domain policy that may apply when a subdomain has no direct record. Save the entire existing record, including policy, subdomain policy, alignment settings and report destinations. Do not replace an established policy with a short example from this guide.
For a first rollout with no direct or applicable inherited policy, an owner-approved monitoring policy can be a measured starting point while legitimate sources are verified. That is not permission to weaken an existing enforcement policy. If the panel cannot preserve your existing advanced tags or reporting requirements, stop and obtain a supported change procedure from Onamae before saving.
The UI actions are メールを配送しない (do not deliver: p=reject), 迷惑メールとして判定し配送する (treat as junk: p=quarantine), and 何もしない (take no action: p=none). These express domain policy; the receiving system ultimately decides handling. A monitoring policy does not block spoofing. Turning the feature OFF removes its DMARC TXT record, so OFF is not a harmless troubleshooting reset. Duplicate or invalid records can trigger a panel error. Official DMARC controls and record examples.
Make the approved DMARC change in Basic/RS
Only continue after resolving the policy-preservation checks above. The provider documents these steps:
- Sign in to the Rental Server control panel, open メール (Mail), then メールセキュリティ (Mail Security).
- Select the intended domain. The common
onamaeweb.jpdomain is not eligible for this feature. - Set DMARC 認証設定 (DMARC authentication) to ON and select the already-approved handling action.
- Choose 確認する (confirm), then review the screen and warnings. The authorized account owner must agree to the displayed notice before committing the change.
- Choose 変更する (change) and check for the panel's success message.
The official procedure includes the Japanese labels and screen illustrations. If your product or controls differ, do not improvise a matching-looking toggle.
For the first monitoring rollout only, after the no-direct-or-inherited-policy and owner-approval checks above, the provider documents a generated TXT record at _dmarc.<domain> with value v=DMARC1; p=none. Replace the domain placeholder with the selected domain; copy the actual generated record rather than overwriting advanced existing settings with this minimal example.
Inspect the resulting record through Domain → DNS and compare it with the approved policy. With external DNS, copy the exact generated TXT record to the correct authoritative owner using that DNS host's verified publication procedure. Do not duplicate an existing policy or assume every DNS host accepts the same relative-name format. Onamae warns that manually configured DMARC is outside its operation guarantee; obtain support confirmation for an external-DNS or advanced-policy situation that does not fit the documented generated-record workflow. Provider workflow boundary.
Configure report notifications deliberately
Onamae provides a separate report-notification setting under Mail → Mail Security for the selected domain. After enabling it, choose an existing mailbox offered for that domain or subdomain, verify the selected address, review the notice and complete the confirmation. Do not assume the policy switch alone configures the desired reporting recipient. Official report-notification procedure.
Use a monitored, authorized mailbox. This panel feature is not evidence that arbitrary external rua addresses are supported by the same UI. For a separately approved reporting arrangement, verify both provider support and destination authorization before changing records. Reports can reveal sending infrastructure and authentication results; permission to receive them is distinct from DNS correctness.
For external aggregate reporting, the DMARC report-destination authorization rule depends on Organizational Domain, not merely two addresses having different hostnames. A same-Organizational-Domain destination has the specified exception; otherwise verify the required destination DNS authorization. That technical check does not replace permission to share reporting data. DMARC aggregate reporting, section 4.
Verify DNS, then a real message
First identify the authoritative server for each actual record owner. Replace every angle-bracket placeholder below with a verified value; these are inspection commands, not DNS records to publish:
dig @<authoritative-nameserver> TXT <actual-spf-owner>
dig @<authoritative-nameserver> TXT <selector>._domainkey.<signing-domain>
dig @<authoritative-nameserver> TXT _dmarc.<from-domain>
If the issued DKIM record is CNAME, inspect its CNAME target and the resolved public key instead. Compare authoritative answers with a recursive resolver after the relevant TTLs. An answer cached before your change may differ temporarily; a wrong authoritative answer is not fixed by waiting.
Next, send from each legitimate application to a controlled test recipient. Inspect authentication results only from the receiver you trust: use its documented boundary that strips or distinguishes untrusted incoming authentication headers, or its authenticated diagnostic view. Do not trust a header merely because it is at the top or names a familiar authentication service.
Record the intended DKIM signature's passing result, selector and signing domain, SPF result and evaluated domain, visible From domain, and DMARC result. A different sender's passing DKIM signature does not prove native Onamae signing is correct. DMARC needs a passing aligned mechanism; SPF and DKIM can individually pass for domains unrelated to the visible From. Strict adkim=s requires exact DKIM-domain alignment; strict aspf=s applies separately to SPF. Relaxed alignment requires the same Organizational Domain, not an unrelated domain. For this native-mail setup, require the intended Onamae DKIM signature to pass and align with the intended From domain, plus a trusted dmarc=pass. SPF-only DMARC success is insufficient evidence that the intended DKIM setup works. DMARC protocol.
If another application sends through Microsoft 365 rather than Onamae, verify that application separately using the Microsoft 365 authentication guide. Do not replace its records with native hosting defaults.
Troubleshooting without breaking working mail
- Panel success but public DNS unchanged: verify authority, child-zone delegation, owner-name expansion and caching. Do not switch nameservers as an experiment.
- SPF fails: inspect the actual MAIL FROM owner and all evaluated authorizations. Do not add a second SPF policy.
- DKIM missing or failing: confirm the exact sending application, selector, public record and provider signing state. Escalate missing provider-issued details rather than guessing keys.
- DMARC fails despite SPF pass: check alignment, not just pass/fail. Verify the intended DKIM path too.
- Existing DMARC tags would disappear: stop before committing. Ask support how the panel manages advanced policy and external DNS.
- Website or mail breaks after a DNS action: compare delegation and the saved zone with the pre-change state. Coordinate an owner-approved correction with the DNS administrator. Do not delete unrelated records or turn DMARC OFF blindly.
For escalation, provide the exact plan, selected domain, authoritative DNS host, relevant public record answers and redacted receiver diagnostics. Never send account passwords or private DKIM keys. Keep a dated change log and the previous record values so an approved rollback restores the specific changed settings rather than resetting the whole zone.