An SPF record lists who may send mail as your domain. Two limits — one record and ten DNS lookups — cause most of the failures.
An SPF record is a TXT record in your domain’s DNS listing the servers permitted to send mail on its behalf. A receiving server checks the sending IP against that list and gets a pass, a fail, or a soft fail. It is the simplest of the email authentication mechanisms and the one most often quietly broken.
Two rules cause most problems. A domain must publish exactly one SPF record — two records mean the check fails outright, not that the lists are merged. And evaluating the record must not require more than ten DNS lookups; exceeding that produces a permanent error, and each `include:` for a sending platform can consume several.
The choice between `-all` and `~all` matters less than it used to, because DMARC decides the outcome, but `-all` remains the correct end state once you are confident the list is complete.
SPF breaks on forwarding by design: the forwarding server is not in your record, so the check fails at the destination. This is not a fault to fix in SPF — it is why DKIM exists, and why DMARC alignment should rest primarily on DKIM. An email bounce caused by forwarding is the usual way this surfaces.
SPF is DNS, not mail. It is published as a TXT record on the domain, propagates on DNS timescales, and is edited wherever the domain’s zone is managed — which in many companies is neither the person who runs the mail platform nor the one who noticed the problem. Knowing who holds the zone is half of fixing it quickly.
Ettex Sites manages the domain and its DNS records alongside the site, so the TXT record, the MX records and the mail configuration are edited in one place rather than across three logins. What the record cannot do is authorise mail you have not listed, and where a provider is missing, the fix is the inventory rather than a wider policy.
No. A domain must publish exactly one. Multiple TXT records starting with the SPF version tag cause a permanent error, and mail from every listed source can start failing.
The evaluation returns a permanent error, and receivers treat it as a failure. Reducing includes or replacing them with explicit IP entries is the fix.
Use ~all while you are still discovering senders, and move to -all once the inventory is complete and DMARC reports are clean.
DMARC relies on SPF or DKIM passing with alignment. You can technically pass on DKIM alone, but publishing SPF is standard and receivers use it in their own assessments.
Hreflang is the tag that stops your German page competing with your English one. It is also the tag most often implemented wrongly — and a broken implementation is worse than none at all.
Raising average order value is usually cheaper than winning more customers, and most shops leave it alone because the tactics feel pushy. Done properly they are the opposite — they answer questions the buyer already has.
A privacy policy is a disclosure, not a disclaimer. Generated from a template it describes a business that is not yours — and the first person to notice is usually the regulator or the customer who asked a question.