Setting up SPF and DKIM on OVHcloud

SPF per plan — and the default record trap

SPF answers a simple question: which IP addresses are allowed to send mail in the domain's name? The answer fits in a single TXT record placed at the apex. For MX Plan, the documented value fits on one line:

example.com.  IN TXT  "v=spf1 include:mx.ovh.com ~all"

The include:mx.ovh.com mechanism authorizes OVHcloud's shared sending infrastructure, the one through which MX Plan mailboxes and web-hosting scripts route their messages. For Email Pro and Exchange, the sending infrastructure is not the same and the value to include differs: it sits in the OVHcloud guide specific to each plan, and that is where it should be taken from rather than copying MX Plan's. The stable principle, though, never changes: one single TXT v=spf1, merging every legitimate source — the OVHcloud plan, but also the marketing platform (Brevo, Mailchimp…), the invoicing tool, the CRM. Each include consumes part of the ten-DNS-lookup budget the standard imposes; stacking without counting leads straight to permerror.

Then comes the house-made trap. When a zone is created with the default records, OVHcloud already deposits an SPF TXT authorizing its own infrastructure. This well-meaning default has two perverse effects. First, it survives migrations: a domain whose mail now lives at Microsoft 365 or Google Workspace keeps an open authorization toward OVHcloud's shared infrastructure — and from SPF's point of view, any machine on that shared infrastructure becomes a legitimate sender for the domain. Second, it feeds the reflex of "adding" a new SPF record rather than editing the existing one: two v=spf1 TXT records then coexist, and the standard is unforgiving — the result is a permanent error, not a merge. The same default-record question shows up at other registrars; the equivalent configuration at Gandi shows a different mechanism with an identical remedy: one single line, kept up to date.

There remains the choice of the final qualifier. ~all (softfail) marks unlisted sources as suspicious without demanding rejection; -all (fail) asks for outright rejection. During the inventory phase, ~all is the prudent choice; once DMARC is in place, the DMARC policy decides the fate of unaligned messages anyway, and hardening SPF becomes a refinement more than a necessity.

DKIM: CNAME selectors, activated from the control panel or the API

DKIM adds a cryptographic signature to the message, verified by the recipient thanks to a public key published in DNS under a name of the form <selector>._domainkey.example.com. At OVHcloud, there is no key to copy and paste: activation creates two selectors as CNAME records, pointing to targets managed by OVHcloud (names hosted under dkim.mail.ovh.net). The benefit of this arrangement is real: the public key stays at OVHcloud, which can rotate it regularly without any intervention on the zone — the two selectors alternate, one signing while the other awaits the next rotation.

Activation depends on the plan. For Exchange and Email Pro, it is driven from the control panel, in the configuration of the domain attached to the service, or through the API. For MX Plan, OVHcloud has largely automated activation on recent plans, and the API can trigger or check it on older domains. Since the exact button labels evolve regularly, the up-to-date procedure is the one in the OVHcloud documentation — the mechanisms described here (two selectors, CNAME, managed rotation) are the stable part.

One particular case deserves attention: when the DNS zone is not hosted at OVHcloud, the two CNAME records cannot be placed automatically. The values to create are then displayed in the control panel or retrievable through the API, and they must be copied — character for character — at the actual DNS host. A misspelled selector produces an unverifiable signature, which means a silent DKIM failure.

Mistakes seen in practice

Three families of mistakes come up again and again in DMARC reports for domains hosted at OVHcloud.

• Two v=spf1 TXT records. The most frequent, born from the default SPF. A receiver that finds two SPF records on the same name returns a permanent error: the message can no longer pass SPF, however good either line may be. The remedy is one operation: merge, then delete the duplicate — the zone's text mode makes the diagnosis immediate.
• The post-migration leftover. Mail migrated from MX Plan to Microsoft 365, or from Exchange to another platform: the SPF keeps the old include, now useless (and even risky, on a shared infrastructure), while DKIM still signs with the old plan's selectors — or no longer signs at all, the CNAME records having been deleted along with the service. DMARC reports expose these ghosts within days: a source that sent yesterday and no longer does, a signature failing since a precise date.
• The TTL that skews the tests. A published fix only becomes observable once caches expire, which can take up to an hour with the default TTL. Testing thirty seconds after the change, concluding failure, and "fixing" again leads to incoherent zones. The useful discipline: lower the TTL before a planned migration, then wait a full cycle before any verdict.

Verifying before hardening

Verification happens at three levels. First, raw DNS: a TXT query on the domain apex must return one and only one v=spf1; a query on the selector1._domainkey and selector2._domainkey names must follow the CNAME records all the way to the keys hosted by OVHcloud. The detailed method, tools and pitfalls included, is walked through in checking an SPF record.

Next, the full-scale test: a message sent to a Gmail or Outlook.com mailbox, followed by a read of the received message's Authentication-Results header. The expected mentions: spf=pass, dkim=pass with an OVHcloud selector, and aligned domains. Finally, observation over time: publishing a DMARC record in monitoring mode shows what receivers around the world actually see, week after week:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The DMARC record examples provide the template suited to each situation — active domain, defensive brand domain, subdomains. That observation phase is what turns a configuration that "looks right" into a proven one.

In summary

At OVHcloud, SPF and DKIM configure quickly once three landmarks are set: the email plan actually purchased (MX Plan, Email Pro or Exchange — each with its infrastructure, its SPF value, its DKIM procedure), the DNS zone as the single place of truth (with text mode as the audit tool), and the default SPF trap, responsible for most duplicate v=spf1 records seen in the wild. DKIM activates from the control panel or the API, as two CNAME selectors whose rotation OVHcloud manages; the classic mistakes — SPF duplicate, post-migration leftover, unanticipated TTL — are all caught by a careful read of the zone and of the reports.

The shortest starting point remains a free DMARC analysis of the domain: within seconds it shows the real state of SPF, DKIM and DMARC as a receiver sees them, duplicates included. Once the diagnosis is in, creating an account makes it possible to collect the reports, keep watch on the two OVHcloud selectors over time, and drive the policy toward p=reject on evidence rather than assumptions.