Defaults.Exposed

Defaults.Exposed › Setup walkthroughs › DMARC › REG.RU

Add a DMARC record on Reg.ru

Check which nameservers the domain uses before touching any record, because Reg.ru has two consoles and only one of them holds the live zone for any given domain. The wrong one accepts the record and publishes nothing.

Which console is live

If the nameservers read ns1.reg.ru and ns2.reg.ru, the personal account zone editor is the live zone and the steps below apply. If they read ns1.hosting.reg.ru and ns2.hosting.reg.ru, the personal account editor is not where the live records sit; use the hosting control panel instead. If the nameservers point at a different company, such as another host, a CDN (Content Delivery Network), or the mail provider, the DMARC (Domain-based Message Authentication, Reporting and Conformance) record belongs there, not on Reg.ru.

Reg.ru is the domain registrar and, when the domain uses its own nameservers, the DNS (Domain Name System) host as well. You supply the DMARC text, and Reg.ru stores exactly the subdomain and text values you enter and serves them from its own nameservers once you save the record.

The DMARC record for Reg.ru

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

v=DMARC1 is the version tag and has to lead. p=none is the policy value, the one that instructs nothing. rua=mailto: is the address aggregate reports go to.

Start here rather than at p=reject. At p=none nothing is blocked and no message is treated differently; the policy moves up only after the reports show it is safe to move it.

Add the record in the Reg.ru console

  1. Sign in to the Reg.ru personal account, the «личный кабинет».
  2. Open the «Домены» (Domains) section and click the row with your domain.
  3. Find the «DNS-серверы и управление зоной» (DNS servers and zone management) block.
  4. Click «Изменить» (Edit) to open the zone editor for that domain.
  5. Click «Добавить запись» (Add record) to start a new record.
  6. Select TXT as the record type from the type list.
  7. In the subdomain field, enter exactly _dmarc and nothing after it.
  8. In the text field, enter v=DMARC1; p=none; rua=mailto:you@yourdomain.com with your own reporting address in place of the example.
  9. Click «Готово» (Done) to save the record.

In the subdomain field enter _dmarc only: Reg.ru appends the domain itself, so typing _dmarc.yourdomain.com produces the wrong host. In the text field paste the plain value starting v=DMARC1; with the rua address changed to a mailbox you read; Reg.ru’s editor does not expose a separate TTL (Time to Live) field for this record type.

Traps in the Reg.ru form

Reading the reports without a parser

Aggregate reports arrive as XML, compressed, attached to an email, usually one per day per receiving provider. You do not need a tool to read your first few, and reading a couple by hand is the quickest way to understand what the tool would be showing you.

Inside, each report names the receiving organisation, the date range, and the policy it saw published on your domain. Then comes a list of records, one per sending IP (Internet Protocol) address, each with a count of messages and the SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) results for them. What you want from each row is three things: how many messages, from which source, and whether either check passed in a way that lined up with your domain.

Sources you recognise that are failing are the work list. A newsletter platform with no DKIM key on your domain, an invoicing tool sending from its own servers with no SPF include, a website form relaying through the host. Each gets fixed at that service rather than in this record.

Sources you do not recognise deserve a look. Most turn out to be a forwarding service or a tool someone in the business signed up for. Forgery shows up too. At p=none it is still delivered, which is the reason to move the policy up once the legitimate list is clean.

Volume makes hand-reading impractical after a week or two, and at that point a parser or a hosted reporting service pays for itself.

The three policies, and the safe way between them

p= carries one of three values. none asks for nothing but reports. quarantine asks receivers to treat failing mail as suspicious, which usually means the spam folder. reject asks them to refuse it outright.

pct= is what makes the move between them safe. v=DMARC1; p=quarantine; pct=10; rua=mailto:you@yourdomain.com applies the policy to a tenth of failing messages and leaves the rest as they were, so an overlooked sender costs you a tenth of the damage and still appears in the reports. Raise the number as the picture stays clean, then drop the tag and move to reject.

Two tags exist for later. sp= gives subdomains their own policy, useful when a marketing platform sends from one and the parent is already strict. adkim= and aspf= set whether alignment is relaxed, the default, or strict, with relaxed being right in nearly every case because it allows a subdomain to satisfy the parent domain.

Neither belongs in a first record. Publish the three-tag version and read the reports first.

Wait, then read the result

A saved change in the Reg.ru zone editor takes minutes up to a couple of hours before receiving mail providers see it. The saved record appears as a TXT row for _dmarc inside the same DNS servers and zone management block you edited. Reopen that block and confirm the _dmarc TXT row shows the value you saved.

How the scan grades this record: the DMARC policy check, with its pass and fail rules and how many domains pass it.

Most domains never get this far: 249,025,625 (74.9%) in the October 2026 census publish no DMARC record, and of those at p=none, 35,049,364, or 80.17%, carry no rua= address to collect anything with.

Once the report list holds nothing failing that you care about, raise the policy to p=quarantine, then later to p=reject. Receivers act on the record only at p=quarantine or p=reject.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.