CYBERMAIL Sigma uses include:spfcm.cybermail.jp for its documented native SPF authorization. DKIM requires a generated public TXT record, a Published DNS status, and a separate Enabled setting with the correct key selected and saved. Publishing the public key alone does not turn on signing. This guide covers an existing, approved CYBERMAIL Σ hosted-mail route through MailGates, not every CyberSolutions product. Official SPF instructions, official outgoing DKIM instructions
The instructions assume an administrator can see the documented controls and the domain owner has approved authentication changes. They do not onboard a new gateway, move incoming mail, configure an on-premises MailGates installation, or change inbound spam checks.
On this page: Confirm the exact contracted-domain prerequisite · Preserve the existing configuration · Configure SPF for the actual native envelope route · Generate the DKIM key in the service · Publish the complete public TXT, including its version prefix · Wait for Published, then enable signing separately · Preserve DMARC and approved reporting · Verify the intended signature on a native message · Troubleshooting · Frequently asked questions
Confirm the exact contracted-domain prerequisite
The current DKIM source requires the contracted domain, Envelope From domain and Header From domain to match completely, including uppercase/lowercase spelling. Treat this as CyberSolutions' documented signer-eligibility condition, not a claim that all DNS or DMARC comparisons are case-sensitive. If the account's native route does not meet it, stop and obtain provider guidance before enabling signing.
Use the actual approved sender and envelope configuration. Do not rewrite users' addresses, change contracts, or route a different service through the gateway to satisfy a tutorial. The vendor links a more detailed caution page, but that page required sign-in during research. No exceptions from that inaccessible page are assumed here.
This narrow procedure excludes CYBERMAIL Sigma ST, EMERGENCYMAIL, separate Cloud Mail SECURITYSUITE deployment, on-premises v5/v6, and inbound-only filtering. The official article also notes that some preconfigured gateway/security-suite customers have a hidden Mail Security tab. Do not treat a hidden tab as permission to change roles or recreate an already-managed configuration. Ask the service administrator which supported workflow applies. Scope and domain-matching requirement
Preserve the existing configuration
Record the contracted domain, intended From, actual MAIL FROM domain and existing outbound route. Save the present SPF policy, DKIM selectors, DMARC policy, relevant DNS owners and TTLs, and existing signing selections. Establish who can approve and restore each change.
Check the authoritative DNS service for the actual record owners. A registrar account, a visible DNS zone or the location of the mailbox does not prove that its editor serves public DNS. Preserve MX records, nameserver delegations, website entries and unrelated verification tokens.
Before generating a key with selector mg, inspect mg._domainkey for the intended signing domain and identify any current dependency. If it already belongs to an active sender or another deployment, do not overwrite it. Resolve the collision through a provider-supported change plan. This guide does not invent an alternate-selector exception to the documented route.
Configure SPF for the actual native envelope route
CyberSolutions documents this policy for a domain whose only sender is CYBERMAIL Sigma:
v=spf1 include:spfcm.cybermail.jp ~all
Use that complete example only for the corresponding sole-sender situation and an approved policy decision. For an existing multi-service policy, incorporate the required authorization into the existing policy at the evaluated owner, preserving other legitimate senders and the owner's terminal qualifier. Do not create a second SPF record or replace a shared policy with the sole-sender example. Provider SPF value and product branches
SPF is a DNS configuration, not a setting changed inside MailGates. Its evaluated identity is SMTP MAIL FROM, which should satisfy the exact native-domain prerequisite above. Confirm that identity on the real route instead of inferring it solely from the visible From or corporate MX.
Maintain one v=spf1 policy per evaluated owner. Review the complete nested lookup path against SPF's ten lookup-causing-term limit; an include can lead to additional lookups. Do not use +all, concatenate full policies or remove a legitimate service just to fit the limit. Any all mechanism makes redirect ineffective, so a redirect-based policy requires a deliberate merge preserving its intended authorization. ~all is softfail for an unmatched sender, not a pass. SPF specification
Do not copy the vendor's illustrative private 10.20.30.0/24 addresses as public Internet egress authorization. If another system sends directly to external receivers, establish its actual approved public egress route first. Adding unrelated relay IPs or changing NAT is outside this native hosted-mail setup.
Generate the DKIM key in the service
Open the administrator interface and follow:
Mail Security (メールセキュリティ) → Sending Domain Authentication (送信ドメイン認証) → DKIM Signature (DKIM署名) → DKIM Key Settings (DKIM鍵設定).
For the approved new key:
- Enter the documented selector
mg, after clearing the collision check. - Choose the option for the system to generate the private/public key pair.
- Select Add (追加).
- Use the blue information control for Public Key Content (公開鍵内容) to copy the public value.
Use system generation for this procedure. Do not use the separate private-key upload branch or an external key generator. The screenshot's key is obscured and is not a reusable value. A private key must never be published in DNS, pasted into a public checker or attached to ordinary troubleshooting material. Key generation and public-value retrieval
If a working key already exists, do not generate another merely because a message went to spam. First inspect its published DNS and actual signing. A necessary rotation must coordinate key selection, DNS propagation and retention of old public keys for delayed messages.
Publish the complete public TXT, including its version prefix
The documented owner is mg._domainkey beneath the contracted signing domain. Use the exact Public Key Name shown for the account, not the example domain in the article or screenshot.
The vendor explicitly says its copied public-key content omits v=DKIM1;. In that documented output, prepend v=DKIM1; exactly once to the complete copied k=rsa; p=... content. Inspect the actual value first so you do not duplicate the version tag if the interface changes. Never publish an ellipsis or a shortened example in place of the account's full p= value.
The owner and value have different jobs. In an editor serving example.com that appends the domain, mg._domainkey.example.com is entered as mg._domainkey. For a supported issued owner at mg._domainkey.news.example.com, its relative form is mg._domainkey.news in the parent zone, or mg._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com is itself delegated, the relative owner is mg. These examples explain placement, not permission to use an uncontracted child domain.
Long TXT data may need multiple quoted character strings within one logical TXT record. Receivers concatenate those strings. Do not split the key into separate competing DNS records, truncate it, or downgrade to a weaker key because the DNS editor limits one field to 255 characters. Use the DNS host's supported complete-value representation; stop and ask its support team if that representation is unclear. The vendor's current signing description specifies SHA-256 with 2048-bit RSA. TXT handling and current signing settings
A CNAME at the same owner conflicts with a new TXT. Do not remove another sender's alias to install this record. Resolve its ownership and supported migration separately.
Wait for Published, then enable signing separately
After publishing DNS, reopen the key screen. The service checks DNS when the screen is displayed. The intended key must show Published (公開済) before proceeding; Unpublished (未公開) is not an acceptable activation state.
Also query the authoritative DNS and a recursive resolver, comparing the complete public value and exact owner with the account. A dashboard DNS check does not establish that every resolver has the same cached answer, and a record saved at the wrong authority will not become correct merely by waiting.
Then open DKIM Signature Settings (DKIM署名設定) under the same DKIM Signature section:
- Change DKIM to Enabled (有効).
- Retain the current RSA-SHA256 signing algorithm and appropriate approved canonicalization settings.
- Set the documented signed-body length to
0for the entire body, not a partial-body limit. - Ensure From remains among the signed headers; the vendor identifies it as mandatory. Do not discard other approved signed headers unnecessarily.
- Select the intended published public key.
- Select Save (保存).
The current official images distinguish a published row from an unpublished row and show the separate selection and Save controls. Publication is therefore not a substitute for activation. If the key is published but signing remains absent after Save, investigate the selected key, actual route and exact contracted-domain condition.
DKIM canonicalization options named SIMPLE and RELAXED describe how selected message content is normalized for signing. They are not DMARC's adkim or aspf domain-alignment modes. Do not weaken DMARC policy when choosing a signing canonicalization setting.
Preserve DMARC and approved reporting
Inspect the visible From domain's direct and applicable inherited DMARC policy. A missing child TXT does not establish an absence of protection. Preserve existing enforcement, alignment modes and report recipients unless the owner approves a specific change. Do not replace an established policy with a generic monitoring example or immediately enforce reject just because DNS publication succeeded. Current DMARC requirements
If there is no applicable policy, arrange a separate owner-approved initial monitoring rollout with the correct DNS owner. _dmarc.example.com maps to _dmarc in the example.com zone. An explicitly approved child policy at _dmarc.news.example.com maps to _dmarc.news in the parent zone or _dmarc in a separately delegated child zone. Review all legitimate senders before proposing stronger enforcement.
Aggregate-report rua addresses receive authentication reports, not forwarded quarantined message bodies. Compare the Organizational Domain of the report URI destination host with the Organizational Domain of the domain where the policy was found, including an inherited policy. When those Organizational Domains differ, the report-generating receiver checks DNS authorization for the external reporting destination; the same-Organizational-Domain exception uses that policy-found domain. Protocol authorization does not replace approval to share report data. RFC 9990 section 4
Do not add failure reporting, obsolete percentage tags or unapproved recipients as incidental steps in a DKIM deployment. None is needed to prove that the intended signer is working.
Verify the intended signature on a native message
After saving activation, an authorized operator should send harmless test content through the existing CYBERMAIL Sigma mailbox route to a controlled receiving mailbox. Do not change a connector, create a real customer workflow or expose confidential messages just to obtain a sample. The reviewed source does not establish a special native “test authentication” button. Without an authorized safe message, record message acceptance as pending.
Use receiver-controlled diagnostic output, or have the receiving administrator identify which Authentication-Results were generated inside its trusted processing boundary and how externally supplied fields are removed or distinguished. A familiar authserv-id or header position alone is not proof. Receiver trust requirements
| Check | Required evidence |
|---|---|
| Actual route | Existing native CYBERMAIL Sigma mail through the intended MailGates path |
| Sender eligibility | Contracted domain, envelope domain and visible From meet the documented exact-match condition |
| Intended DKIM | The selected native signature passes using the expected actual selector |
| DKIM alignment | That same passing signature's d= aligns with approved From under effective adkim |
| DMARC | Trusted receiver reports pass for the actual From, with no unnoticed sender rewrite |
| SPF | Actual MAIL FROM evaluated independently, with errors resolved rather than hidden by DKIM success |
Relaxed DKIM alignment compares Organizational Domains; strict alignment requires exact equality. SPF alignment compares MAIL FROM with From under the separate aspf mode. A child envelope does not automatically meet strict alignment with its parent From. These protocol checks do not remove the vendor's additional signer-eligibility requirement.
A DMARC pass supplied only by SPF cannot validate this DKIM deployment, nor can a passing unrelated gateway signature. Retain sanitized results, identities, selector and timestamp. See raw DKIM results versus aligned policy results.
Troubleshooting
The key stays Unpublished
Check the actual authoritative zone, full owner, version prefix, complete public key and TXT representation. Look for doubled domain suffixes, conflicting CNAMEs or multiple key records. Reopen the key screen after DNS is correct; do not enable an unpublished key or repeatedly regenerate it.
Published is shown but the message has no intended signature
Check Enabled, the selected published key and Save, then the exact contracted/Envelope From/Header From relationship. Confirm that the message actually passed through the scoped native route. The linked detailed caution page was not publicly readable during research; obtain provider guidance rather than assuming undocumented exceptions.
SPF fails even though DMARC passes
Inspect the actual smtp.mailfrom. Fail or softfail calls for checking authorization; temperror indicates transient evaluation trouble such as DNS availability; permerror calls for checking syntax, duplicate policies and lookup limits. Investigate these even when aligned DKIM supplies DMARC pass. A passing but unaligned provider envelope is a different outcome from an SPF error.
The interface differs or Mail Security is absent
Stop and confirm the product and provisioning arrangement. Some other CyberSolutions deployments are preconfigured, while on-premises versions have distinct instructions. Do not expand account privileges, upload a private key or modify inbound authentication to imitate the screenshots.
Another sender fails after an update
Compare the before-and-after SPF and selector records. Coordinate a bounded restoration after checking intervening edits. Do not restore an entire old zone or delete all keys, which could disrupt unrelated services.