OpenSRS SPF, DKIM and DMARC setup, step by step

For OpenSRS Hosted Email, the documented SPF authorization is include:_spf.hostedemail.com. DKIM uses a key pair and selector created by your authorized administrator: publish the public key as a DNS TXT record, then enter only the selector and the matching private key in the domain's DKIM section of the Mail Administration Console (MAC) and select Update.

These are separate steps. Publishing a public key does not make the platform sign with it, and a DNS lookup does not prove the private key matches or that a delivered message is aligned. Keep private-key handling restricted to the authorized operator, approved tools and secure storage. No private key belongs in DNS, an article, a support attachment or a public checker. Official DKIM setup

Scope: hosted mail, not registrar notifications

This guide covers outbound messages from mailboxes on the OpenSRS email platform. OpenSRS's SPF page says Hosted Email can send through Cluster A or Cluster B and directs customers to the same _spf.hostedemail.com include for both.

Registrar notices are a different source. OpenSRS separately documents include:registrarmail.net for messages to registrants using the reseller's technical-contact From address. Do not substitute that include for Hosted Email, or add both just because they share the OpenSRS brand. This is also not a generic Tucows, Hover, Enom or external-SMTP setup guide. Hosted email versus registrant notices

Before starting, identify:

• The hosted-email domain, actual mailbox sending route and cluster serving the account.
• An authorized MAC administrator who can edit that domain's settings. The MAC exposes different capabilities by administrator level; mailbox-only and read-only access are not equivalent to domain administration. Do not grant broad company permissions merely to complete this task. MAC access and administrator levels
• The authoritative DNS operator, which may be OpenSRS SystemDNS or an external DNS provider.
• Existing SPF, DKIM selectors, DMARC policies and DNS delegations, plus other senders sharing the domain.
• An approved key-generation/storage process and the domain owner's key-strength policy.
• A controlled receiving mailbox for a later native-route test.

The reviewed instructions do not establish a special paid-plan or regional entitlement for DKIM. Confirm domain access and actual account applicability rather than assuming that any reseller or mailbox login can change signing.

1. Resolve the SystemDNS key-size limitation first

OpenSRS's current DKIM instructions expressly say: if you use SystemDNS nameservers, generate a 1024-bit key, not a 2048-bit key. Do not silently reinterpret that as documented 2048-bit support or truncate a larger key to make it fit. Provider's SystemDNS note

There is a security distinction to resolve before provisioning a new key. For RSA DKIM, RFC 8301 requires at least 1024 bits and recommends at least 2048 bits. It does not categorically prohibit a 1024-bit key, but meeting the minimum is different from meeting the recommendation or your organization's security requirements. RSA signing must use SHA-256, not the retired SHA-1 algorithm. RFC 8301 §§3.1–3.2

If your domain uses SystemDNS, stop and discuss a supported 2048-bit-capable configuration with OpenSRS and the DNS/security owners before treating a new deployment as approved. If the documented 1024-bit limitation remains, the security owner must explicitly decide whether that exception is acceptable; if policy requires 2048 bits, do not proceed with a smaller key. Changing nameservers, transferring a domain or replacing a working key is not an implied solution or an authorized side effect.

For externally hosted DNS, confirm that both the DNS editor and the actual OpenSRS configuration accept the intended key size and format. The SystemDNS-specific warning does not establish a universal MAC limit, nor does it prove every other provider supports your proposed key. Resolve uncertainty with OpenSRS before generating or installing production credentials.

2. Create and protect the matching key pair

OpenSRS's procedure asks you to generate a public key, private key and selector. Its documentation names a third-party web generator as an example, not an obligation to entrust production signing credentials to that service.

Have the authorized operator use an approved secure key-generation process, preferably one that keeps private material within the organization's controlled environment. Do not upload an existing private key to a generator or checker. If an external service would receive or retain private material, that requires a separate explicit security decision, not automatic consent from this tutorial.

Choose a selector that does not collide with an existing sender and record the intended signing domain. The provider's dkim1 example is illustrative; it is not an account-issued mandatory selector. Save the complete outputs in the approved locations:

OpenSRS warns that after saving, the private key is obfuscated and cannot be recovered from the platform. Keep an authorized secure copy before installation. Do not rely on the MAC to return it later for rollback. If the generated format is uncertain, ask OpenSRS for format guidance without sending the private key. Key generation, installation and recovery warning

For an existing signed domain, plan the change with its owner. Do not regenerate keys as a casual troubleshooting step or overwrite a selector without checking queued mail and rollback dependencies. The reviewed MAC page does not promise simultaneous use of multiple private keys or an automatic rotation-overlap mechanism.

3. Add the correct Hosted Email SPF authorization

The documented include mechanism is:

include:_spf.hostedemail.com

OpenSRS supplies this minimal full policy:

v=spf1 include:_spf.hostedemail.com ~all

Use that full example only when there is no existing SPF policy at the intended owner and the domain owner has confirmed that it authorizes all legitimate senders for that identity. For a multi-service domain, incorporate the Hosted Email mechanism into the existing approved policy instead of replacing other authorizations or creating a second v=spf1 record. Official Hosted Email SPF instructions

