OVH mail plans (MX Plan, Email Pro, Exchange) will happily send mail without DKIM, and many accounts run that way for years because nothing visibly breaks — until a DMARC policy starts quarantining the traffic. This guide covers enabling DKIM in the OVH control panel, getting SPF right, and moving to enforcement without cutting off legitimate senders.
Step 1 — Enable DKIM in the OVH panel
- Open the OVHcloud control panel and go to Web Cloud → Emails, then select the domain.
- Open the General information tab and find the DKIM section. DKIM is off by default on most plans, so this is a real switch, not a formality.
- Start the activation. OVH generates a selector and the matching
TXT record. Note the selector name shown — it differs between offers, and the selector is part of the DNS name you must publish.
- If the domain's DNS zone is hosted at OVH, the record is usually published automatically. If DNS lives elsewhere, copy the record and add it at your DNS provider manually.
- Wait for propagation, then confirm with the DKIM Checker using the selector you noted.
Do not assume activation finished because the panel says so. The panel tracks its own state; the record either resolves publicly or it does not.
Step 2 — Publish an SPF record for OVH sending
OVH mail servers send from their own infrastructure, so the SPF record must authorise it. Use the include: value OVH documents for your specific offer rather than copying one from a blog post — the value for MX Plan and the value for Exchange are not always the same, and a wrong include fails exactly like a missing one.
Two rules keep the record healthy:
- Keep every mechanism inside the 10-DNS-lookup limit. Each
include: costs a lookup, and exceeding the limit returns a permanent error.
- Do not stack a second
v=spf1 record. Two SPF records on one name is a syntax error, not a merge.
Validate the published record with the SPF Checker. If you also send through a website, CRM or ESP, those senders need their own include on the same record.
Step 3 — Add DMARC, then tighten
Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com and let a full week of aggregate reports accumulate before changing anything. Reports are the only way to see which IPs are sending as your domain — including the ones you forgot about, such as a contact form on an old host.
Then move in steps: p=quarantine; pct=10, verify that quarantined volume matches sources you already know, raise pct, and only then move to reject. Read the XML with the DMARC Report Analyzer and confirm the published policy with the DMARC checker.
Troubleshooting
DKIM checks pass but DMARC still fails
Check which domain signed the message. If OVH signs with a shared or subdomain identifier and your policy uses adkim=s, alignment fails despite a valid signature. Relaxed alignment (adkim=r) is the default for a reason.
Mail from a subdomain behaves differently
DMARC's sp= tag governs subdomains when present; without it, subdomains inherit p=. If you delegate a subdomain to a separate platform, publish a record there rather than loosening the parent policy.
External DNS provider never sees the record
When the zone is not hosted at OVH, automatic publication cannot happen. Add the TXT record manually and use the TXT Lookup to confirm what is actually public.
FAQ
Does OVH DKIM work with a domain hosted elsewhere?
Yes, but you must publish the generated TXT record yourself. OVH can only auto-publish into a zone it manages.
Should I authenticate every mailbox?
Authentication is per-domain, not per-mailbox. Every mailbox sending as that domain inherits the same DKIM and SPF setup.
What if reports show no data at all?
Verify the rua mailbox accepts mail and that the DMARC record still resolves — the Header Analyzer shows the authentication results a real message carried.
