To authenticate OVHcloud email, first identify the actual mail product. Shared MX Plan, Email Pro and Hosted Exchange use the documented shared-mail SPF authorization; Private Exchange requires the actual server addresses. Obtain DKIM records from the selected service, complete activation, and verify an aligned passing result on a received message. OVHcloud DNS hosting alone does not make OVHcloud your sender.
This guide covers hosted email, including the separate Zimbra workflow. It does not configure a self-managed VPS or dedicated-server mail transfer agent. No customer account, DNS change or delivery test was performed.
Choose the product before changing DNS
Record the product name, service reference, account region and domain from the control panel. Keep a raw message from each route and record its visible From address, MAIL FROM identity and DKIM signing domain. Then identify the authoritative DNS host and export the current zone.
Do not identify the product solely by its webmail interface. OVHcloud uses Zimbra both within an MX Plan migration and as a standalone offering. The migration FAQ distinguishes those services and says the MX Plan transition preserves SPF/MX/SRV configuration. A different webmail login screen is not a reason to replace authentication DNS with a new recipe. OVHcloud Zimbra migration FAQ
Before proceeding, confirm that you can manage the correct email service and its associated domain, edit the actual DNS zone, and receive a test message at an external mailbox. Inventory staff mail, applications, marketing and support tools separately. Preserve their authorizations and existing DMARC policy. Do not alter MX or nameservers just to enable outbound authentication: those changes can affect receiving mail and unrelated services.
Configure SPF for the actual service
MX Plan, Email Pro and Hosted Exchange
For Europe/Africa, OVHcloud’s shared-mail example is a TXT value:
v=spf1 include:mx.ovh.com ~all
For Canada/Americas and Asia/Pacific, the shared-mail example instead uses v=spf1 include:mx.ovh.ca ~all. Choose the region of the actual service, not the operator’s location; do not add both includes without a real need. The source lists MX Plan across these regions, Email Pro for Europe/Africa, and Hosted Exchange for Europe/Africa and Canada/Americas. These are provider-only examples, not as an automatic replacement for your existing policy. In OVHcloud DNS, use Web Cloud → Domain names → your domain → DNS zone; locate the existing policy and use its actions menu → Edit the entry, or Add an entry → TXT when none exists. Paste the approved full policy in Value. For an apex owner, leave Subdomain empty or use the interface’s supported @; for a child owner, enter its relative name. If you use the SPF helper instead, its Include OVH email servers checkbox inserts mx.ovh.com; the regional instructions require mx.ovh.ca in Additional servers to authorise (include) for Canada/Americas and Asia/Pacific. Review the generated value and resulting TXT answer; do not authorize a or mx merely because a checkbox exists. If another host is authoritative, publish there. OVHcloud SPF setup
Private Exchange
Use the actual server IPv4 and IPv6 addresses with ip4 and ip6. Retrieve them from the service’s General information diagnostics, or the A/AAAA records for its webmail hostname when the green diagnostics do not expose the values. This Private Exchange branch is documented for Europe/Africa and Canada/Americas. Add the correct regional shared-mail include only if you also use shared mail. Never copy the documentation’s sample IP addresses. Private Exchange SPF branch
Standalone Zimbra
Use Zimbra Mail → Domain → the domain’s menu → Diagnostics and inspect its SPF instructions. Zimbra onboarding supports automatic SPF configuration; the custom configuration branch is appropriate when existing email settings must be preserved. Inspect the proposed change rather than accepting a full automatic DNS configuration that could replace an existing service. Use the current account-issued value for your deployment. Leave MX and SRV routing/autoconfiguration changes outside this authentication repair. The Custom configuration screenshot has those boxes checked, so Custom alone does not prevent routing changes: deselect unapproved MX/SRV actions and review the exact changes before Confirm. Where Zimbra shares a domain with Exchange or Email Pro, the native guide requires a non-authoritative email-domain configuration: have the routing administrator approve that coexistence plan separately; this is not DNS nameserver delegation. For an external domain, Zimbra may first issue a separate ownership CNAME; keep it distinct from the two DKIM selectors, and note its documented 48-hour validation window. Zimbra domain setup and diagnostics
Merge safely at the exact SPF owner
SPF evaluates the MAIL FROM domain, or HELO for an empty reverse path, rather than automatically evaluating the visible From domain. Parent policies do not inherit to subdomains. Publish one v=spf1 TXT policy at each evaluated owner; merge needed authorizations into it, preserving unrelated TXT records and the existing terminal policy. SPF record selection
Evaluate all nested includes and redirects against the limit of 10 evaluated DNS-query-causing terms. a, mx, exists and ptr can also consume that budget. Do not count only the visible includes, add +all, or replace a managed include with an unmaintained snapshot of current IPs. Preserve a stronger existing policy rather than changing -all to the example’s ~all. SPF processing limits
redirect is ignored whenever the policy contains an all mechanism. Do not append a redirect after ~all or -all expecting a second policy to run. Keep the approved ending and evaluate any redirect-based design separately. SPF all/redirect rule
An authorization for an unrelated third-party sender belongs at the domain that service actually uses for SPF. Adding every vendor to the root policy without examining the MAIL FROM identity can increase complexity without authenticating its messages.
Enable DKIM for the selected OVHcloud product
Automatic DKIM configuration is proposed and performed by default unless disabled, so inspect the existing status before starting activation. The current official workflow is product-specific:
- MX Plan: domain → General information → red DKIM badge → Validate.
- Exchange: service → Associated domains → domain’s DKIM badge → Validate.
- Email Pro: service → Associated domains → domain’s DKIM badge → Validate.
- Zimbra: Zimbra Mail → Domain → domain menu → Diagnostics → DKIM.
The prose labels the activation confirmation Validate; its English modal screenshot labels that action Confirm. Confirm the correct service/domain in the modal, rather than relying on the wording alone. Copy both generated CNAME owners and targets when requested. With external DNS, publish and let them resolve before completing Enable. Check the resulting green badge or cleared Zimbra warning. The documented activation window is 30 minutes to 24 hours. The source scopes MX Plan, Email Pro and Zimbra instructions to Europe/Africa, and Exchange to Europe/Africa and Canada/Americas; confirm your account’s product and region rather than extrapolating. OVHcloud DKIM configuration
For manual OVHcloud DNS publication, open Domain names → the authoritative domain → DNS zone → Add an entry → CNAME. Enter the relative selector owner and the complete issued target; the native form expects a final dot on the target. Check the generated full owner before Add and repeat for the other selector. Do not use the DKIM helper, which creates TXT, for an issued CNAME. OVHcloud native record workflow
Keep the two owner/target pairs together in your change record. They are generated for your service; a sample such as another account’s ovhex... selector is not reusable. Do not derive targets from a service name, region or old screenshot.
A CNAME cannot share its owner with a conflicting TXT, address or MX record, or with a second CNAME. If a conflict exists, identify the current owner before making a change. Use DNS-only resolution where a DNS host offers web proxying. Avoid duplicated domain suffixes when an editor appends the zone automatically. Query the final fully qualified owner after saving.
For an issued full owner such as issued-selector._domainkey.news.example.com, an example.com zone uses issued-selector._domainkey.news; a separately delegated news.example.com zone uses issued-selector._domainkey. If _domainkey.news.example.com itself is delegated, publish issued-selector in that delegated zone with its administrator. These are owner-mapping examples, not real OVHcloud selectors. Preserve NS delegations and unrelated selectors; never delete a delegation to force a parent-zone edit. DNS aliases and delegation
If the authoritative host is Cloudflare, keep these aliases DNS only rather than proxied. Turn a relevant per-record Flatten control off where available, and ensure whole-zone flatten-all does not suppress the required literal CNAME answers. Coordinate dependencies before turning off an applicable zone setting; do not blanket-disable unrelated settings. Cloudflare’s apex and same-zone target behavior can flatten even without that per-record option. If mandatory behavior cannot retain the required aliases, stop and coordinate a supported configuration with the DNS and email administrators. Do not invent a switch or replace the issued target. Cloudflare flattening controls · CNAME verification caveats
If your approved workflow uses the API
Keep the product’s native API family and account region: /email/domain/ for the documented Europe/Africa MX Plan and Zimbra flow, /email/exchange/ for Exchange, and /email/pro/ for Europe/Africa Email Pro. Read existing state before any write. This guide neither grants API access nor runs activation, deletion or rotation calls.
MX Plan/Zimbra expose the domain’s DKIM state and both cname values through the native GET DKIM operation. The documented enable flow uses PUT, may return a pending task, and requires manual DNS followed by activation when automatic publication cannot complete. modifying is pending, toConfigure requires DNS attention, and enabled is the final configuration state. Selector toSet means missing and toFix means wrong values.
Exchange/Email Pro list assigned selector names first, then create the required selectors using their product-specific POST operation. Retrieve each selector’s customerRecord, targetRecord and recordType; these returned fields, not tutorial samples, define DNS. Wait for ready before the explicit selector-enable operation. inProduction identifies the active selector, while the successor can remain ready. A pending task or DNS-visible key is not signing activation. Follow the exact current native parameter schema rather than borrowing identifiers between products. Full product API workflows and states
The DKIM verification name is formed from the received signature’s selector s= and domain d=: selector._domainkey.signing-domain. Its public record must resolve to the key corresponding to the service’s signing key. Do not publish private keys, credentials or unrelated generated key material. Keep old valid selectors available during a planned rotation until delayed mail no longer needs them. DKIM selectors and key discovery
Preserve DMARC enforcement and establish reporting
A passing SPF result with an aligned MAIL FROM domain, or a passing DKIM signature with an aligned d= domain, satisfies DMARC. Relaxed alignment uses the same organizational domain; strict alignment requires exact equality. For example, with visible From sender@example.com, a passing intended DKIM signature using d=mail.example.com aligns only under relaxed mode when both share the same Organizational Domain; d=example.com aligns under both relaxed and strict mode. A passing unrelated provider domain does not suffice. Exact DKIM alignment rule Current RFC 9989 replaces RFC 7489 and removes pct; do not plan percentage enforcement using that obsolete tag. Current DMARC specification
Inspect the sending domain’s _dmarc record and any applicable parent policy before changing anything. Retain established quarantine or reject enforcement, alignment settings and reporting destinations. Do not add a second DMARC policy or create a child p=none that overrides inherited enforcement.
For a first monitored rollout with no direct or applicable inherited policy, and only after the domain owner approves the monitoring plan and recipient, this is an illustrative starting shape, not a record to paste unchanged:
Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Use an approved mailbox or reporting service instead of the example address. Separate tags with semicolons and keep one policy at the owner. A relative-owner editor for the example.com zone expects _dmarc; for a visible From domain of news.example.com, use _dmarc.news there, producing _dmarc.news.example.com. If news.example.com is a separately delegated authoritative zone, use relative _dmarc in that zone for the same full owner. A delegated _domainkey zone is for DKIM selectors, not the DMARC policy. For a destination in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization before sending aggregate reports. A destination within the same Organizational Domain is excepted; merely using a different hostname does not make it external. The domain owner must independently approve the aggregate recipient and data sharing: protocol DNS authorization is not privacy approval. RFC 9990 external reporting authorization
Review aggregate reports across all legitimate routes before choosing stronger enforcement. Do not assume a successful test represents a month’s worth of billing or application traffic. Failure reports can reveal message information and require a deliberate privacy decision.
Test DNS, activation and delivered-message alignment
These read-only commands are patterns. Replace example names with the actual MAIL FROM domain, generated DKIM owners and visible From domain; no customer queries were performed in this review.
dig +short NS example.com
dig +short TXT example.com
dig +short CNAME first-selector._domainkey.example.com
dig +short CNAME second-selector._domainkey.example.com
dig +short TXT _dmarc.example.com
Compare authoritative answers with a public recursive resolver. For SPF, expect one valid policy at the evaluated owner. For each DKIM CNAME, expect the exact target returned by the account and a usable public key at that target. For DMARC, expect the intended single policy. Record TTLs and distinguish stale cached data from a wrong authoritative answer.
Next send a new message through the real mailbox route to an external inbox you control. Save its raw source. Use results produced inside the receiving service’s known processing boundary and establish its documented handling of externally supplied Authentication-Results, such as stripping or isolating those untrusted fields. Ignore attacker-supplied results. Header position and a familiar authserv-id string alone prove nothing; if that handling cannot be established, use receiver-controlled message trace or logs instead. Authentication-Results trust boundary
Confirm the following:
- SPF passes for the expected
smtp.mailfromdomain when that route is intended to authenticate with SPF. - DKIM passes for the expected
header.ddomain; the signature carries an expected selector. - DMARC passes for
header.from, supported by at least one aligned passing method. - The actual outbound route agrees with your product and application inventory.
For newly configured branded DKIM, require the intended OVHcloud signature itself to pass and align with the intended, unchanged visible From under the current policy, plus trusted dmarc=pass. A DMARC pass through SPF alone does not prove DKIM; a rewritten provider From does not prove authentication of your intended brand. Diagnose SPF fail (not authorized), temperror (temporary evaluation problem) and permerror (invalid policy or evaluation-limit problem) separately even when aligned DKIM makes DMARC pass. SPF results
Repeat for each application, alias and distinct service in use. Keep direct and forwarded copies separate. A green control-panel badge demonstrates configuration status, not that every delivered message aligns; authentication also does not guarantee inbox placement.
Website email is a separate test
OVHcloud distinguishes PHP mail() through hosting infrastructure from authenticated SMTP through an email account. The former requires the From domain to be attached to the hosting plan; the latter uses the account route and signs with DKIM when it is enabled. Prefer a fixed, authorized sender for form notifications, with the visitor’s address in Reply-To rather than impersonated in From. Check application logs and its actual route. OVHcloud web-hosting sending guidance
For WordPress, first identify the plugin’s real transport. Use EmailAuth’s raw DKIM versus aligned DKIM explanation when interpreting its received-message result. Do not certify site notifications from a passing webmail test.
Troubleshooting OVHcloud authentication
DKIM stays red: check both generated CNAME pairs, delegation and exact targets. For Exchange/Email Pro, native diagnostic 501 identifies an uninitialized second selector, 502 a failed configuration task, 503 a wrong CNAME and 504 a missing CNAME. Fix only the identified record or task; use the actual account owner, not a sample diagnostic string. OVHcloud distinguishes missing or wrong records from a configuration task error. If the documented activation window has elapsed, retain the diagnostic state and service reference for support. Do not repeatedly delete and regenerate selectors. OVHcloud DKIM diagnostics
550 5.7.1 rejects a different From domain: OVHcloud documents cross-domain spoofing protection from 20 July 2026. Its Europe/Africa instructions cover Zimbra, MX Plan and bundled hosting email; the Canada/Americas and Asia/Pacific branches list MX Plan and bundled hosting email, not Zimbra. Compare the authenticated mailbox domain with the application’s actual From domain. Use an authorized mailbox on the sending domain rather than weakening SPF or DMARC. Prefer per-address accounts or supported delegation over shared credentials impersonating multiple addresses. OVHcloud cross-domain rejection guidance
SPF fails only on Private Exchange: compare its real outbound addresses with the IP-based policy. A shared-mail authorization is not a substitute for verifying that server’s route.
Authentication passes but DMARC fails: compare the passing domains with the visible From domain and configured strict/relaxed alignment. Diagnose identity selection before changing policy.
Only one application fails: compare a passing mailbox sample with the failing application. Check SMTP account, transport, envelope identity and signature instead of adding more root-domain includes.
The domain recently migrated: verify the current product and account-generated values. Retain old records still needed for delayed messages or other active services; remove them only after ownership and traffic review.
Prepare a sanitized support bundle with product, region, service reference, timestamp, Message-ID, exact selector names, DNS answers and receiver results. Do not include passwords or private keys.
What this review verifies
Account eligibility, generated records, customer DNS and actual message outcomes remain to be checked in your environment. No live configuration, publication or delivery outcome is claimed.