With a SPF record do you determine which mail servers or sending systems are authorized to send emails on behalf of your domain.
If you use SpamExperts for outgoing email filtering and your messages are sent via the SpamExperts infrastructure, this infrastructure must be included in your SPF record.
The designated SpamExperts SPF mechanism is:
include:spf.antispamcloud.com
Important: SPF is a DNS record for your sender domain. It is not set up in the email client. Changes are made where the DNS zone of your domain is managed.
What is SPF? #
SPF stands for Sender Policy Framework. A domain publishes via DNS which systems are authorized to send emails for this domain.
A receiving mail server can retrieve the SPF record and check whether the actually sending server is authorized by the published policy.
Simplified, the verification works like this:
Email is sent
↓
Receiving mail server
↓
Retrieve the SPF record for the sender's domain
↓
Is the sending server authorized?
↙ ↘
Yes No
↓ ↓
SPF check passed SPF check failsSPF is thus an important component of modern email authentication.
Why does SpamExperts need an SPF record? #
If your outgoing emails are sent via SpamExperts Outgoing Filtering, the SpamExperts infrastructure handles the forwarding of the messages to the external recipients.
The receiving mail server thus sees SpamExperts as part of the routing path.
Therefore, the SpamExperts systems must be authorized for this sending by the SPF record of your domain.
SpamExperts provides the following include mechanism for this purpose:
include:spf.antispamcloud.com
This integrates the sending servers provided by SpamExperts via their own SPF configuration.
Do not confuse SPF and SpamExperts Incoming Filtering #
A common misconception is to equate SPF with the MX records for SpamExperts.
Although both settings are located in the DNS, they serve completely different purposes.
| DNS setting | Task |
|---|---|
| MX | Define where incoming emails for your domain are delivered |
| SPF as TXT record | Define which systems are allowed to send emails on behalf of your domain |
For SpamExperts Incoming Filtering, the MX records are set to the SpamExperts infrastructure.
We explain the complete setup under Set up SpamExperts incoming filtering and configure MX records.
When do you need SpamExperts in the SPF record? #
The entry is relevant if outgoing emails from your domain are sent via SpamExperts Outgoing Filtering.
If SpamExperts is used exclusively for incoming email filtering, that does not automatically mean that SpamExperts also has to be entered as an outgoing sending system in SPF.
Briefly explained: Incoming filtering and outgoing filtering are two separate functions. An MX record for inbound messages says nothing about which systems your domain uses to send emails.
We explain how to set up the outgoing filter at Set up SpamExperts Outgoing Filtering.
Where is the SPF record stored? #
SPF is listed as TXT record published in the DNS zone of the domain.
Typically, the entry is located on the main domain, for example:
example.ch
The exact name or host that needs to be entered in the DNS editor depends on the DNS system being used. Some systems expect the complete domain, while others use, for example, @ for the main domain.
Example: SpamExperts is the only authorized sending system #
If SpamExperts is the only system that should send emails for your domain, an SPF record can look like this, for example:
v=spf1 include:spf.antispamcloud.com -all
The components mean:
| Component | Meaning |
|---|---|
v=spf1 | Mark the TXT record as SPF version 1 |
include:spf.antispamcloud.com | Authorize the SPF systems published by SpamExperts |
-all | Other unauthorized shipping sources should be considered invalid during SPF checking |
Attention: Do not copy this example blindly if your domain also sends emails via other systems. All legitimate sending sources must be taken into account in the SPF configuration.
Check first whether an SPF record already exists #
Before creating an SPF record, you should check whether a corresponding TXT record already exists for your domain.
An existing SPF record begins with:
v=spf1
For example, an entry for another email service might already exist.
In this case you should no second independent SPF record create.
Important: A domain should not have multiple separate SPF records with
v=spf1publish. If an SPF record already exists, the required sending sources must be combined into a single SPF policy.
Add SpamExperts to existing SPF record #
If an SPF record already exists and SpamExperts is additionally used as an outbound sending system, the existing record must be updated accordingly.
Assuming an existing record schematically reads:
v=spf1 include:example-mail-provider.com -all
Then a combined configuration could look like this, for example:
v=spf1 include:example-mail-provider.com include:spf.antispamcloud.com -all
This is merely a framework. Which further mechanisms are actually required depends on which systems send emails for your domain.
The all-Element belongs at the end #
Mechanisms such as -all complete the SPF evaluation for all previously unrecorded sending sources.
New authorized shipping sources must therefore before the final all- mechanism to be inserted.
Example:
v=spf1 include:example.com include:spf.antispamcloud.com -all
It would not make sense to simply place an additional include mechanism behind an already concluding -all to set.
What does mean -all? #
The minus sign in front of all stands for in SPF Fail.
With this, the domain essentially states that systems not authorized by any previous SPF rule are not permitted to send.
In addition, there are other qualifiers such as ~all. Which policy is suitable for a domain depends on the overall sending configuration.
Important: Do not hang up
-allum, as long as you aren't sure that all legitimate sending systems of your domain are included in the SPF record.
Which shipping systems need to be taken into account? #
A domain often sends emails through more than just a single system.
In addition to a standard mail server, other services can, for example, send messages on behalf of your domain:
- SpamExperts Outgoing Filtering
- Newsletter systems
- CRM systems
- Support or ticketing systems
- Online stores
- external transactional email services
- Cloud services
Before replacing an existing SPF record, you should therefore clarify which of these systems are actually used.
Do not simply replace SPF with the SpamExperts record #
Assuming your domain already has a working SPF record for other legitimate sending services.
If you simply replace this with:
v=spf1 include:spf.antispamcloud.com -all
replaced, the previous shipping systems might then no longer be authorized by SPF.
This can negatively affect the deliverability of legitimate emails.
SpamExperts must therefore be integrated into the existing sending architecture – not blindly put in its place.
Edit SPF in cPanel Zone Editor #
If your domain's DNS zone is managed by CURIAWEB and the cPanel Zone Editor is available to you, you can edit TXT records there.
To do this, open in cPanel the Zone editor and subsequently the administration of the domain in question.
We explain how to manage DNS records in cPanel at Using the DNS Zone Editor in cPanel.
Search there first for an existing TXT record whose content begins with v=spf1 begins.
Edit SPF with an external DNS provider #
If your name servers or your DNS zone are not managed by CURIAWEB, you must change the SPF record at the responsible DNS provider.
This can be, for example, your domain provider, an external DNS service, or another hosting platform.
What matters is not where your email account is located, but which nameservers or DNS zone are authoritative for the domain.
DNS changes take time #
Changes to an SPF TXT record are not necessarily immediately visible worldwide.
DNS resolvers can cache previous responses according to the set TTL.
Therefore, after a change, you should take into account that different systems may temporarily still see different versions of the record.
Check SPF record after the change #
After the DNS change, you should check which SPF record is publicly served for your domain.
The published TXT record must contain the expected content.
When SpamExperts is used for outgoing mail, it should accordingly:
include:spf.antispamcloud.com
be included.
SPF check with a real test email #
A DNS check shows which SPF record is published. In addition, a real test email is useful.
Send a message to an external mailbox using the normal, actually used routing method of your domain.
Then check the complete message headers or authentication results.
There, depending on the recipient system, information such as:
spf=pass
to be visible.
Practical Tip: Don't test just any SMTP server. The message must be sent via the exact delivery path that you will later use in production. Only then does the result reveal something about your actual SPF configuration.
What does SPF pass mean? #
SPF Pass means that the sending server relevant to the SPF check has been authorized by the published SPF policy.
This is the desired result with a correctly configured legitimate shipping route.
What does SPF fail mean? #
A SPF Fail basically means that the verified sending server is not authorized for this sending according to the published SPF policy.
If a legitimate message receives an SPF fail, you should not simply disable the SPF check at the recipient's end because of this.
Check instead:
- whether the correct SPF record is published
- whether SpamExperts or the actually used delivery service is included
- whether the message was actually sent via the expected shipping route
- whether multiple conflicting SPF records exist
- whether DNS changes are already visible
SPF Neutral, Softfail and other results #
In addition to Pass and Fail, SPF knows other possible results.
For example, a frequently used mechanism is:
~all
This is usually referred to as Softfail Evaluated.
An SPF result should always be evaluated together with the actually published policy and the specific transmission path.
Why multiple SPF records are problematic #
A common DNS error is to create a separate SPF TXT record for each email service.
For example:
v=spf1 include:provider-a.example -all
v=spf1 include:spf.antispamcloud.com -allThat is not a clean SPF configuration.
The authorized shipping sources must be combined into a common SPF policy, for example schematically:
v=spf1 include:provider-a.example include:spf.antispamcloud.com -all
SPF has a DNS lookup limit #
With extensive SPF records, it must also be taken into account that SPF limits the number of certain DNS-based queries.
Many nested includeMechanisms can lead to this limit being exceeded.
The problem cannot be reliably assessed by merely looking at the visible length of the TXT record. The DNS mechanisms used by embedded domains in turn must also be taken into account.
Important: Do not add an arbitrary number of SPF includes. For complex sending environments, the complete SPF structure should be reviewed.
SPF alone does not completely prevent spoofing #
A correctly configured SPF record is important, but SPF alone does not provide complete protection against spoofed senders.
Modern email authentication therefore additionally uses in particular DKIM and DMARC.
| Procedure | Basic task |
|---|---|
| SPF | Check if a shipping system is authorized for the envelope sender domain used |
| DKIM | Verifies a cryptographic signature of the message |
| DMARC | Link SPF/DKIM with the visible sender domain and a published policy |
That is why SpamExperts also recommends not disabling the filter's SPF, DKIM, and DMARC checks without a specific technical reason.
SPF and forwarding #
Forwarded emails can cause special challenges for SPF.
The original sender has published their SPF record for their own sending systems. If a message is subsequently forwarded by another server, the next recipient may see a different sending IP address.
Professional email platforms can use procedures such as for this SRS (Sender Rewriting Scheme) insert.
This is one of the reasons why SPF should not be viewed in isolation and DKIM as well as DMARC are also important.
SPF and SpamExperts Filter Settings #
SpamExperts can consider SPF for incoming messages as part of its sender checks.
This check should generally remain enabled.
If a legitimate message causes issues due to faulty SPF configuration, the root cause should be investigated in the respective sending path instead of globally disabling the SPF check.
You can find our recommendation regarding these settings at SpamExperts Filter Settings: Why the Default Configuration is Usually the Best Choice.
Not protecting one's own domain against spoofing using block lists #
Your own domain should not be placed on the SpamExperts Sender Block List to prevent forged senders.
SpamExperts explicitly recommends mechanisms like SPF and DMARC for this.
A blocklist serves a different purpose and does not replace proper email authentication.
We explain more about this under Sender Block List: Block senders in SpamExperts.
Typical SPF errors #
| Error | Possible consequence |
|---|---|
| SpamExperts is missing in the SPF record | Messages sent via SpamExperts can cause SPF issues |
Several separate v=spf1-Records | Invalid or ambiguously evaluable SPF configuration |
| Overwrote existing SPF record | Other legitimate shipping systems are losing their authorization |
| Wrong domain edited | Change has no effect on actual shipping |
| Too many DNS-based mechanisms | SPF evaluation can exceed the permissible lookup limit |
| Misjudged shipping route | SPF authorizes systems other than those that actually send |
Best practices for SPF setup #
- Identify which systems are actually sending emails for your domain.
- Check if an SPF TXT record with
v=spf1is available. - Do not delete the existing SPF record before its mechanisms are understood.
- With SpamExperts Outgoing Filtering
include:spf.antispamcloud.comintegrate. - Consider all other legitimate shipping services.
- Ensure that only one common SPF policy is published.
- Save DNS changes and wait for them to propagate.
- Check the publicly visible SPF record.
- Send a real test email via the production shipping route.
- Check SPF result in message headers.
When emails cause problems after an SPF change #
If legitimate messages are no longer delivered as expected after an SPF change, you should not „fix“ the change with further random adjustments.
First, check the currently published SPF record and compare it with the mailing systems actually in use.
If the message in question was sent via SpamExperts Outgoing Filtering, the Outgoing Log Search can additionally help to trace the routing of the dispatch.
Summary #
SPF uses a DNS TXT record to specify which systems are allowed to send emails on behalf of your domain.
If you are using SpamExperts Outgoing Filtering, the SpamExperts sending infrastructure must be included in the SPF configuration. The mechanism intended for this is:
include:spf.antispamcloud.com
For example, if SpamExperts is the only authorized sending system, a complete policy might look like this:
v=spf1 include:spf.antispamcloud.com -all
If an SPF record already exists, you should not create a second SPF record. Instead, all legitimate sending sources must be merged into a single policy.
Also, check before any change which systems actually send emails for your domain. Newsletter services, online shops, CRM systems, or other external platforms can also be part of your SPF configuration.
After the change, you should check both the publicly visible DNS record and a real test email via the productive delivery path.
SPF is an important component of email authentication, but it does not replace DKIM and DMARC.
