How to add DMARC, SPF and DKIM records on OVH

10 June 2026 · 14 min read

OVH hosts millions of domains across Europe and beyond, and its DNS zone editor is one of the more capable ones out there: you get a full record table, raw zone-file editing, and a generous set of record types. That power comes with a few sharp edges that trip people up specifically on OVH, especially when you are adding the three records that make email authentication work: SPF, DKIM and DMARC.

This guide walks through exactly where each record goes in the OVH control panel, what to type into each field, and the OVH-specific gotchas: how OVH labels the root of your zone, how it splits long TXT records, why a DKIM CNAME sometimes refuses to save, and how OVH's TTL and serial-number behaviour affects how fast your changes go live. Every example below uses real, valid record syntax you can adapt to your own domain.

If you would rather not touch any of this by hand, the done-for-you DMARC service publishes and maintains all of these records for you and walks your domain safely from p=none to p=reject. But if you want to do it yourself on OVH, read on.

Before you start: find the OVH DNS zone, not the redirection page

OVH has two different places that look like they manage your domain, and beginners frequently edit the wrong one.

• The DNS zone (sometimes shown as "DNS zone" or "Zone DNS") is the real authoritative editor. This is where SPF, DKIM and DMARC records live.
• The redirection / web forwarding screen handles HTTP redirects and has nothing to do with email authentication.

To reach the right place, log in to the OVH Control Panel, open Web Cloud (or Domains), select your domain, then open the DNS zone tab. You will see a table of existing records with an Add an entry button, plus a tab or toggle for Edit in text mode (the raw zone file).

One important precondition: OVH must actually be running your DNS. If you have pointed your domain's nameservers at Cloudflare, Route 53 or another provider, then editing the OVH DNS zone does nothing because OVH is no longer authoritative. Check this first. At the top of the DNS zone page OVH usually shows the active nameservers; if they are not dns.ovh.net / ns.ovh.net, you need to edit records wherever your real nameservers are, not here. You can confirm what the public internet actually sees with the DNS record checker before and after any change.

How OVH names the root of your zone

This is the single biggest source of confusion on OVH, so it is worth getting straight before you add anything.

When OVH asks for a subdomain in the "Add an entry" form, it means the host label in front of your domain, not the full hostname. To target the root of the domain (the apex, for example example.com itself), you leave the subdomain field empty. You do not type @, you do not type the domain name, you leave it blank.

So for a record at the apex:

• OVH subdomain field: leave it empty
• Resulting name: example.com

For a record on a host below the apex, you type only the label:

• OVH subdomain field: _dmarc
• Resulting name: _dmarc.example.com

And in raw zone-file (text) mode, OVH uses the bare @ symbol for the apex, like a classic BIND zone file. So the same apex SPF record looks like this in text mode:

@ 3600 IN TXT "v=spf1 include:mx.ovh.com -all"

Keep this rule in mind for every record below: empty subdomain field, or @ in text mode, means the root. A label like _dmarc or selector1._domainkey means a host underneath it. Mixing these up is why people end up with a DMARC record sitting at _dmarc._dmarc.example.com or an SPF record that never gets found.

Step 1: Add (or fix) the SPF record

SPF (Sender Policy Framework) is a single TXT record at the root of your domain that lists which servers are allowed to send mail using your domain in the envelope sender. There must be exactly one SPF record per domain. If OVH already created a default one when you set up email hosting, edit that one rather than adding a second.

Where it goes

1. In the DNS zone, click Add an entry.
2. Choose record type TXT.
3. Subdomain: leave empty (this is the apex).
4. TTL: leave as default, or set 3600.
5. Target / Value: the SPF string in quotes.

A starting SPF record for a domain that sends only through OVH email hosting looks like this:

v=spf1 include:mx.ovh.com -all

If you also send through a third party (for example a marketing platform or a transactional provider), you add its include before the all mechanism. A domain sending through OVH plus SendGrid plus Google Workspace might use:

