Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Identify the hosted email product and outbound route
OVHcloud can supply a domain, DNS, hosted mail or a server without supplying all four. This guide covers its documented hosted-email products: MX Plan, Exchange, Email Pro and Zimbra. It does not prescribe authentication for an arbitrary VPS mail server, website script or third-party relay merely because the infrastructure or domain is at OVHcloud. That broader catalogue scope remains held until the intended route is confirmed.
Record the product, service identifier, mailbox, sender domain and authoritative DNS provider. Then identify how the test message is submitted. A web application using an external relay needs that relay's record prescription; the mailbox provider's DKIM controls may have no effect on it. Keep the mailbox product and the sending application separate in the inventory.
OVHcloud's current DKIM guide distinguishes product-specific control-panel and API routes, and warns that non-OVHcloud authoritative DNS must be updated at its actual provider. Domain registration at OVHcloud does not establish where the public answers are hosted. OVHcloud DKIM record configuration
Use the product-specific DKIM control
The documentation describes automatic configuration for the hosted offerings, with separate navigation for MX Plan, Exchange, Email Pro and Zimbra. Select the control belonging to the actual service rather than following screenshots for a different product. Obtain the generated selector records from that service. Where DNS is outside the relevant account or provider, the documented flow requires publishing the two supplied CNAME values before enabling. OVHcloud DKIM record configuration
Preserve the requested owner, type and target for both selectors. Do not copy the guide's sample service identifiers into production. A second selector may be part of the provider's lifecycle, so do not omit it because the current message uses only one. If the service state is changing, record that state and the last operation instead of creating duplicate requests.
For API-based administration, choose the product's documented endpoint family and read existing status before a write. Do not assume identical parameters across products. The API path, returned records and activation result belong in the change evidence. This manuscript performs no API call, grant of access or tenant change.
Publish the actual records and verify their owners
Find the authoritative nameservers and the zone containing each requested owner. If an OVHcloud DNS zone exists but is not delegated, editing it will not affect recipients. If DNS is hosted in another account, coordinate with that account's administrator rather than changing delegation to simplify a DKIM repair.
Inspect existing records for collisions. Use the DNS editor's expected relative owner or fully qualified name, ensuring the zone appears exactly once. Preserve target punctuation as appropriate for that interface and compare the final answer, not only the form entry. Never replace an unrelated working selector or inbound routing record without understanding its owner and impact.
After an approved publication, query the authoritative answers and then a recursive resolver. Record both selectors and the expected target for each. A green provider diagnostic is useful status evidence, but the acceptance test must still show signing on the real route. DKIM's d= and s= fields identify which public-key lookup the receiver needs. DKIM RFC 6376
Preserve all legitimate senders in SPF
OVHcloud's SPF guide identifies include:mx.ovh.com for shared MX Plan, Email Pro and Hosted Exchange. Private Exchange has a separate branch authorizing the actual server IP addresses; add the shared include only when that shared route is also used. Do not infer Zimbra's precise SPF prescription from the shared-offer list: confirm the current product-specific instructions. Use that authorization only when the confirmed route requires it. The provider's full example is not a universal replacement for a domain that also sends through marketing, billing or application platforms. OVHcloud SPF configuration
Evaluate the actual SMTP identity and collect the existing TXT answer before making a change. Maintain one v=spf1 policy for that owner. Retain justified authorizations, remove obsolete ones only with ownership evidence, and evaluate lookup limits. Avoid using broad mechanisms simply because a wizard offers them. An MX record tells the world where inbound mail goes; it is not proof that every listed inbound server should be authorized to send. SPF RFC 7208
DNS editors may label a helper form SPF, but current SPF policy is carried in TXT. Verify the published TXT answer and do not rely on a legacy record type alone. Do not overwrite DMARC policy or delete unrelated TXT verification records during cleanup. SPF RFC 7208
Read the receiver result before calling the route complete
Send a harmless controlled message from the selected mailbox through the production-equivalent submission path. Preserve the visible From domain, envelope domain, DKIM signing domain and selector, and the trusted receiver's Authentication-Results. Check DMARC alignment under the policy's mode. A signature existing in the header is not evidence that verification passed. DMARC RFC 9989 DKIM RFC 6376
Repeat the test for applications that use that mailbox service, if they are part of the approved scope. If an application uses its own relay, classify it separately rather than assuming the hosted mailbox test covers it. If only forwarded mail fails, compare the direct and forwarded paths before changing keys. Message modification and SPF's dependence on the connecting sender can explain different results.
Authentication is only one part of delivery. A spam-folder result does not automatically mean the CNAME is wrong; a passing DMARC result does not guarantee inbox placement. Preserve the receiver's actual result and avoid changing multiple controls at once when diagnosing a failure.
Hosted-email acceptance worksheet
This proposed worksheet must be completed with live evidence for each product and sender domain.
- Product and submission: MX Plan, Exchange, Email Pro or Zimbra; service identifier, mailbox, application and actual outbound relay.
- DNS branch: authoritative provider, account owner and whether automatic or manual publication applies.
- DKIM records: both returned selector owners and targets, previous records, public answers and provider status.
- SPF inventory: envelope domain, existing TXT policy, justified hosted-mail authorization, other senders and lookup assessment.
- Receiver test: message identifier, From, envelope domain, d=, s=, authentication outcomes and alignment decision.
- Recovery plan: previous configuration, approval owner, failed-test trigger and provider escalation evidence.
- Exclusions: VPS, website scripts and third-party relays not proven by this mailbox test.
Fictional diagnosis of a repaired inactive DNS zone
This example is fictional. A company activates DKIM for Email Pro and adds the requested selectors to an OVHcloud DNS zone. The diagnostic remains unresolved and external messages have no usable signature. The operator initially assumes the public key is defective.
The worksheet shows that the domain's nameservers point to a different DNS provider. The team publishes the exact Email Pro-issued records in the authoritative zone, checks both public answers and rechecks activation. A controlled mailbox message is then inspected for aligned authentication. The website's external mail relay remains a separate task; the mailbox repair does not certify it. No nameserver migration or root-policy replacement is needed merely to correct the publication location.
Keep scope and human review open
No hosted-mail account, DNS zone or received message was inspected for this article. The hosted-product scope, generated records, activation, live alignment, visual inspection and SME approval remain pending. Broad OVHcloud infrastructure coverage is not claimed. Reassess the guide after a mailbox migration or DNS delegation change before reusing prior evidence.