SystemDNS publication path

If the domain actually uses OpenSRS systemdns.com nameservers, the official instructions are:

1. Open the Reseller Control Panel (RCP).
2. Search for the domain and select its name in the results.
3. In DNS, select Edit.
4. Select TXT from the add-record dropdown.
5. Enter the approved single SPF policy at the root of the domain, as specified by the provider.
6. Select Save DNS settings and inspect the resulting DNS data.

When an SPF policy already exists, edit that policy deliberately rather than using the add-record flow to create a duplicate. The provider's minimal example does not override this one-policy requirement.

If another provider is authoritative, use its DNS editor instead; the RCP's stored records cannot affect a zone it does not serve. For a subdomain mailbox identity, establish the actual evaluated owner with your mail administrator rather than assuming a parent policy is inherited.

SPF identity and policy checks

SPF checks SMTP MAIL FROM, normally represented by the Return-Path after delivery, and HELO in relevant cases. It does not authenticate the visible From address or Reply-To. Confirm the actual envelope identity on the native-route message later in this guide.

At each evaluated owner:

• Publish one complete SPF policy, preserving legitimate services and the existing deliberate qualifier.
• Place an added include before a terminal all. Do not append a second v=spf1 string.
• If the policy uses redirect, review its design: an all mechanism makes redirect ineffective.
• Check the ten evaluated DNS-dependent-term budget, including nested include, a, mx, ptr, exists and redirect terms. This is not merely a count of top-level includes.
• Do not replace the maintained include with a one-time snapshot of provider IPs. The primary lists distinct regular, forwarding/autoresponder and migration traffic; those tables are not a reason to authorize unrelated traffic indiscriminately.

The sample ~all produces softfail for unmatched senders, not a guaranteed inbox or rejection decision. Do not automatically change a working -all or ?all merely to match an example. SPF specification

4. Publish the public DKIM record at the correct owner

The standard owner is the chosen selector followed by ._domainkey. and the signing domain. For example, a hypothetical selector SELECTOR for mail.example.com produces:

SELECTOR._domainkey.mail.example.com

This is a structural placeholder, not a key or an OpenSRS default. Publish a TXT record containing the complete public DKIM record from the approved generation process. Never paste a private key or a raw private-key PEM block into DNS. Keep the public record's tags, public-key data and punctuation intact. OpenSRS public-key publication

If the DNS editor expects a full name, enter the complete owner instead. Use its documented trailing-dot and quoting conventions and inspect the saved full owner to catch a duplicated suffix. Preserve existing NS delegations and work with their operator, not by deleting a delegation and placing an ineffective record in the parent zone.

A TXT record cannot coexist at an owner already occupied by a CNAME. If the selected owner is in use, do not overwrite another service or introduce a second incompatible key. Choose an approved unused selector and keep DNS and MAC in agreement, or coordinate a supported replacement.

A long TXT value may be represented as multiple quoted character strings within one logical record. They must reconstruct the complete intended value, without inserted spaces or omitted characters. This general TXT representation rule is not evidence that SystemDNS supports a larger key than its documented limitation. If the editor rejects the required data, stop for support rather than splitting it into multiple independent records or shortening the key.

This documented route uses TXT, not an issued DKIM CNAME. No web-proxy or CNAME-flattening change is required merely to publish these TXT records. Do not alter shared DNS settings, MX, DNSSEC or nameservers as part of this procedure.

5. Install the selector and private key in the MAC

First verify that the correct public record is available at the actual authoritative owner. Then the authorized operator completes the documented signing configuration:

1. Sign in to the MAC for the account's correct email cluster. The MAC guide describes cluster-specific access and administrator capabilities; use your established account access rather than guessing another cluster.
2. Search for the domain in the top-left search field and open its overview page.
3. Expand DKIM.
4. In Selector, enter only the selector label, not the domain or full SELECTOR._domainkey... owner.
5. In Key, enter the matching private key from approved secure storage. Do not paste the public TXT value into this field.
6. Select Update at the bottom of the page. Check the application response for a successful save or an error before proceeding.

The page documents Update as the installation step; it does not establish a separate universal “Verify,” “Enable signing” or green-status button. The private key is obfuscated after saving, so its visual appearance is not proof that the correct key is installed. The MAC also has a documented five-minute idle timeout; if the session expired, re-establish authorized access and determine whether the change saved before repeating it. DKIM installation

Do not share the private key to demonstrate completion. Retain a private change record of the domain, selector, public-key fingerprint or equivalent approved identifier, operator and time. The decisive signing check is a newly received native-route message.

6. Preserve DMARC and map a first policy safely

Review the direct DMARC policy for the actual visible From domain and any applicable inherited policy. Preserve existing protection, adkim/aspf settings and authorized reporting. Do not replace p=quarantine or p=reject with a tutorial's monitoring example, or create a weaker child policy to evade inherited protection.

Only when no direct or applicable inherited policy exists, the domain owner approves a first monitoring policy and a suitable monitoring plan is in place, this is a minimal TXT value:

