Last updated: July 2026

In short: After this guide your domain at OVHcloud publishes a DMARC record. It tells receiving servers what to do with mail that fails SPF and DKIM — and sends you reports on who sends in your name.

Prerequisites

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Compliance) ties SPF and DKIM together into a policy. OVHcloud is explicit that it “is based on the results of the” SPF and DKIM checks: when both fail, DMARC tells the receiver what to do — deliver, quarantine, or reject — and can send you aggregate reports about who is sending mail as your domain.

That’s why the prerequisite matters. OVHcloud states that at least one of SPF or DKIM “must be configured in the DNS zone of the email solution domain name” before DMARC does anything useful. Set up SPF and DKIM first.

The starting point at OVHcloud

OVHcloud gives you two ways in the DNS-zone assistant: “There are two ways to configure the DMARC in your OVHcloud DNS zone” — a simplified DMARC record where you fill in fields, or a plain TXT record where you write the full string yourself. Both end up as a TXT record under _dmarc.

Step-by-step guide

1. Open the DNS zone and add an entry

Log in to the OVHcloud Control Panel, click the Web Cloud tab, select the domain in the Domain names section, and open the DNS zone tab. Click Add an entry, then choose the DMARC (“Mail records”) assistant.

2. Fill in the fields

  • Sub-domain: this entry must start with _dmarc. For the whole domain, enter nothing but _dmarc.
  • Version (v=): OVHcloud calls it a “Mandatory field determining the version of the DMARC protocol.” — always DMARC1.
  • Policy (p=): what receivers should do on failure. none means “The domain holder does not request any specific action regarding message delivery.” quarantine treats failing mail as suspicious; reject “Rejects emails that fail the DMARC verification.”
  • rua=: “Addresses to which reports should be sent” — the mailto: prefix is required.

That produces a record like:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

3. Start at p=none

Resist the urge to jump straight to reject. OVHcloud recommends the same: “It is recommended that you configure” p=none “and perform a failure report analysis for several weeks”, in order to resolve anomalies first. For a gradual rollout you can also use the pct= tag — its purpose “is to enable domain name holders to adopt a slow implementation of the DMARC mechanism.”

4. Tighten to quarantine, then reject

Once the reports show that all your legitimate sources pass SPF or DKIM, raise the policy:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@beispiel.de

and finally, when you’re confident:

v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de

5. Wait until the change is live

DNS changes take a few hours depending on TTL and caching.

The tags in detail

TagMeaning
v=DMARC1version identifier, mandatory
p=policy: none, quarantine, or reject
pct=percentage of mail the policy applies to (0–100, default 100) — for gradual rollout
rua=address for aggregate reports (mailto: required)
sp=separate policy for subdomains
aspf= / adkim=SPF/DKIM alignment mode (r relaxed, s strict)

Verify the result

Check your configuration with the free MXAudit scanner — it reads your policy and flags an inconsistent setup. Or in the terminal:

dig TXT _dmarc.example.com +short

Common mistakes

DMARC without SPF or DKIM. DMARC evaluates the results of both — with neither configured, it has nothing to build on. Set up SPF and DKIM first.

Jumping straight to p=reject. Without a report phase you can’t see which legitimate sources still fail — and you’ll silently reject your own mail. Start at none and watch the reports.

Record at the wrong name. The DMARC record lives at _dmarc.your-domain, not on the bare domain. In the OVHcloud assistant the sub-domain field must start with _dmarc.

No rua address. Without a report address you’re flying blind — you never learn who sends as your domain or whether legitimate senders fail.

Further reading