Establish whether Openprovider serves the active zone
This guide concerns publishing authentication records in Openprovider DNS. It is not a configuration guide for Openprovider's separate mailbox or forwarding products. Your domain can be registered in Openprovider while Microsoft 365, a campaign service or another provider sends its mail. The sender supplies its authentication instructions; the authoritative DNS operator publishes the approved records. Keep those roles separate when assigning the work.
Openprovider supports its own nameservers and external nameservers. Its nameserver guide explains that externally hosted zones must be configured at the external DNS provider, while Openprovider-hosted zones are managed through DNS Management and DNS zones overview. Start with the actual public delegation and the exact zone under change. A registered domain and a zone visible in the account are not enough to establish authority. Openprovider nameserver guidance
Do not change nameservers merely to make an SPF editor available. That is a separate migration that can affect the website, inbound mail, validation tokens and DNSSEC. If an external provider is authoritative, hand the approved record changes to that provider's administrator. If Openprovider is authoritative, confirm you are editing the live zone rather than a template intended for future use.
Assemble the record changes from the sending service
Request the current sender-issued SPF authorization, DKIM owners and values, any custom-envelope instructions, and the precise domain to which each applies. Avoid a universal record called an Openprovider SPF setting: a DNS host does not become an authorized mail sender simply by hosting the zone. The same distinction applies to DKIM. Openprovider's DKIM article says the sending mail server determines the record content and the provider or system engineer supplies it. Openprovider DKIM publication
Export or otherwise preserve the complete affected record sets, including owner names, types, TTLs and values. Keep unrelated TXT tokens intact. Record each proposed action as add, replace or retire, with its service owner and reason. A selector that appears old may still validate queued mail or support another application. A new service's instruction does not authorize deletion of the old service's key.
Separate the fully qualified intended owner from the editor input. For DKIM, the selector and _domainkey labels are essential; they are not interchangeable with the domain apex. For DMARC, identify the applicable _dmarc owner. For SPF, identify the actual SMTP envelope domain. The retrieved DNS Records guide does not establish a current universal apex-entry convention. Confirm the current interface handling of the root owner and appended suffixes before saving; do not assume a blank field or @ is accepted in every input mode. Openprovider DNS record conventions
Publish SPF as one policy with verified TXT formatting
Openprovider's SPF guide uses TXT records and specifically instructs its users to wrap the content in straight quotation marks. Follow the current editor's documented input convention, then inspect the published TXT answer to verify that formatting was interpreted correctly. Curly quotation marks copied from a word processor are not equivalent. Do not repeatedly add quotation layers when a resolver already displays strings with quotes. Openprovider SPF publication
Protocol semantics are the acceptance criterion. There should be one candidate SPF policy at the evaluated owner. A TXT record may contain multiple character strings that are joined for SPF processing, so a display split is not necessarily multiple policies. Conversely, two separate records beginning with the SPF version marker are not a valid way to accommodate two senders. Preserve required spaces and the complete mechanism sequence in the reconstructed value. SPF RFC 7208
The provider's general SPF article contains simplified language about TXT length, while its DNS Records guide explicitly describes splitting a large TXT value into smaller strings within one record. The character-string limit must not be treated as a total record limit. Confirm the current editor's handling and verify the reconstructed answer. Openprovider TXT record guidance If a long value is rejected, obtain provider guidance; do not shorten a public key or split an SPF policy into independent records.
Evaluate SPF's recursive lookup limits before saving a merged policy. A visually short policy can still exceed the limit through included policies. Do not replace provider-maintained mechanisms with a snapshot of today's IP addresses unless that maintenance model is deliberately approved and supported. Static flattening changes who must track future infrastructure changes.
Keep DKIM record types and selector ownership intact
Some sending services supply a TXT public key; others supply a CNAME alias. Publish the supplied type at the supplied selector owner. Do not put a CNAME target into a TXT field or publish the key at the apex. The receiver derives the lookup from the message's signing domain and selector, which is why a plausible-looking record at a different owner does not help. DKIM RFC 6376
Openprovider documents errors when a CNAME shares its owner with other ordinary record data. If the editor reports a duplicate or CNAME conflict, inspect that exact owner's full record set. Do not delete the conflicting TXT record before identifying the sender that owns it. Ask the new sender for a supported non-conflicting selector or plan a controlled rotation. The conflict is a trust-ownership question, not merely an input validation problem. Openprovider CNAME conflict guidance
A public key or delegation record does not cause the sending service to begin signing. Complete any sender-side activation separately and verify the signature on a real message. Never publish private keys, API credentials or SMTP passwords in the zone or worksheet.
Distinguish manual DMARC from hosted delegation
Openprovider's EasyDMARC integration describes two management paths: a hosted policy reached through a CNAME alias and a manually maintained TXT policy. It warns that the delegation target shown in an example is not the value to use; the control panel supplies the actual target. It also describes automatic CNAME creation in a qualifying purchase or activation flow using Openprovider nameservers. Therefore inspect the existing _dmarc owner before adding anything manually. Openprovider EasyDMARC management
Choose one approved management model. With a hosted delegation, the operational policy may change in the hosted service without a corresponding edit in the Openprovider zone. Assign an owner for that service and retain its approved policy settings. With manual TXT, changes must be reflected in the published value. Avoid leaving a TXT policy and a CNAME at the same owner, and do not replace existing reporting destinations merely to follow an integration wizard.
DMARC evaluates the visible From domain against passing aligned SPF or DKIM identities. Publication is one part of that process; it does not prove the domain's senders align. Keep receiver behavior distinct from requested policy and retain a domain-wide sender inventory before tightening enforcement. DMARC RFC 9989
Reusable Openprovider publishing worksheet
Create one row for each changed owner and retain a shared change record for the domain.
- Domain, authoritative nameservers and live zone identifier: ______.
- DNS administrator, sender administrator and change approver: ______.
- Sending service and its current configuration evidence: ______.
- Intended fully qualified owner and separate editor host input: ______.
- Record type, complete approved value and TTL: ______.
- Prior record set and dependencies that must survive: ______.
- SPF evaluated envelope owner and recursive policy check: ______.
- DKIM selector ownership, conflict review and sender activation: ______.
- DMARC manual TXT or hosted CNAME choice and policy owner: ______.
- Authoritative after-change answer and recursive comparison: ______.
- Received-message reference, From, envelope, signatures and trusted results: ______.
- Rollback steps, retest owner, visual check and human acceptance: pending.
Fictional diagnosis of a selector collision
This example is fictional. A reseller adds a new marketing service to a domain whose DNS is hosted by Openprovider. The new service requests a CNAME at a selector already holding a TXT key for an invoice sender. Openprovider rejects the change as a conflict. The reseller proposes removing the TXT because the new setup guide says the selector is required.
The safe investigation identifies the invoice sender and confirms that it still signs outgoing messages with that selector. The proposed recovery is to request a different supported selector from the marketing service or coordinate a verified key transition with both owners. It is not to delete the invoice key blindly. After an approved change, separate invoice and marketing messages would be tested. No actual zone, sender or successful test is represented by this scenario.
Close with DNS and message evidence
Query the exact owners at the authoritative nameservers after saving and preserve the responses. Compare a recursive answer separately, recognizing caching. Then have each affected sender produce a controlled message for an independent mailbox and record trusted receiver results. A DNS-only validator cannot confirm which selector the sender actually uses or whether its passing identity aligns.
If recovery is necessary, restore only the affected prior record set and repeat the relevant workflow tests. Preserve evidence of hosted-policy settings as well as DNS values, because the former can change independently. Current account access, interface screenshots, authoritative before-and-after captures, received-message evidence and human SME approval remain pending for this guide. No DNS edits or live tests were performed.
Keep public records separate from cryptographic operations
Publishing a public key does not encrypt the email body, create a signature or establish that the whole message is safe. Use the DKIM standard for signing semantics rather than the provider article’s simplified encryption explanation. Verify the actual signed content and receiver result after the sender operator completes activation.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.