OVH DMARC Setup: Add the DNS Record

OVHcloud provides two DMARC entry methods. The simplified DMARC form generates a TXT answer. The general TXT editor lets you enter the policy string yourself. Both publish DMARC through DNS.

This guide follows OVHcloud’s DMARC documentation, last updated July 31, 2026, and RFC 9989. We verified the control-panel path in August 2026.

OVHcloud’s documentation still describes pct, rf, and ri. RFC 9989 made those tags historic in May 2026. Do not add them to a new policy. Use t=y for policy test mode.

From the OVHcloud zones we review, the recurring errors are duplicate _dmarc records and an SPF value copied for the wrong OVHcloud product or region. The DNS interface is rarely the root cause.

DMARC form or TXT record?

Use the simplified DMARC form when it supports the active tags you need. Use the TXT editor when you need a tag that the form does not expose, such as adkim, ruf, fo, np, psd, or t.

The simplified form is not a proprietary DNS record. OVHcloud states that DNS servers read it as TXT. The practical difference is the set of fields available in the control panel.

For a new deployment, a short TXT value is usually easier to audit:

v=DMARC1; p=none; rua=mailto:[email protected];

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

OVHcloud also has an SPF form. It publishes the SPF policy through TXT. If you use additional email services, include the sources that actually use this domain as their envelope sender in one 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 OVHcloud hosts your mail, identify the exact email product and platform before changing DKIM. OVHcloud has multiple MX Plan generations, Email Pro, Exchange, and Zimbra services. Their signing controls are not interchangeable. Use the documentation and settings for the service shown in your control panel.

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 record created through OVHcloud’s DMARC form 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.)

For the value in this guide, select TXT and enter the policy directly. You can also use OVHcloud’s DMARC form if it exposes every active tag you plan to publish.

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 depends on the record TTL and resolver caches. Confirm the record at OVHcloud’s authoritative nameservers first. Then allow cached answers to expire.

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 OVHcloud pitfalls

OVH’s DNS management has a few quirks that are worth knowing.

Pitfall 1: assuming the DMARC form is not TXT

OVHcloud says the simplified DMARC entry is read as TXT by DNS servers. Use the TXT editor only when you need fields the form does not expose or want direct control of the string.

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: duplicate SPF policies

Whether you use OVHcloud’s SPF form or the TXT editor, receivers see TXT. Do not publish a second v=spf1 value at the same hostname.

Pitfall 5: following the obsolete pct example

OVHcloud’s July 2026 page still shows pct=100. RFC 9989 now lists pct as historic. Omit it. A policy without pct applies normally. Use t=y when you need the new test-mode behavior.

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.

Quarantine dry run

v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected];

This asks receivers to apply the next-lower policy while you test quarantine. Add ruf and fo only if you have a clear need for message-specific failure reports and a service that can receive them. RFC 9989 says fo is ignored without ruf.

Reject, where appropriate

v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject;

This requests reject for failing mail, including mail from subdomains (sp=reject). RFC 9989 section 7.4 warns that domains with users who post to Internet mailing lists can create interoperability problems with p=reject. Evaluate those flows before using 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 is a short DNS change. Understanding the senders 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>

Participating receivers send these reports on their own schedules. Each file can contain many rows of IP addresses, pass/fail results, and alignment data. RFC 9989 recommends machine parsing.

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.

DMARCTrust also monitors DNS and can alert you when a record changes or authentication starts failing.

After OVH: the path to enforcement

Adding the DMARC record on OVH is step one. Here’s what comes next.

Inventory: Wait until the reports cover every normal sending cycle. Identify legitimate and unknown sources.

Remediate: Fix alignment for each legitimate sender. Test the final delivered message.

Test enforcement: Publish p=quarantine; t=y. Remove t=y when report data shows no legitimate impact.

Choose the final policy: Keep quarantine or consider reject based on the domain’s users and indirect mail flows.

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 use OVHcloud DNS, the steps above publish the policy. Monitoring then shows whether real mail passes it.

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.

OVHcloud hosts the DNS record. DMARCTrust processes the reporting data.

FAQ

Can I use OVH’s DMARC wizard at all?

Yes. OVHcloud states that the simplified entry is read as TXT. Use it when the form supports the active tags you need. Use the TXT editor for tags the form does not expose.

How long does DNS propagation take on OVH?

Propagation depends on the record TTL and resolver caches. Check the authoritative OVHcloud response first, then allow existing cached answers to expire.

I already have a DMARC record from the wizard. Should I replace it?

No. Do not replace it only because it was created through the simplified form. Keep one valid policy. Edit or replace it only when you need different tags or a reporting destination.

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?

Yes. You can put a mailbox you control in the rua tag. Aggregate reports are XML and are designed for machine processing. DMARCTrust provides a dedicated address, validates incoming reports, and presents the data by source and authentication result.