Sakura Internet SPF, DKIM and DMARC setup, step by step

For Sakura Rental Server email, use the account’s assigned server hostname in its SPF policy, configure DKIM for the selected mail domain in Server Control Panel, and publish the public key at the actual DNS authority. Sakura DNS can publish through the DKIM record checkbox; external DNS requires a manual TXT record. Saving a generated key, publishing DNS and proving a signed message are separate checks. Sakura DKIM procedure; Sakura SPF procedure.

This guide covers native custom-domain email on the overlapping documented Lite, Standard, Premium, Business, Business Pro, Managed Server and Mailbox services. It supports Sakura’s nameservers or external authoritative DNS. It does not configure Sakura VPS/Cloud, a self-managed mail server or an unrelated third-party sender. Although the DKIM page also lists Business Mail, that separate product is not assumed to use the Rental Server SPF-host workflow covered here.

No customer login, DNS publication or live message test was performed.

Confirm the domain, login and actual sending route

Sign in to Server Control Panel using the service’s initial domain or an added domain, not an email-address login. Sakura says an email-address login hides the domain settings needed for this task. Obtain appropriately authorized service and DNS access rather than changing credentials or creating a broader account. Sakura login prerequisite.

Identify the configured mail domain and the approved From addresses. Sakura explicitly lists these DKIM-capable native sending routes:

• An email client authenticated with SMTP AUTH.
• Sakura webmail.
• Programs using the service’s sendmail command.
• Mail sent from the server through localhost:25.

A PHP or CGI program that connects directly to the recipient’s mail server without using sendmail is explicitly outside that signing behavior. Hosting an application at Sakura does not prove that it uses a supported route. Identify the application’s actual transport before altering its DNS. This guide does not authorize changing server software or rerouting an application. Supported signing paths.

Record the sending routes, mailbox/application owners, existing SPF, selectors, DNS delegations and DMARC policies. If another source uses Microsoft 365, authenticate that separately using the Microsoft 365 SPF and DKIM guide.

Sakura’s DKIM procedure distinguishes its nameservers, NS1.DNS.NE.JP and NS2.DNS.NE.JP, from external DNS. Confirm the actual authority, including any delegated namespace. Do not move nameservers merely to use an automatic checkbox.

Obtain the assigned SPF hostname and preserve other senders

Sakura documents this SPF shape:

v=spf1 a:www*.sakura.ne.jp mx ~all

The asterisks are a placeholder, not a value to publish. Obtain the service’s actual server hostname from Server information → Server information in Server Control Panel. Use the complete assigned host in the a: mechanism. Do not substitute the website’s domain, another customer’s host or a hostname remembered from a different server. Server-information lookup; SPF template and host instructions.

The a: mechanism authorizes addresses resolved for that server hostname. The mx mechanism authorizes addresses of the SPF domain’s MX hosts. Compare both with the actual approved outbound sources; an inbound mail service is not automatically an intended outbound sender. Do not change A/AAAA or MX routing to make an example policy fit.

SPF evaluates the SMTP MAIL FROM domain, often represented in the received Return-Path, not automatically the visible From address. A null reverse-path involves HELO handling. Inspect the actual receiver-reported smtp.mailfrom identity. The sources do not establish one universal envelope domain for all mailbox, sendmail and localhost routes. SPF identity selection.

At the evaluated owner, keep one TXT record beginning v=spf1. If other authorized services already use it, merge the necessary mechanisms into the existing policy instead of adding a second complete policy. Preserve its deliberate qualifier. Sakura’s ~all means softfail for an unmatched source; it is not a guarantee of acceptance or inbox placement.

Do not append all to a policy using redirect= without redesigning the policy: the all mechanism makes that redirect ineffective. Evaluate the full DNS lookup tree against the limit of ten evaluated DNS-query-causing terms, including nested processing, rather than counting only visible includes. a and mx also count, with further lookup constraints. SPF limits; redirect processing.

