How to set up DMARC on Timeweb

You want a DMARC record on Timeweb, and what that comes down to is one TXT record at the host _dmarc under your domain, holding a short policy string that begins v=DMARC1.

Timeweb is the DNS host and mail provider named in this piece, in both its classic panel and the Timeweb Cloud panel. It publishes whatever record the reader enters in its DNS editor, and for a delegated domain on Timeweb Mail it may already carry a DMARC record of its own before the reader adds anything.

The record comes first on this page, with what each part of it means, and the exact Timeweb fields it goes into come after, because the record is the same wherever your DNS lives and only the form around it changes.

The record before the console

DMARC is the instruction a receiver reads after it has checked SPF and DKIM on a message claiming to come from your domain. Those two checks each return a pass or a fail. DMARC tells the receiver what you want done with a fail, and where to send a summary of what it saw. The instruction lives in DNS because that’s the one place a receiver anywhere in the world can look up something only the domain’s owner can write.

The host is _dmarc, with the _ character at the front, and the type is TXT. The value to start with is:

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

Three tags carry the meaning. v=DMARC1 names the version of the standard and has to come first. p= is the policy: none asks receivers to deliver failing mail as they would have anyway and report on it, quarantine asks them to put failing mail in spam or junk, and reject asks them to refuse it during delivery. rua=mailto: names the mailbox that receives the aggregate reports, which arrive as XML attachments listing which servers sent mail as your domain and whether each one passed.

A message passes DMARC when SPF or DKIM passes and the domain that passed matches the domain in the From header. That matching is called alignment, and it’s why a mail provider’s own SPF record isn’t enough on its own: the check has to succeed for your domain, since that’s the one the reader sees.

Other tags turn up in records elsewhere. sp= sets a separate policy for subdomains and defaults to whatever p= says; the subdomain policy piece covers when it’s worth setting. pct= applies the policy to a share of failing mail. adkim= and aspf= switch alignment from relaxed to strict, and ruf= asks for per-message forensic reports, which most large receivers don’t send. Leave all of these out at the start; the three-tag record above is complete and valid.

Start at p=none. Publish p=reject before you know your SPF and DKIM pass on your own mail and you’ll bounce your own invoices along with the forgeries. The reports are how you find that out, so the rua= address has to be a mailbox somebody opens.

Check that Timeweb answers DNS for the domain

The Timeweb DNS editor only affects a domain that is delegated to Timeweb’s own nameservers. Open the domain’s row in «Домены и SSL» (Domains and SSL) and check the nameservers listed there against what the registrar shows. If the nameservers point at a different host, a CDN or the email provider instead, the record has to go in wherever that other provider answers DNS, because the Timeweb editor will save the entry and still do nothing.

For a delegated domain using Timeweb Mail, Timeweb can publish a _dmarc record on its own without the reader adding one. For every other domain, Timeweb publishes only the exact TXT record the reader types into the DNS editor and saves.

Publish SPF and DKIM before DMARC. The policy tells receivers what to do when those checks fail, so a domain with neither has nothing for DMARC to work from, and a p=reject on such a domain refuses everything that carries its name.

Add the record in the Timeweb console

Sign in to Timeweb and open «Домены и SSL» (Domains and SSL), then «Мои домены» (My domains).
In the Timeweb Cloud panel, open «Домены и SSL» and then the domain’s own DNS tab instead.
Click the row for the domain in question to open its settings.
Open the «Редактор DNS» (DNS editor) tab for that domain.
Check the existing rows first for a record already named _dmarc, since Timeweb Mail can add one automatically on a delegated domain.
If a _dmarc record already exists, open that row to edit it rather than clicking «Добавить запись» (Add record) again.
If none exists, click «Добавить запись» (Add record) to start a new row.
Set the record type field to TXT.
In the «Хост» (Host) field, enter exactly _dmarc, since Timeweb appends the domain name for you.
In the «Значение» (Value) field, paste the record value with no surrounding quote marks, leave TTL at the panel default, and save.

