Defaults.Exposed › Setup walkthroughs › SPF › Beget

How to set up SPF on Beget

Beget already publishes an SPF (Sender Policy Framework) record for domains on its hosting, and it is written in a form that hands the whole policy to Beget. The line reads v=spf1 redirect=beget.com. Adding Google Workspace, Microsoft 365 or a newsletter tool means rewriting the line, and adding a second v=spf1 record next to it breaks SPF for the domain.

How redirect= differs from include:

An SPF record is a single line of DNS (Domain Name System) text listing who may send mail as your domain. include: pulls in another party’s list and keeps going with yours. redirect= works differently: when nothing earlier in your record matched, the receiver evaluates somebody else’s policy instead, including its final all term. Your record then ends on Beget’s terms. Add your own all term to the same line and receivers ignore the redirect= entirely.

So the clean fix is a rewrite, and it is the change Beget’s own help describes. Take the senders you actually have, name each with its own include:, and finish the line yourself:

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

Compare that block against what your mail provider’s own setup page tells you to publish.

Keep include:beget.com in the rewritten record if the website or Beget mailboxes still send mail. Dropping it breaks the mail that was working before you started.

The example ends in ~all, and -all is the other choice. -all lets a receiver reject mail from an unlisted server on SPF alone, which can bounce forwarded mail before DKIM (DomainKeys Identified Mail) is checked. ~all marks that mail as a soft fail and leaves the decision to your DMARC (Domain-based Message Authentication, Reporting and Conformance) policy. Both endings are defensible; whichever you choose, list every sender first. In the October 2026 census, 87,173,390 domains (26.2%) end their record on softfail.

Check Beget is the one answering

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.

What Beget supplies and what you supply

Beget is the hosting provider and DNS host for the domain, and it publishes its own SPF entry for domains on its hosting. That is correct as it stands if Beget’s servers are the only thing sending the domain’s mail. It does not generate a value for a second sender; you take that value from the second provider’s own help page and add it to the record Beget already created.

Edit the record in Beget

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

The host or name field takes the domain itself, since this is an apex record and Beget’s Quick add block asks you 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 its own help describes.

Traps on this console

• 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.
• The default v=spf1 redirect=beget.com form leaves the final verdict to Beget’s record, so adding a sender means rewriting it in the include: form with your own all term at the end.
• Beget’s panel can display in Russian or English, and the exact button labels differ between panel versions.
• Every include: costs DNS lookups, and a record that needs more than ten of them to evaluate fails with a permanent error rather than degrading. Three or four senders is fine; a dozen is where this starts to matter.

Reading the line you ended up with

Once you have rewritten the record, it is worth being able to read it back, because the terms are not self-explanatory and the next person to touch it may be you in a year.

include:beget.com pulls in Beget’s own published list of sending servers. Whatever Beget adds or retires on its side is picked up automatically, which is why an include is better than typing Beget’s IP (Internet Protocol) addresses in by hand. include:_spf.google.com does the same for Google. Terms you may also meet in an inherited record are a, meaning the domain’s own web server address, mx, meaning whatever answers mail for the domain, and ip4: followed by a single address or a range.

The term that catches people out is a site sending its own mail. A contact form or an order confirmation sent by the website itself leaves from Beget’s servers, so it is covered by include:beget.com and stops being covered the moment that include is dropped. If the site goes quiet on order emails a week after you edited this record, that is the first thing to check.

The mechanisms can go in any order. The all term has to come last, because evaluation stops there. Anything written after it is ignored.

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.

Then run the free scan against your domain. It reads the record back the way a receiving mail server reads it and tells you what the line actually resolves to.

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

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. That one glance catches the most common outcome, which is an edit that was never saved.

SPF is checked against the envelope sender, and the address a reader sees in their mail client plays no part in it. Some receivers reject on an SPF hard fail by itself; a receiver that applies DMARC follows your DMARC policy, which is what ties the check to the visible From address. The SPF guide covers the mechanics from the receiving side.

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.