Publish SPF with Sakura DNS

Sakura documents Domain/SSL → Domain/SSL → selected domain’s Settings → Mail domain settings. Select Use for the SPF record and choose Save (保存する). Review the existing policy and approved changes before using an automatic setting. Do not change the neighboring mail-delivery scope, DKIM or DMARC controls merely because they appear in the same screen. SPF setting and save step.

To inspect Sakura-hosted DNS, the same article gives Member Menu → Contract information → Contracted domains → Domain Control Panel → selected domain’s Zone. Check the complete published TXT rather than treating the checkbox as proof. If the generated policy would remove another legitimate sender, reconcile the required single policy before applying it; the source warns that manually combined configurations require operator validation.

Publish SPF with external DNS

Use the external provider’s TXT editor at the actual envelope-domain owner, with the assigned Sakura hostname and approved sender inventory. The Sakura checkbox does not publish to another provider’s nameservers. A policy at example.com does not automatically apply to an envelope domain such as news.example.com; that owner needs its own applicable policy.

Configure DKIM for the selected mail domain

First inspect an existing working configuration. Do not create a new key simply to follow a tutorial again.

For a new approved setup:

1. In Server Control Panel, open Mail → Mail domains. On Business and higher services, Sakura labels the menu User/Mail.
2. Find the intended domain and choose Settings → DKIM settings (DKIM設定).
3. Select Create a new private key (秘密鍵を新規作成する) within Sakura’s interface. The provider generates the signing material; you do not need to create or upload a key yourself.
4. Keep the displayed selector unless a deliberate, coordinated selector change is required. Do not copy the example selector from a screenshot.
5. Follow the correct DNS branch below, then choose Set (設定する) to save the configuration.

The domain list displays SPF and DKIM/ARC status indicators. They are configuration evidence, not proof of a received-message pass. Sakura domain selection, generation and save steps.

Sakura-authoritative DNS

Select Use for DKIM record before saving. Sakura documents that this publishes the corresponding DKIM record in its DNS. If this checkbox is left unchecked, saving creates the key material but does not register the DKIM DNS record. That is not completed publication.

The DMARC record checkbox is separate. Do not turn it on automatically, replace an existing policy, or alter an already configured reporting choice as a side effect of DKIM. A new DKIM setup can be handled separately from a new DMARC policy. The reporting-dashboard option has an additional privacy consequence explained below.

External authoritative DNS

Sakura also documents external DNS. In that branch, select Use for DKIM record, then choose Set (設定する) to save, as the provider’s external-DNS procedure specifies. Next inspect the displayed domain, selector and public key, and publish the corresponding TXT record at your actual DNS provider. The checkbox does not publish to external nameservers; that manual TXT step remains necessary. It does not require enabling the separate DMARC record option.

The full owner has this structure:

SELECTOR._domainkey.SIGNING-DOMAIN

Replace both uppercase placeholders with the current configuration. The TXT value has this structure:

v=DKIM1; k=rsa; p=PUBLIC-KEY-BASE64

Replace the entire PUBLIC-KEY-BASE64 placeholder with the generated public key’s base64 content. Sakura’s current screenshot shows that public key in PEM format, beginning with -----BEGIN PUBLIC KEY-----. For p=, use only the complete base64 payload between the public-key delimiters, without those BEGIN/END lines or display line breaks. Keep every base64 character, including any ending padding. Do not put the PEM block itself, the private key or the screenshot’s sample key into DNS. Sakura public-key display and external TXT format; DKIM public-key data format.

This is a representation change for the issued public key, not generation of a different key. If you cannot confidently match the displayed public key to the TXT value, stop and have the DNS administrator or Sakura confirm it. Do not use the nearby private-key download, key-upload or Delete controls as troubleshooting shortcuts.

Map owners at the actual DNS authority

Avoid double-appending a domain in an editor that uses relative names. These examples explain placement, not additional domains or selectors to configure:

• For signing domain example.com, the full DKIM owner is SELECTOR._domainkey.example.com. In its relative-name zone editor, use SELECTOR._domainkey.
• For an actually configured signing domain news.example.com, the full owner is SELECTOR._domainkey.news.example.com. In the parent zone use SELECTOR._domainkey.news; in a separately delegated news.example.com zone use SELECTOR._domainkey.
• If _domainkey.example.com is delegated, the selector’s relative owner inside that authoritative zone is SELECTOR. The same applies within _domainkey.news.example.com for that signing domain. Preserve existing NS delegation and coordinate publication through the delegated authority; do not delete it or create an ineffective parent-zone copy.
• For SPF, example.com is the full apex owner. An actual envelope domain news.example.com uses relative news in the parent zone or the apex of its delegated child zone. Follow the editor’s full-name, blank or @ convention.

Preserve other selectors and unrelated TXT records. Resolve a collision with an existing CNAME or another service’s key before adding the new TXT. Do not publish several independent public-key records at one selector. This native route uses TXT, so HTTP proxy and CNAME-flattening settings are not part of its setup. DKIM selector lookup.

Keep DMARC and the report dashboard separate

Inspect the From domain’s direct and applicable inherited DMARC policy before changing anything. Preserve existing protection, an existing p=none, alignment settings and authorized recipients. Do not add a weaker child policy or adopt the source’s suggestion to choose quarantine when unsure.

Only if no applicable direct or inherited policy exists, and the domain owner approves a first policy with a monitoring and review plan, a minimal first TXT value is:

v=DMARC1; p=none

For From domain example.com, use full owner _dmarc.example.com, relative _dmarc in that zone. For news.example.com, use full owner _dmarc.news.example.com, relative _dmarc.news in the parent zone or _dmarc in the delegated child zone. Publish one policy. This minimal value requests no enforcement or aggregate reports; add a real rua destination only after approving and configuring it. Current policy discovery rules.

Sakura’s DMARC report-dashboard option is a separate data-sharing choice. The provider says enabling it adds a dedicated aggregation address, reports also go there, and the user cannot view that address. Do not enable the checkbox just to complete DKIM. Obtain the owner’s approval for the provider’s report processing, access and retention before using it. The source also says this dashboard function is unavailable with external nameservers. Sakura report-feature behavior.

For any report destination, compare its Organizational Domain with the Organizational Domain where the DMARC policy was found. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. Have the report receiver establish the necessary authorization. This protocol check does not replace the owner’s privacy/data-sharing approval. RFC 9990 section 4.

A domain-wide move to enforcement needs a separate review of all legitimate and indirect mail. RFC 9989 requires domains publishing p=reject to apply valid DKIM signatures rather than rely only on SPF, and warns about forwarding and mailing-list interoperability. Do not downgrade an existing policy for a test or tighten it based on one successful mailbox message. Interoperability requirements.

Verify publication and the exact sending paths

After saving, inspect the configuration and authoritative DNS, then a recursive resolver. Replace the fictional names, server and selector in these read-only examples:

dig NS example.com
dig @ns1.example.net TXT example.com
dig @ns1.example.net TXT SELECTOR._domainkey.example.com
dig TXT example.com
dig TXT SELECTOR._domainkey.example.com
dig TXT _dmarc.example.com

Query the correct authority for any delegated owner. Compare the complete SPF policy and DKIM public value with the approved configuration. Multiple quoted strings in one TXT resource record are joined for interpretation; they are not automatically several separate records. Allow the previous TTL and cached answers to expire, but do not treat a waiting period as proof that a missing or malformed record is correct.

Then send new messages through each actually used, supported route, using harmless synthetic content and controlled, valid external test mailboxes. Test webmail and SMTP AUTH separately where both are used. For a sendmail or localhost application, use an approved synthetic test in that application’s actual route, without charging an order, changing a real customer’s account or sending to a customer audience. Do not assume a mailbox pass covers a script.