v=DMARC1; p=none

Use the full owner if the editor requires it. Maintain one applicable DMARC policy at that owner. This minimal value does not request aggregate reports; add rua only for a real authorized destination and an approved reporting plan.

If the reporting destination belongs to a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination in that same Organizational Domain is excepted; different hostnames alone do not make it external. Protocol authorization is separate from the domain owner's privacy and data-sharing approval. RFC 9990 §4

DMARC passes through either passing aligned SPF or passing aligned DKIM. Strict alignment requires exact domain equality for the relevant authenticated identity; relaxed alignment uses the appropriate Organizational Domain relationship. A child envelope domain is not automatically a strict SPF match to a parent From domain. Do not assume a universal OpenSRS Return-Path, signing domain or strict-alignment outcome before inspecting the message. Current DMARC standard

7. Verify DNS, then test a real hosted-mail path

Use read-only lookups of the actual records. Replace uppercase placeholders with your own confirmed names and approved DNS server:

dig @AUTHORITATIVE_NS TXT SPF_OWNER +noall +answer
dig @AUTHORITATIVE_NS TXT SELECTOR._domainkey.SIGNING_DOMAIN +noall +answer
dig @RECURSIVE_RESOLVER TXT SELECTOR._domainkey.SIGNING_DOMAIN +noall +answer
dig @RECURSIVE_RESOLVER TXT _dmarc.FROM_DOMAIN +noall +answer

Compare complete public TXT data with the intended record, including concatenated strings where applicable. Confirm the authoritative zone, correct selector and exactly one SPF policy at its owner. Empty answers, malformed records, NXDOMAIN and SERVFAIL are not passes. Cached data can differ from an updated authoritative answer; use the actual TTL/change plan rather than inventing an activation deadline.

OpenSRS recommends a DKIM lookup as a test. Such a lookup can show a public key resolves, but cannot by itself prove that the MAC has the matching private key or that the platform used it to sign this message. Never provide a private key to a public lookup service.

After the authorized operator has saved the MAC configuration, send a harmless message from the actual OpenSRS hosted mailbox through the intended native route to a controlled valid recipient. A message sent from another mailbox provider, a registrar notice or an unrelated external SMTP route is not a substitute. For forwarding, autoresponders or other materially different paths you use, arrange separate controlled tests; do not deliberately target nonexistent addresses or change production rules to manufacture results.

In the receiving service, inspect the raw message or its trusted administrative diagnostics. Use results produced inside that service's known receiving boundary, with its documented treatment of externally supplied Authentication-Results. Header position and a familiar authserv-id string alone do not establish trust. Ignore attacker-supplied results. RFC 8601

Require:

• The intended visible From is unchanged, not rewritten to an unrelated provider identity.
• The intended OpenSRS DKIM signature reports dkim=pass, with the expected selector s= and signing domain d=. Check the signing algorithm and key against the approved configuration.
• That passing signature aligns with the intended From under the applicable adkim mode.
• The trusted receiver reports dmarc=pass for the intended From. SPF-only DMARC success does not close the DKIM installation task.
• The actual envelope identity and SPF result are retained separately. Diagnose SPF fail, temperror and permerror even when aligned DKIM supplied the DMARC pass.

EmailAuth's raw DKIM results versus aligned DKIM policy results explains why another passing signature is not necessarily the intended aligned one. Record the route, domain, selector, DNS revision, MAC save and received-message evidence without exposing private material. One passing message supports that tested route, not every mailbox or destination; authentication does not guarantee inbox placement.

Troubleshooting and rollback

For a failed change, pause the affected sending path where appropriate and coordinate with the mailbox, DNS and security owners. Restore only an approved last-known-good configuration with a known matching key pair. Retain public selectors while queued mail or rollback still depends on them; do not delete unrelated keys or shared delegations. If a private key may have been exposed, involve the security owner and OpenSRS in replacement and retirement rather than reusing it because authentication happens to pass.

No rollback should alter inbound MX, broaden SMTP trust, disable filtering or weaken domain-wide DMARC without a separate authorized decision. Retest DNS, the MAC configuration and a fresh native-route message after repair.

Sources and documentary check

The inspected primary pages did not expose a reliable article publication/update date in their body or structured article-date fields; this check date is not a vendor update date. The authentication procedures are established by complete prose, not uninspected screenshots.

• OpenSRS Setting Up DKIM for Hosted Email Domains: key generation, SystemDNS limitation, DNS publication, MAC Selector/Key/Update and irreversible key obfuscation.
• OpenSRS Set Up SPF Records for OpenSRS Hosted Email: maintained include, SystemDNS publication path and separate registrar-notice authorization.
• OpenSRS Mail Administration Console: cluster-specific access, administrator capabilities and idle timeout.
• RFC 8301: RSA algorithm and key-size requirements, read alongside the provider's specific SystemDNS limitation.

No key pair was generated, no private material was accessed, and no customer login, DNS edit, MAC update, email send, live delivery test or publication was performed for this guide.