How to set up SPF on Beget

Setting up SPF on Beget comes down to one TXT record at the root of your domain, holding a line that starts v=spf1 and names the servers allowed to send mail as you.

Beget is the hosting provider and DNS host for the domain, and it publishes its own SPF entry for domains on its hosting. It does not generate a value for a second sender; the reader takes that value from the second provider’s own help page and adds it to the record Beget already created.

The order below is the record first and the console second, because the pasting takes two minutes and the thinking is all in the line itself.

What the record says, and why it lives in DNS

SPF (Sender Policy Framework) is a published list of the sources that may send mail for your domain. When a mail server receives a message with your domain in the return path, it fetches the TXT record at that domain, checks whether the connecting server’s address is on the list, and writes the result into the message headers for the filters that run afterwards.

That lookup goes to whichever nameservers the registry lists for your domain, and to nowhere else. This is why the record has to be published where your DNS is answered, and why a record saved in the wrong console is invisible to the world, however correct its text.

A record saved at Beget only takes effect if Beget is the one answering DNS questions for the domain. That is the default when the domain was registered at Beget or the site is hosted there and the nameservers were never changed. Open the DNS section in the Beget control panel and check what the domain’s zone shows. If the nameservers point at Cloudflare, another host or a mail provider instead, the record has to be added there, and anything saved at Beget does nothing.

Read the record before you paste it

An SPF record is a single string with three parts: the version tag, a list of mechanisms, and a closing catch-all. The version tag is always v=spf1, and a TXT record without it isn’t SPF at all.

Mechanisms come next, separated by spaces, and each one names a source of legitimate mail. include: pulls in another domain’s SPF record, which is how you authorise a mail provider or a newsletter tool: you name the hostname they publish and their list becomes part of yours. ip4: and ip6: name an address or a range directly, for a server you run yourself. a and mx authorise the hosts behind your domain’s own A and MX records.

redirect= hands the whole evaluation to another domain’s record; it’s a modifier rather than a mechanism, it can’t sit alongside an all, and it matters here because some hosts publish a record in that form on your behalf.

Each mechanism can carry a qualifier in front of it. + means pass and is the default, so include: and +include: are the same thing. - means fail, ~ means soft fail, and ? means neutral. The one qualifier that decides anything is the one on the last term.

That last term is all, and it says what to do about a source the mechanisms didn’t match. -all asks the receiver to fail unlisted mail. ~all asks it to accept the message and mark it suspect. ?all says nothing useful, and +all authorises the entire internet, which is worse than publishing no record.

Start with ~all while you’re confirming that the list is complete, then move to -all once a few weeks of ordinary sending have passed without a legitimate source turning up as unlisted. The choice between the two endings has its own page. Of the 316,600,902 domains carrying a grade in the September 2026 census, 84,153,064 (26.6%) end their record in ~all.

Two limits shape what you can put in the list. A domain gets one SPF record: a receiver that finds two TXT records starting v=spf1 treats the domain as having a permanent error, which counts the same as having none.

A record may also trigger at most ten DNS lookups during evaluation, counting each include:, a, mx and redirect= plus the lookups inside any record they pull in; an eleventh lookup fails the whole record. So a second sender goes into the existing record as another include:, and if the count is getting high, the mail provider’s help page usually says which of its hostnames costs the fewest lookups.

The record for Beget

Beget publishes an SPF record of its own for domains on its hosting, in the form v=spf1 redirect=_spf.beget.com, which delegates the whole policy to Beget. That is correct as it stands if Beget’s servers are the only thing sending the domain’s mail. Adding a second sender is left entirely to the reader, who must rewrite that line themselves.

v=spf1 include:_spf.beget.com include:_spf.google.com ~all

Compare that block against what your mail provider’s own setup page tells you to publish. The include: hostname has to match theirs character for character, because it’s a DNS name the receiver will resolve, and a typo resolves to nothing. If you send from more than one service, each gets its own include: in the same line, in any order, before the all.

Enter the record, click by click

Sign in to the Beget control panel.
Open the DNS section and select the domain in the list at the top.
Next to the domain’s main zone, click «Открыть режим редактирования» (Open editing mode).
Find the existing TXT record starting v=spf1 and edit it to add the second sender.
If no such record exists, use the «Быстрое добавление» (Quick add) block instead.
In Quick add, choose the domain itself as the target for the new record.
Set the record type field to TXT.
Paste the rewritten SPF text into the data field, then save the record.

The type field takes TXT. The host or name field takes the domain itself, since this is an apex record and Beget’s Quick add block asks the reader to choose the domain rather than type a subdomain. The data or value field takes the full SPF text starting v=spf1, pasted as plain text with no surrounding quote marks, since adding a " can corrupt the record. Beget does not ask for a TTL on this record in the flow the source describes.

Before you save, read the value back once. The whole string sits on one line with single spaces between terms, no line break, no trailing space, and nothing after the all. If the form already shows a TXT record beginning v=spf1, you’re editing that one, and the only reason to be adding a new row is that no such record exists.

Some of the mistakes on this form belong to this console rather than to SPF.

Beget’s panel can display in Russian or English, and the exact button labels differ between panel versions.
Only one v=spf1 TXT record is allowed per domain. Two of them is treated as broken by mailbox providers, and Beget often pre-creates one, so the correct move is to edit it rather than add another.
redirect= and include: do not mix. The default v=spf1 redirect=_spf.beget.com form cannot have a second sender bolted onto it, so the record has to be rewritten in the include: form and ended with ~all.
Keep include:_spf.beget.com in the rewritten record if the website or Beget mailboxes still send mail.
~all is softfail, meaning anything not listed is treated as suspicious, while -all is hardfail, meaning anything not listed is rejected. Start at ~all and tighten to -all once the sender list is known to be complete.

Wait, then check it

Changes saved in the Beget panel are not instant and can take from a few minutes up to a couple of hours to spread. The saved record shows in the domain’s DNS zone list in the same DNS section used to edit it.

Once the change has had time to spread, run the free scan against your domain. It fetches the record the way a receiving mail server would, reports whether one is present, whether it parses, how many lookups it costs and which qualifier it ends on, and it checks DKIM and DMARC in the same pass.

Reopen the domain’s DNS section in the Beget panel and check that the TXT record now reads the rewritten include: line rather than the original redirect= form.

If the scan reports no record when you’ve saved one, the order of suspects is the nameserver check at the top of this page, then a second v=spf1 row that has been sitting in the zone for years, then a value the form mangled on the way in. A record that’s present but reports as invalid is nearly always one of the limits above: two records, too many lookups, a redirect= with an all after it, or quote marks that ended up doubled.

What a missing or broken record costs you

Of the 316,600,902 domains carrying a grade in the September 2026 census, 166,497,698 (52.6%) publish no SPF record at all. For any of them, a receiver has no list to check the sending server against, so mail from the real mailboxes and mail from a forger’s server arrive carrying the same amount of evidence. Your genuine messages then depend on the receiver’s other filters, and a share of them land in spam for no reason you can see.

A malformed record ends in the same place. A permanent error reads as no policy, and some receivers treat a domain that publishes a broken policy less kindly than one that publishes nothing.

What SPF does on its own is narrower than people expect. It authorises the server, judged against the envelope sender that the recipient never sees, and the result is a header line rather than an instruction. A forged message that fails SPF can still be delivered, because until a DMARC policy tells receivers what to do with a failure, they’re under no obligation to do anything with it.

SPF is the list, DMARC is what turns the list into an instruction receivers act on, and the SPF guide covers how the two fit together and how to read the result headers on a message you’ve sent yourself.

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.