v=spf1 include:mx.ovh.com include:sendgrid.net include:_spf.google.com -all

OVH SPF gotchas

• Only one SPF record. Two v=spf1 TXT records at the apex is a hard SPF failure (permerror). If OVH auto-created an SPF entry and you add another, you have broken SPF. Merge everything into one record.
• The ten-lookup limit. SPF allows a maximum of ten DNS lookups when it is evaluated. Each include: you add (and includes can chain into more includes) counts. OVH does not warn you about this; you will only see it as a permerror in your DMARC reports. If you are stacking several include mechanisms, check the count and flatten if needed.
• -all versus ~all. -all is a hard fail (reject unlisted senders), ~all is a soft fail. Start with ~all if you are not yet certain you have listed every legitimate sender, then tighten to -all once your reports are clean.
• Do not wrap OVH's value in extra quotes in the form. In the graphical "Add an entry" form, OVH adds the quoting for you, so paste the raw v=spf1 ... string. In text mode you must include the quotes yourself.

When you are done, confirm the published record with the SPF checker, which also counts your DNS lookups so you can see how close you are to the limit. If you are close, the SPF generator can help you build a tidy record.

Step 2: Add the DKIM record (TXT or CNAME)

DKIM (DomainKeys Identified Mail) is where OVH's editor most often fights you, because DKIM records come in two shapes and the OVH form behaves differently for each.

DKIM works by publishing a public key under a selector. The hostname always follows the pattern:

<selector>._domainkey.example.com

The selector is chosen by whoever signs your mail. OVH's own email hosting uses a selector it shows you in the email configuration screen; Google Workspace uses google; many providers use names like selector1, s1, k1, mail, or a long random string.

Case A: the provider gives you a long TXT public key

This is the classic DKIM record. The value starts with v=DKIM1; and contains a long base64 p= key:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...very long...IDAQAB

To add it on OVH:

1. Add an entry, type TXT.
2. Subdomain: the host portion only, for example selector1._domainkey (not the full domain).
3. Target / Value: the whole v=DKIM1; ... string.

The TXT chunking gotcha (this is the big one on OVH)

A single character string in DNS cannot exceed 255 bytes. DKIM keys, especially 2048-bit RSA keys, are longer than that. The DNS protocol handles this by allowing a TXT record to be made of several quoted strings concatenated together, like this:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAfirstchunk..."
"...secondchunkcontinuingthekey...IDAQAB"

Here is how OVH handles it:

• In the graphical form, paste the entire key as one continuous string with no manual quotes and no line breaks. OVH's editor will split it into 255-byte chunks for you when it writes the zone. Do not try to insert your own quotes in the graphical form; you will end up with literal " characters baked into the key, which makes the published key invalid.
• In text mode, if you paste a value longer than 255 characters as a single quoted string, OVH may reject it or save something malformed. The safe approach in text mode is to split the key yourself into multiple quoted strings (each under 255 bytes) separated by spaces or new lines inside the same record, exactly as shown above. DNS resolvers concatenate them back into one key.

The failure mode to watch for: a DKIM key that "looks" present in the OVH table but verifies as broken because a stray quote or a bad split corrupted the base64. After saving, always validate with the DKIM checker. Give it your domain and selector and it will fetch the record exactly as the world sees it, reassemble the chunks, and tell you whether the key parses. A green result here is worth far more than the record merely appearing in the OVH panel.

Case B: the provider gives you a CNAME (delegated DKIM)

