| 12 min read

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.

DT
Marc, Owner
How to configure DMARC on OVH (the right way)

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=none on your root DMARC record while keeping p=reject, so subdomains stay in monitoring mode
  • Add separate _dmarc.subdomain TXT 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.

Read Next

View all posts
How to add an SPF record in GoDaddy (step-by-step)
dmarc-setup ·

How to add an SPF record in GoDaddy (step-by-step)

GoDaddy hosts your domain but doesn't create SPF records for you. Here's how to add SPF and configure it alongside DMARC in the GoDaddy DNS interface, with exact steps and common pitfalls to avoid.

DT
DMARCTrust
9 min read
From p=none to p=reject: how to enable DMARC enforcement in 2026
dmarc-setup ·

From p=none to p=reject: how to enable DMARC enforcement in 2026

Forums show the same anxiety pattern: 'I want p=reject, but I'm afraid I'll block legit mail.' The rollout is mostly about gates: inventory done, alignment fixed, SPF lookup limit avoided, and then staged enforcement.

DT
DMARCTrust
3 min read