The type field takes TXT. The «Хост» (Host) field takes only _dmarc, since Timeweb appends the domain name itself, so typing _dmarc.yourdomain.com in full duplicates the domain and typing dmarc without the leading _ character names the wrong record. The «Значение» (Value) field takes the plain string starting v=DMARC1; with the mailbox after rua=mailto: replaced by an address the reader reads, and with no quote marks added around it. TTL stays at whatever the panel sets by default.

Look for an existing TXT record at _dmarc before you add one. A domain gets one DMARC record, and a receiver that finds two treats the domain as having none, so if one is already there you edit it. Paste the value without surrounding quotation marks and without a trailing space or line break, then compare the last few characters against the record above once it’s saved.

Traps in the Timeweb form

Timeweb’s own docs say a DMARC record is applied automatically for a delegated domain using Timeweb Mail, so a _dmarc row can already be sitting in the DNS editor before the reader opens it.
Two DMARC records at the same name is treated as no valid record at all, so an existing _dmarc row has to be edited, never added to.
Dropping the leading _ character, or typing the full _dmarc.yourdomain.com in the Host field, both produce the wrong name because Timeweb appends the domain automatically.
Pasting the value with manual quote marks around it can break the record, so the plain string starting v=DMARC1; goes in unquoted.
The DNS editor saves a record regardless of where the domain’s nameservers point, so a domain not delegated to Timeweb gets a saved but inactive row.

A record that’s present and malformed is worse than an absent one in a single respect: it looks done. v=DMARC1 missing from the front, p= misspelt or left out, a rua= without mailto: in front of the address, or curly quotes pasted in from a document all produce a record receivers can’t parse and so ignore. The DMARC typos piece lists the ones that show up most often in the census.

With those checked and the record saved, run the free scan below. It looks up _dmarc on your domain the way a receiving mail server does and tells you whether the record is present, whether it parses, and which policy it carries.

Wait, then read the result

The change is not instant, so the reader should re-check rather than assume it has taken effect. The saved record appears as a row in the same «Редактор DNS» (DNS editor) tab where it was entered.

Run the free scan on this site to confirm the record is published and to see which policy it currently carries.

A scan run in the first minutes after saving can read as absent while nothing is wrong, because a resolver somewhere is still handing out its cached answer from before the record existed. If the scan still reports no DMARC after a couple of hours, go back to the nameserver check at the top of this page first and the host name second.

A record saved into a console that isn’t answering DNS for the domain is the most common reason a scan comes back unchanged, and the fix is to add the same record at the company the nameservers point to.

When the scan shows the record and its policy, you’re in the monitoring stage. Nothing about delivery has changed yet, and the first reports take a day or so to arrive.

Tightening from none to reject

p=none leaves delivery as it was and starts the reports arriving. Those reports are the only evidence you’ll get about what sends as your domain: your mail provider, a newsletter tool, an invoicing system, and whatever else somebody connected two years ago. Each report names the sending server, how many messages it sent, and whether SPF and DKIM passed for them. The DMARC piece explains how to read one and what a failing row means.

Without a record, a receiver that sees a message fail both checks has no instruction from you, so most deliver it anyway and nobody tells you. Of the 316,600,902 domains carrying a grade in the September 2026 census, 238,156,049 (75.2%) have no DMARC record at all. The monitoring stage has its own trap: of the domains whose DMARC record carries p=none, 33,651,068 (80.33%) have no rua= address, so they sit at none collecting nothing that would let them move.

Read the reports until every sender you recognise is passing and the failing rows are ones you don’t. Then change p=none to p=quarantine in the same field you saved it in, wait for a further round of reports to confirm your own mail still lands, and change it to p=reject. That last edit is the one that turns a monitoring record into an instruction receivers act on, and it takes the same minute in the Timeweb console as the first one did.

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