How to configure DMARC on OVH (the right way)
OVH has a built-in DMARC generator, but it doesn't support all DMARC tags. Here's how to add a proper DMARC TXT record in OVH's DNS zone, why you should skip their wizard, and how to actually monitor what happens next.
OVH (OVHcloud) is one of the largest hosting providers in Europe. Millions of domains rely on their DNS infrastructure. If you manage a domain on OVH, you should configure DMARC to protect your brand and make sure your emails reach their destination.
OVH offers a built-in DMARC generator in their DNS zone editor. It looks convenient. Itâs also incomplete. The wizard doesnât support several important DMARC tags, which limits your control over reporting and subdomain policies.
This guide walks you through setting up DMARC on OVH using a standard TXT record, which gives you full flexibility. Weâll also cover the SPF prerequisites, common OVH-specific pitfalls, and how to turn those unreadable XML reports into something useful.
Why skip OVHâs built-in DMARC generator?
When you add a DNS entry in OVHâs control panel, youâll notice a âDMARCâ option under âMail records.â Itâs a wizard that generates a DMARC record through a form. It covers the basics: policy (p), percentage (pct), aggregate report address (rua), and alignment modes (adkim, aspf).
But it misses several tags:
| Missing tag | What it does |
|---|---|
ruf |
Forensic (failure) report address. Lets you receive detailed reports on individual authentication failures. |
fo |
Failure reporting options. Controls when forensic reports are generated (0, 1, d, s). |
sp |
Subdomain policy. Lets you set a different policy for subdomains than for the root domain. |
ri |
Report interval. Controls how often aggregate reports are sent (default is 86400 seconds / 24 hours). |
If you want to receive forensic reports, apply a different policy to your subdomains, or control report intervals, OVHâs wizard simply wonât let you.
Thereâs another issue. OVH stores wizard-generated DMARC entries as a proprietary âDMARCâ record type internally, not as a standard TXT record. While DNS servers read them correctly, this can cause problems with third-party DNS management tools, APIs, and automation scripts.
The solution is simple: use a standard TXT record instead. It supports every DMARC tag, works with all tools, and gives you complete control.
Before you start
DMARC builds on two authentication mechanisms: SPF and DKIM. Before adding a DMARC record, make sure at least one of them is configured.
Check your current setup
Go to our free domain checker and enter your domain. Youâll see the status of your SPF, DKIM, and DMARC records instantly. If SPF or DKIM are missing, fix those first.
SPF on OVH
If you use OVHâs email hosting (MX Plan, Exchange, or Email Pro), your SPF record should include OVHâs mail servers. Hereâs the recommended value:
v=spf1 include:mx.ovh.com ~all
OVH also has a built-in SPF generator (same problem, same recommendation: use a TXT record instead for full control). If you use additional email services like Google Workspace, Mailjet, or SendGrid, you need to include all of them in a single SPF record:
v=spf1 include:mx.ovh.com include:_spf.google.com include:spf.sendinblue.com ~all
Remember: SPF has a 10 DNS lookup limit. Each include: counts as one or more lookups. Use our SPF generator to build a valid record and check your lookup count.
You must have exactly one SPF record per domain. If you already have one, edit it. Never add a second.
DKIM on OVH
If you use OVHâs email hosting, DKIM is available for Exchange and Email Pro plans. For MX Plan, DKIM support depends on your setup. Check OVHâs documentation for your specific plan to enable DKIM signing.
For third-party email services (Google Workspace, Microsoft 365, etc.), follow their DKIM setup guides, which typically involve adding CNAME or TXT records in OVHâs DNS zone.
Step 1: get your DMARCTrust reporting address
DMARC reports are XML files that email providers (Gmail, Microsoft, Yahoo, and many others) send back to you. They contain data about every email sent using your domain: whether SPF passed, whether DKIM aligned, what happened to the message.
Reading raw XML is not practical. Thatâs what we do for you.
When you sign up for DMARCTrust, you get a unique reporting address, a dedicated mailbox that collects all your aggregate reports automatically:
[email protected]
This is a dedicated inbox managed by us. Reports arrive, get parsed, and appear in your dashboard. No manual processing, no XML files piling up in your email.
Add your domain in your DMARCTrust dashboard, then use our DMARC generator to build your record. Select p=none to start in monitoring mode and paste your reporting address in the rua field.
The generator outputs something like:
v=DMARC1; p=none; rua=mailto:[email protected];
Copy this value. Youâll paste it into OVH next.
Step 2: log into the OVHcloud control panel
Go to the OVHcloud Control Panel and sign in.
In the top navigation bar, switch to Web Cloud. In the left sidebar, click Domain names and select your domain.
Click the DNS zone tab.
Youâll see a table listing all your existing DNS records: A, AAAA, CNAME, MX, TXT, and others. This is where youâll add your DMARC record.
Step 3: check for existing DMARC records
Before adding a new record, check whether a DMARC record already exists. Look through the list for any entry with _dmarc in the subdomain column.
You might find:
- A TXT record with subdomain
_dmarc - A DMARC record (OVHâs proprietary type) with subdomain
_dmarc
If a record exists: edit it rather than creating a new one. Having two DMARC records for the same domain causes receivers to ignore both. Click the pencil (edit) icon next to the existing record to modify it.
If no record exists: proceed to the next step.
Step 4: add the DMARC TXT record
Click the âAdd an entryâ button on the right side of the DNS zone table.
A panel appears with record type categories:
- Pointing records (A, AAAA, CNAME)
- Mail records (MX, SPF, DKIM, DMARC)
- Extended fields (TXT, SRV, NAPTR, etc.)
Select âExtended fieldsâ then âTXTâ.
Do not select âDMARCâ under âMail records.â Thatâs the limited wizard we discussed earlier. You want a standard TXT record for full control.
Fill in the fields:
| Field | Value |
|---|---|
| Sub-domain | _dmarc |
| TTL | Select âCustomâ and enter 3600 (or leave as default) |
| Value | Your DMARC record from Step 1 |
Example:
Sub-domain: _dmarc
TTL: 3600
Value: v=DMARC1; p=none; rua=mailto:[email protected];
Click Next, then Confirm.
Step 5: verify your record
DNS propagation on OVH typically takes between a few minutes and 24 hours. In most cases, the record is visible within an hour.
To verify, go to DMARCTrustâs domain checker and enter your domain. The DMARC section should show your record with a green status.
You can also verify from the command line:
dig TXT _dmarc.yourdomain.com
You should see your full DMARC record in the response.
Common OVH-specific pitfalls
OVHâs DNS management has a few quirks that are worth knowing.
Pitfall 1: using the DMARC wizard instead of TXT
The most common mistake. OVHâs DMARC wizard creates a proprietary record type that works for basic setups but breaks if you need advanced tags or use third-party DNS tools. Always use a TXT record.
Pitfall 2: âInvalid subDomainâ error
If you get this error when saving, check that:
- The subdomain field contains exactly
_dmarc(with the underscore) - You havenât accidentally included the domain name (OVH appends it automatically)
- There are no trailing spaces or special characters
Pitfall 3: duplicate records
OVH doesnât always prevent you from creating duplicate TXT records with the same subdomain. If you have two _dmarc TXT records, email receivers will see both and likely ignore your DMARC policy entirely. Always check for existing records before adding a new one.
Pitfall 4: proprietary SPF record type
The same advice applies to SPF. OVH has a built-in âSPFâ record type that creates a proprietary entry. Prefer a standard TXT record for SPF too. If you have both an SPF-type record and a TXT record with SPF, receivers may see conflicting data.
Pitfall 5: confusing the TTL default
OVHâs default TTL is 3600 seconds (1 hour). If you leave the TTL dropdown on âDefault,â OVH internally stores it as 0 (meaning âuse zone defaultâ). This works fine in practice, but if you manage DNS with external tools or Terraform, the internal representation can cause confusion or duplicate records. Setting a custom TTL of 3600 explicitly avoids this.
A more complete DMARC record
The record we created in Step 1 is a good starting point for monitoring. Once youâve analyzed your reports and fixed any alignment issues, you can strengthen your record.
Monitoring phase (start here)
v=DMARC1; p=none; rua=mailto:[email protected];
This tells receivers to send reports but take no action on failing emails. Use this phase to discover all your legitimate senders and fix authentication.
Gradual enforcement
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]; fo=1;
This quarantines (sends to spam) 10% of emails that fail DMARC. The fo=1 tag requests forensic reports on any authentication failure, which gives you detailed data on whatâs failing and why. Gradually increase pct as you gain confidence.
Full enforcement
v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; fo=1;
This rejects 100% of emails that fail DMARC, including from subdomains (sp=reject). This is the strongest DMARC policy. It tells receivers: if an email claims to come from our domain and fails authentication, donât deliver it.
Our enforcement playbook details this gradual approach step by step.
Subdomain considerations on OVH
If you send email from subdomains (like news.yourdomain.com or support.yourdomain.com), DMARC has a subtlety worth knowing.
Without a sp tag, your subdomain policy defaults to whatever you set for p. If your root domain has p=reject but a subdomain has its own legitimate email flow you havenât authenticated yet, those emails will be rejected.
You can either:
- Set
sp=noneon your root DMARC record while keepingp=reject, so subdomains stay in monitoring mode - Add separate
_dmarc.subdomainTXT records in OVH for subdomains that need their own policy
To add a subdomain DMARC record in OVH, use the same TXT record process but set the subdomain field to _dmarc.subdomain (for example, _dmarc.news for news.yourdomain.com).
Why monitoring matters more than the record
Adding a DMARC record takes 5 minutes. Understanding whatâs happening with your email takes ongoing monitoring.
DMARC reports are XML files that look like this:
<record>
<row>
<source_ip>192.0.2.1</source_ip>
<count>1247</count>
<policy_evaluated>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>
Gmail, Microsoft, Yahoo, and dozens of other providers send these reports daily. For a single domain, you can receive hundreds of reports per month. Each one contains rows of IP addresses, pass/fail results, and alignment data. Nobody reads these manually.
This is what DMARCTrust was built for. When you add your domain, you get a dedicated reporting mailbox. Every report gets fetched, parsed, and displayed in your dashboard. You see which services are sending as your domain, whether they pass SPF and DKIM, and where the failures are.
Our source insights feature breaks down every sending source by IP, hostname, and email provider, so you know exactly who is sending as your domain and whether theyâre properly authenticated.
When something changes (a DNS record is modified, a new sender appears, authentication starts failing), you get alerted. You donât have to check manually. You donât have to parse XML. You just look at your dashboard.
After OVH: the path to enforcement
Adding the DMARC record on OVH is step one. Hereâs what comes next.
Weeks 1-2: Reports start arriving within 24-48 hours. Review your DMARCTrust dashboard to identify all legitimate senders. Youâll likely find services you forgot about: old marketing tools, CRM systems, transactional email platforms.
Weeks 3-4: Fix alignment issues. Make sure each service is properly authenticated with SPF and DKIM. Our dashboard shows exactly which sources are failing and why.
Month 2: Move to p=quarantine with a low percentage (pct=10). Monitor closely for any legitimate email that gets quarantined. Increase the percentage gradually.
Month 3+: Progress to p=reject. This is where DMARC actually protects your domain, because spoofed emails get blocked and your deliverability improves.
Donât rush this process. The goal is to reach enforcement without blocking a single legitimate email. Monitoring makes that possible.
Check your domain now
Enter your domain in our free checker. Youâll see instantly whether your DMARC, SPF, and DKIM records are properly configured.
If youâre on OVH and havenât set up DMARC yet, the steps above will get you there. But the record alone isnât enough. Without monitoring, you have a policy that nobody enforces and reports that nobody reads.
Sign up for DMARCTrust to get your dedicated reporting address. Add it to your DMARC record. Let us handle the XML. You focus on moving to enforcement.
OVH gives you the DNS. DMARCTrust gives you the visibility to actually use it.
FAQ
Can I use OVHâs DMARC wizard at all?
You can, but we donât recommend it. The wizard doesnât support ruf, fo, sp, or ri tags, which limits your options as you move toward enforcement. A standard TXT record takes the same time to set up and supports everything.
How long does DNS propagation take on OVH?
OVH states up to 24-48 hours. In practice, most changes propagate within 1-4 hours. You can lower the TTL to 300-600 seconds before making changes to speed up propagation, then raise it back to 3600 once your record is stable.
I already have a DMARC record from the wizard. Should I replace it?
Yes. Delete the existing DMARC-type record and create a new TXT record with the same value (plus any additional tags you need). This gives you a standard record that works with all tools and supports all tags.
Do I need to configure anything else on OVH for DMARC to work?
DMARC itself is just a DNS record, so no additional OVH configuration is needed beyond adding the TXT record. However, make sure SPF and DKIM are properly configured for your email services, as DMARC relies on at least one of them passing and aligning.
What if I use OVH email hosting (MX Plan, Exchange)?
The DMARC setup is the same regardless of your email provider. The difference is in SPF and DKIM configuration. For OVH email hosting, include mx.ovh.com in your SPF record and enable DKIM if your plan supports it. The DMARC TXT record at _dmarc works identically.
Can I receive reports at my own email address instead of DMARCTrust?
Technically, yes. You can put any mailto: address in the rua tag. But DMARC reports are XML files, and a busy domain can generate hundreds of them per month. Your inbox will fill up with unreadable attachments. DMARCTrust provides a dedicated mailbox specifically designed to collect, parse, and present these reports in a way thatâs actually useful.