Many modern providers (and DMARC Engine's own hosted setup) do not give you a raw key. Instead they ask you to add a CNAME that points the selector host at a hostname they control, so they can rotate the key for you without you ever touching DNS again. It looks like this:

selector1._domainkey.example.com.  CNAME  selector1.dkim.provider.example.

To add this on OVH:

1. Add an entry, type CNAME.
2. Subdomain: selector1._domainkey (host part only).
3. Target: the provider's hostname, for example selector1.dkim.provider.example.

OVH CNAME gotchas

• Trailing dot. OVH's text-mode zone file is fussy about the trailing dot. A CNAME target without a trailing dot may be treated as relative and have your own domain appended, so selector1.dkim.provider.example silently becomes selector1.dkim.provider.example.example.com. In the graphical form OVH usually appends the dot for you, but in text mode add it yourself: selector1.dkim.provider.example.. If your DKIM suddenly resolves to a nonsense hostname, this is almost always why.
• A host cannot have both a CNAME and other records. This is a DNS rule, not an OVH quirk, but OVH enforces it: if selector1._domainkey already has a TXT record, OVH will refuse to add a CNAME on the same name. Delete the old TXT first.
• CNAME "flattening" does not apply at a DKIM selector. Some hosts (notably Cloudflare) flatten CNAMEs at the apex into A records. OVH does not do this, and you would not want it at a _domainkey host anyway. Just add the CNAME as given. The only place apex CNAME flattening ever matters is the root of the zone, and DKIM never lives at the root.

After saving a delegated DKIM CNAME, confirm it resolves through to a valid key with the DKIM checker. It follows the CNAME for you and validates the key at the far end.

Step 3: Add the DMARC record

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a single TXT record at a fixed host: _dmarc under your domain. It ties SPF and DKIM together with a policy and, crucially, asks receivers to send you reports.

Where it goes

1. Add an entry, type TXT.
2. Subdomain: _dmarc (just that, not _dmarc.example.com).
3. Target / Value: your DMARC policy string.

A safe starting record, monitoring only, with reports sent to a mailbox you can read, looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r

What each tag does here:

• p=none means do not change how mail is handled yet; just observe. This is the only sane way to start.
• rua= is where the daily aggregate XML reports go. This is the data you actually need.
• ruf= is for forensic / failure reports (many receivers ignore these, but it costs nothing to ask).
• fo=1 asks for a failure report whenever any underlying check fails.
• adkim=r and aspf=r set relaxed alignment, which is the right default.

Why you must NOT start at p=reject on OVH (or anywhere)

It is tempting to paste p=reject straight away because that is the "secure" setting. Do not. If any legitimate source of your mail is not yet aligned (a newsletter tool, your CRM, an OVH-hosted app, a booking system), p=reject will cause receivers to bin that mail. The correct path is:

1. Publish p=none and collect aggregate reports for two to four weeks.
2. Read the reports to find every legitimate sender and fix its SPF/DKIM alignment.
3. Move to p=quarantine with a low pct, then increase coverage.
4. Only then move to p=reject.

This is exactly the staged rollout the hosted DMARC product automates, but you can do it by hand on OVH as long as you actually read the reports. Raw DMARC XML is unreadable, so paste it into the DMARC report analyzer to see which senders are passing and which are not. If you want a policy string built for you from a few questions, the DMARC generator produces a valid record you can paste straight into the OVH value field.

DMARC gotchas on OVH

• The host is _dmarc, full stop. Putting the record at the apex (empty subdomain) is the most common DMARC mistake. It will not be found there. It must be _dmarc.
• One DMARC record only. Two v=DMARC1 TXT records at _dmarc is invalid and receivers will ignore your policy entirely.
• Cross-domain reporting needs the other domain's permission. If your rua address is on a different domain (for example you send OVH-domain reports to a mailbox at an analytics provider), that other domain must publish an authorisation record, or large receivers will refuse to send reports there. Reports to a mailbox on the same domain need no such record.

Validate the final record with the DMARC checker, which parses every tag and warns about common mistakes such as a missing rua or an unreachable report address.

TTL, serial numbers and how fast OVH changes go live

OVH gives you a per-record TTL field. A few practical notes specific to how OVH behaves:

• Default TTL on OVH is typically 3600 seconds (one hour). That means a cached old value can linger for up to an hour after you change it. If you are about to make a change you might need to roll back quickly (tightening SPF to -all, for example), lower the TTL to 300 a day or two before the change, then raise it again once you are confident.
• OVH bumps the zone serial automatically on save, but it does not always push instantly. After you click Save, OVH may show a confirmation and apply the change to its nameservers within a minute or two; occasionally it takes a little longer to propagate across all of OVH's anycast nodes.
• Propagation is about caches expiring, not about OVH being slow. Even after OVH is serving the new record, resolvers around the world hold the old answer until its TTL expires. So "I added it but the checker still shows the old value" is usually a caching artefact, not a mistake. Confirm what is actually authoritative versus cached with the DNS propagation checker.

A reliable rhythm on OVH: make the change, wait a couple of minutes, then re-check with the relevant tool. If the tool still shows the old value and you are past your TTL, then go back and look for an editing error (wrong subdomain, stray quote, missing trailing dot).

Text mode versus the graphical editor: when to use which

OVH lets you switch the whole zone into raw text editing. Both modes write the same zone, so use whichever avoids mistakes for the record at hand.

• Use the graphical "Add an entry" form for SPF and DMARC. Short, single-string TXT records are easy to get right there, and OVH handles the quoting.
• Use the graphical form for delegated DKIM CNAMEs too, because OVH usually appends the trailing dot for you.
• Consider text mode for a long raw DKIM TXT key only if the graphical form mangles it. In text mode you control the chunking explicitly: split the key into multiple sub-255-byte quoted strings within one record. If you are unsure how to split a long string cleanly, the DNS record splitter chunks a long TXT value into correctly sized quoted strings you can paste straight into the zone file.

Whatever mode you use, the published result is what matters, not how it looks in the panel.

A complete OVH example, end to end

Here is what a finished, healthy email-authentication setup looks like in OVH text mode for example.com sending through OVH email plus one marketing platform. Remember that @ is the apex and the trailing dots are deliberate.

@               3600 IN TXT   "v=spf1 include:mx.ovh.com include:_spf.marketingplatform.example -all"
_dmarc          3600 IN TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r"
ovhselector._domainkey  3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...firstchunk..." "...secondchunk...IDAQAB"
mkt._domainkey  3600 IN CNAME mkt.dkim.marketingplatform.example.

Note the four moving parts: one apex SPF record, one _dmarc policy, OVH's own DKIM as a chunked TXT key, and the marketing platform's DKIM as a delegated CNAME with its trailing dot. That is the full set. There is nothing else to add for SPF, DKIM and DMARC.

Verify everything before you trust it

The OVH panel showing a record does not prove the record is correct or visible to the world. Always close the loop with an external check:

• SPF checker: one record, syntax valid, lookups under ten.
• DKIM checker: selector resolves, chunks reassemble, key parses.
• DMARC checker: record at _dmarc, policy and rua valid.
• DNS record checker: a quick sweep of what is actually published.

For the bigger picture of what "good" looks like across all five mechanisms, see the email authentication requirements, and if any term above is unfamiliar, the glossary defines SPF, DKIM, DMARC alignment, selectors and the rest in plain language.

The practical takeaway

Adding SPF, DKIM and DMARC on OVH is mostly about three OVH-specific habits: leave the subdomain field empty (or use @) for the apex, never let a long DKIM key pick up stray quotes or a bad split, and always add the trailing dot on a CNAME target in text mode. Get those right, start DMARC at p=none, read your reports, and tighten the policy in stages.

Once the records are live, the real work is ongoing: watching the aggregate reports, spotting a new sender that suddenly fails alignment, and not breaking your own mail when you move toward p=reject. You can do all of that yourself, or you can let continuous monitoring with change alerts and the done-for-you DMARC service handle the rollout and the day-to-day watching for you, so an OVH zone edit never quietly breaks your email again.