At the recipient, inspect the original raw message and use Authentication-Results produced inside the receiving service’s known processing boundary, with its documented treatment of external result fields. Ask the receiving administrator when that boundary is unclear. A matching authserv-id string or a header’s position alone is not trustworthy evidence; ignore attacker-inserted results. Receiver-result security.

Record the unchanged approved From, connecting IP, actual smtp.mailfrom, SPF result, intended DKIM d= and s=, signature result and DMARC result. Match the actual selector and signing domain to the saved Sakura configuration.

Acceptance requires the intended Sakura signature to pass DKIM and align with the intended branded From, plus trusted dmarc=pass. An unrelated passing signature, provider-rewritten From or DMARC passing through SPF alone is not proof of this DKIM setup.

Under relaxed alignment, the authenticated identity and From can share an Organizational Domain. Strict alignment requires identical domains for the mechanism involved: DKIM d= under adkim, and the SPF-authenticated envelope under aspf. Do not promise strict alignment from a child identity or infer a universal Return-Path. DMARC alignment.

Sakura says ARC is enabled automatically with DKIM and is not separately configurable. It also documents no ARC signature for internal delivery to addresses on the same server. ARC is not a substitute for checking the intended original DKIM signature, and an ARC-related result does not by itself prove your branded DMARC acceptance. Sakura ARC scope.

Troubleshoot and recover safely

Domain controls are missing: check that you used initial-domain or added-domain login, not an email-address login. Confirm the eligible service and permissions without broadening access by assumption.

The key was generated but DNS is empty: distinguish the DKIM record checkbox from key generation. With external DNS, publish there manually; a Sakura checkbox cannot write to another provider. Preserve any existing delegated authority.

The DKIM record cannot be parsed: confirm the exact selector/domain, complete tagged TXT value and base64 payload. Remove PEM delimiters and display line breaks from p=, not key characters. Do not confuse a private-key download with the public DNS key.

Mailbox DKIM works but application mail does not: inspect SMTP AUTH, sendmail, localhost or direct-recipient transport. Sakura explicitly excludes direct PHP/CGI sends that bypass sendmail. Resolve the application route with its owner; do not change DNS blindly or claim every hosted script is signed.

SPF fail or softfail: inspect the actual envelope owner, connecting source and assigned server-host authorization, including the intended MX sources. None or neutral: check the evaluated owner and policy; these are not passes. Permerror: check duplicate policies, syntax and nested term-budget exhaustion. Temperror: check DNS availability and resolution, then retest before rewriting a correct policy. Diagnose SPF independently even when aligned DKIM already passes DMARC.

DMARC fails despite an authentication pass: compare the passing identities with the unchanged From and effective alignment mode. More SPF mechanisms cannot repair an unrelated signing domain. Do not weaken policy to hide the discrepancy.

Before rollout, agree with the mailbox/application and DNS owners who may pause affected sending, restore exact approved prior records, or coordinate account-side recovery. Preserve concurrent DNS changes, other selectors, shared dependencies and keys needed by queued mail. A new provider key, a changed selector or the Delete control can disrupt old messages and dependent routes; coordinate replacement and retirement rather than toggling or regenerating indiscriminately.

Retest after restoration, server migration, domain changes, DNS changes, route changes or key rotation. Keep original/final DNS, the issued public key and selector, saved account state, controlled message evidence and unresolved exceptions together.

Sources and verification limits

The primary sources are Sakura’s DKIM/ARC/DMARC procedure, SPF procedure and server-information guide. Nine linked setup, status, public-key and SPF images were inspected. These bodies did not establish article publication/update dates; unrelated news-banner dates were not treated as article dates.

A linked FAQ returned a loading/CSS-error shell and was not substantive evidence. The instructions above are based on the complete main procedures and their actual images. Customer records, eligibility, configuration, message headers and production outcomes remain untested.