With the function Email deliverability In cPanel, you can check important settings for the authentication of your email domain. These include in particular SPF and DKIM.
These DNS records help receiving mail servers verify whether messages are actually sent via authorized systems and whether an email was altered during transport.
In this guide, we show you how to check email deliverability in CURIAWEB, correctly categorize warnings, and recognize when changes to the DNS records are necessary.
Important: A faultless setup in cPanel does not guarantee inbox delivery. Mail providers like Gmail, Outlook, or other providers additionally use their own spam filters, reputation, message content, and numerous other signals.
What does email deliverability mean? #
Email deliverability simply describes the ability to successfully transmit sent messages to other mail servers and have them processed there as correctly as possible.
Various factors play a role here.
An important component is the technical authentication of the sender domain. Receiving mail servers want to be able to determine, among other things, whether the sending server is authorized for the domain in question and whether certain parts of the message were transmitted unchanged.
This is precisely where SPF and DKIM come into play, among other things.
What does the cPanel function „Email Deliverability“ check? #
The function examines the email authentication settings relevant to your domains and can indicate if there are issues with the expected DNS records.
Of particular relevance are:
- SPF – specifies which systems are allowed to send emails for a domain
- DKIM - signs outgoing emails with a cryptographic signature that can be verified via DNS
Depending on the DNS configuration, cPanel can also display hints or suggested records if the required DNS data cannot be changed automatically on the responsible DNS system.
Do not confuse SPF, DKIM and DMARC #
The three terms are often mentioned together, but fulfill different tasks.
SPF checks in a simplified manner whether a sending system is authorized for the domain in question.
DKIM enables the cryptographic verification of a signature added to an outgoing message.
DMARC builds on SPF and DKIM and defines, among other things, how receiving systems should handle messages that fail certain authentication and alignment checks. DMARC can also enable reporting.
Briefly explained: SPF, DKIM, and DMARC complement each other. They are not three different names for the same function.
1. Open Email Deliverability in cPanel #
Log in to your CURIAWEB cPanel.
Scroll to the section on the homepage Email and click on Email deliverability.
cPanel will then show you the domains of your hosting account and the determined status of the email configuration.
2. Choose the correct domain #
If there are multiple domains in your hosting account, check the domain whose email deliverability you want to investigate.
For example:
your-domain.ch
Authentication is configured for domains via DNS records. Therefore, a correct status of one domain does not automatically mean that another domain in the same hosting account is also configured correctly.
3. Check domain status #
First, check what status cPanel displays for the desired domain.
If cPanel detects no issues with the expected settings, this is a good sign that the authentication data checked by cPanel is correctly accessible.
If a problem or warning is displayed instead, you should open the detailed view.
Important: Do not change DNS records simply because you suspect that „more records“ improve deliverability. SPF, DKIM, and DMARC must technically match the actual mail configuration.
4. Manage domain and view details #
Open the management or detail view for the domain in question.
There you can check the SPF and DKIM settings detected by cPanel in more detail.
If there is an issue, cPanel can also display the expected or recommended DNS record, depending on the situation.
What is SPF? #
SPF stands for Sender Policy Framework.
The SPF record is published as a TXT record in the domain's DNS.
He describes which systems or sending sources are authorized to send emails on behalf of the domain in question.
An SPF record can begin, for example, simply with the following component:
v=spf1
This is followed by rules that determine which shipping sources are authorized and how other sources should be handled.
Why SPF is important #
When a receiving mail server receives a message, it can use SPF to check whether the sending server is authorized for the relevant domain according to the published SPF record.
This makes SPF make certain forms of domain name spoofing as a sender more difficult.
However, SPF alone does not prevent every form of sender forgery, nor is it a spam filter.
Do not create multiple independent SPF records #
A common configuration error is to create a separate SPF TXT record for each shipping service.
For example, if a domain sends emails via the hosting server and additionally via an external newsletter or mail service, the necessary authorized sources must be included in a valid SPF configuration.
Attention: Do not simply add a second SPF record with
v=spf1a. Multiple SPF records for the same domain can lead to an SPF PermError. The required sending sources must be combined into a single, correct SPF policy.
Include external mail services in SPF #
If you do not send exclusively via the CURIAWEB mail server, your SPF configuration must match your actual infrastructure.
This applies, for example, to domains that additionally use an external mail service, newsletter provider, CRM service, or other systems for sending.
Do not randomly copy SPF components from third-party guides for this. Use the specifications of the service actually in use and integrate them correctly into the existing SPF configuration.
What is DKIM? #
DKIM stands for DomainKeys Identified Mail.
During sending, the email is provided with a cryptographic signature. The corresponding public key is made available via a DNS record of the domain.
The receiving mail server can use this public key to verify the DKIM signature.
This can be used, among other things, to check whether the signed components of the message have been modified after signing.
Why DKIM matters #
DKIM strengthens the technical authentication of outbound messages.
A recipient can use the signature to verify whether the message was signed with a key matching the specified DKIM domain and whether the signature verification is successful.
However, DKIM alone guarantees neither freedom from spam nor placement in the inbox.
What is a DKIM selector? #
A DKIM key is not simply published directly under the main domain. For this purpose, a so-called Selector used.
The DNS name typically contains the structure:
selector._domainkey.deine-domain.ch
Which selector is actually used depends on the respective mail system.
Attention: Do not create a DKIM record based on an example from a foreign domain. The public key and the used selector must belong to your actual mail configuration.
5. Check SPF status #
Open the detail view of the desired domain and check the SPF section.
If cPanel recognizes the configuration as valid, you should not change the entry without a specific reason.
If cPanel shows an error instead, read the exact message first and check which SPF record cPanel expects or recommends.
6. Check DKIM status #
Then check the DKIM section.
The same applies here: If cPanel recognizes the entry as correct, you should not make changes as a precaution.
In the event of a warning, you should check whether the required DKIM DNS record exists and is publicly accessible.
Who manages your domain's DNS zone? #
Before you change a DNS record, you need to know, where the authoritative DNS zone of your domain is managed.
If your domain uses the nameservers intended for your CURIAWEB hosting and the DNS zone is managed via the hosting, changes can be made accordingly within this environment.
If the domain instead uses external nameservers, for example with another DNS provider, the changes must be made there.
Important: An entry in the local cPanel Zone Editor has no public effect if the domain actually uses its authoritative DNS zone on other nameservers.
7. Check nameservers or DNS authority #
If cPanel displays a required record but it cannot be corrected automatically, first check the DNS authority of the domain.
If DNS management is external, you must add the record required by cPanel with the responsible DNS provider.
If DNS management is in the CURIAWEB cPanel, you can manage DNS records via the Zone Editor.
We show the procedure at Using the DNS Zone Editor in cPanel.
8. Accept the entry suggested by cPanel exactly as is #
If cPanel displays a required SPF or DKIM record due to an externally managed DNS zone, you should copy its name and value exactly.
Do not manually modify a DKIM key, in particular.
With long TXT records, even missing or extra characters can cause authentication to fail.
DNS changes take time #
After a change in the DNS, the result is not necessarily visible everywhere immediately.
DNS responses may still be answered with the previous status for a while due to TTL values and cached information.
If cPanel continues to show a warning immediately after an external DNS change, this does not automatically mean that the new record is incorrect.
Practical Tip: After a DNS change, do not try multiple different variants. First, check whether the correct entry has been published, and then take the DNS caches into account.
9. Recheck status after a change #
After the DNS record has been published and sufficient time has passed for the update, open again:
Email → Email deliverability
Check the status of the domain in question again.
Now, if cPanel detects a valid configuration, the original authentication issue is resolved.
What is DMARC? #
DMARC stands for Domain-based Message Authentication, Reporting and Conformance.
DMARC uses results from SPF and DKIM and additionally checks the so-called Alignment- Relationship to the visible sender domain.
Simplified, this means: For DMARC, it is not always sufficient for an SPF or DKIM check to be successful somewhere in the message. The authenticated domain must also match the visible sender domain in the way expected by DMARC.
Why Alignment is Important in DMARC #
For example, an email can be sent technically via an authorized server without the domain used for SPF matching the visible sender domain exactly.
Therefore, DMARC considers not only whether SPF or DKIM passed, but also the relationship of the respective domains to the visible sender.
This is an important difference between the individual authentication methods.
Do not blindly enable DMARC with a strict policy #
DMARC can specify how receiving systems should handle messages that fail the DMARC check.
An inconsiderately strict policy can therefore affect legitimate emails if not all actual sending sources are yet correctly authenticated.
Attention: Before implementing a strict DMARC policy, all legitimate sending paths for your domain must be known and correctly configured for SPF and/or DKIM. This includes not only normal mailboxes, but also websites, shops, newsletter systems, and external business systems, for example.
Why a green status is no inbox guarantee #
A technically correct SPF and DKIM configuration is important, but only part of deliverability.
Receiving mail providers can additionally evaluate numerous other factors.
This includes, for example:
- Sender reputation
- Domain reputation
- Content and structure of the message
- Shipping behavior and shipping volume
- Spam complaints from recipients
- Quality and origin of recipient lists
- further custom filter and security rules of the recipient
Therefore, a technically correctly authenticated message can still end up in the spam folder.
Basic rule: SPF and DKIM are important prerequisites for clean email delivery – but they are no guarantee that every message will land in the inbox.
SPF and DKIM are not spam filters #
SPF and DKIM do not evaluate whether the content of a message is wanted or unwanted.
They serve to authenticate or check certain technical properties of email transmission.
Even an unwanted promotional email can be technically correctly authenticated with SPF and DKIM.
Conversely, a legitimate message can encounter delivery issues if its authentication is misconfigured.
Distinguish between email deliverability and cPanel spam filters #
The function Email deliverability and the Spam filter therefore fulfill different tasks in cPanel.
The deliverability feature helps control the authentication of your domain.
The spam filter, on the other hand, serves to examine incoming messages for spam characteristics and treat them accordingly.
We show how to configure this at Configure spam filter in cPanel.
What happens with externally hosted emails? #
If your website is hosted with CURIAWEB, but your email accounts are operated through an external provider, the entire mail configuration must match this setup.
This includes not only SPF and DKIM, but also MX records and email routing.
For example, if you use an external mail service, its specifications for SPF and DKIM must be taken into account.
In such a case, the configuration expected by CURIAWEB hosting for local mail delivery must not simply replace the specifications of the actual mail provider without verification.
External e-mail system and CURIAWEB website simultaneously #
A particularly common constellation is:
Website: CURIAWEB
Email: third-party provider
The website can still send messages, for example via a contact form or an online store.
This allows multiple legitimate routing paths to exist for the same domain.
The SPF, DKIM and, if applicable, DMARC configuration must take this actual infrastructure into account.
Checking routing for external mail services #
If a domain's mailboxes are hosted externally, it should also be checked whether cPanel treats the domain as an external mail destination.
An incorrect routing setting can be particularly problematic in the case of messages sent directly from a website hosted on the server to an address within the same domain.
We show you how to control this at How to properly set up email routing in cPanel.
SPF has special features with forwarding #
Email forwarding can make authentication checks more complex.
A message was originally sent by a foreign server and is subsequently forwarded via another server to a new destination.
This can cause the SPF check at the final recipient to differ from that of a direct delivery.
That does not automatically mean that the forwarding is set up incorrectly. Rather, it shows why email authentication for forwarding should not be judged solely on the basis of a simple SPF check.
We explain how to set up redirects in cPanel at Set up email forwarding in cPanel.
DKIM can be helpful with forwarding #
A valid DKIM signature can survive forwarding under certain conditions, as long as the signed parts of the message are not altered in a way that invalidates the signature.
Therefore, DKIM, alongside SPF, is an important component of modern email authentication.
However, even here the actual result depends on the specific message path and the systems involved.
Website sends emails, but SPF or DKIM fails #
When a website, shop, or application sends emails, you need to know, Which shipping method these messages are actually sent.
An application can, for example, use the local mail server or send messages via an external SMTP service.
These two variants can have different requirements for SPF and DKIM.
Practical Tip: Before changing DNS records, first clarify which server or service actually sends the message in question.
An email is rejected – what now? #
When an external mail server rejects a message, you should examine the full error message.
This may contain, for example, a reference to SPF, DKIM, DMARC, reputation, or a completely different cause.
Do not automatically change SPF or DKIM just because an email failed to arrive.
We show how to investigate the delivery history under Track email delivery in cPanel.
Common mistake: DNS record changed in the wrong place #
A user sees a recommended SPF or DKIM record in cPanel and enters it in the cPanel Zone Editor.
However, the domain uses external name servers.
The result: While the change exists in the hosting server's local DNS zone, it is not being used in the public DNS at all.
Therefore, before making any DNS changes, you should clarify which nameservers are authoritative for the domain.
Typical mistake: Copied old DKIM record from a previous environment #
After a hosting or mail server change, DNS records from the previous environment may still exist.
An old DKIM key might not match the currently used mail system.
Therefore, use the DKIM record that actually belongs to the current sending platform.
Typical mistake: Forgot external mail provider for SPF #
If your employees send via an external service, but this service is not included in the SPF configuration, the SPF check for these messages can fail.
Therefore, identify all legitimate sending sources before you change SPF.
Depending on the company, this can include:
- the hosting mail server
- an external email provider
- Newsletter systems
- CRM or ERP systems
- Support and ticketing systems
- other authorized shipping platforms
Typical mistake: Continuously expanding SPF #
The opposite is also problematic.
An SPF record should not indiscriminately authorize more and more sources just to avoid potential errors.
Every approved source should have a traceable purpose and actually be needed for the domain's email delivery.
Safety: Authorize in the SPF only sending sources that are actually allowed to send emails on behalf of your domain.
SPF has technical limitations #
SPF records can use mechanisms that cause additional DNS queries. The SPF procedure has technical limits for this.
A very complex configuration with numerous integrated services can therefore itself become prone to errors.
When you combine many external shipping platforms, the SPF configuration should be technically checked and not just expanded by continuously adding more includemechanisms can be added.
Send a real test email after a correction #
If cPanel recognizes the configuration as valid after a change, you should additionally send a real test message to an external recipient.
For this purpose, use an independent external mailbox, for example, and check whether the message arrives.
If required, the headers of the received message may contain further information on how SPF, DKIM, and DMARC were evaluated by the recipient.
Mail headers provide additional information #
The complete headers of an email contain technical information about the message route and can also include results of authentication checks.
Depending on the receiving system, information regarding SPF, DKIM, and DMARC, for example, may appear there.
The exact display differs between various email providers.
For a deeper diagnosis, such headers are much more informative than just the visible sender address in the email client.
What to do if cPanel shows everything as correct, but emails end up in spam? #
If SPF and DKIM are correct, you shouldn't keep working on these DNS records.
Investigate other possible causes instead.
This includes, for example, sending behavior, reputation, content, links, attachments, recipient complaints, or the target provider's filter rules.
For individual messages, you should also check whether there is actually a general deliverability problem or if only a specific recipient is affected.
Practical Tip: Do not test with just a single recipient. If a message ends up in spam with one provider, but arrives correctly at several other providers, this is diagnostically important information.
What to do when only a specific domain rejects emails? #
If shipping to many recipients works, but messages to a specific domain are regularly rejected, you should examine the error message from that destination server.
This suggests a specific issue with this delivery method rather than a complete failure of your email sending.
Use the Delivery Tracking in cPanel and check the complete SMTP error.
No speculative DNS changes #
In case of delivery issues, you should not change SPF, DKIM, DMARC, MX records, and email routing all at once.
This can lead to additional errors and makes the original cause harder to trace.
Instead, proceed systematically:
- Check the relevant domain at Email deliverability.
- Check SPF and DKIM.
- Determine where the authoritative DNS zone is managed.
- Correct only one actually erroneous entry.
- After a DNS change, take the update time into account.
- Check the status again.
- Then send a real test message.
When should you contact support? #
If cPanel displays an error, but you cannot clearly assess the DNS configuration, you should not delete or replace entries on suspicion.
For a targeted analysis, the following information is particularly helpful:
- affected domain
- displayed message under email deliverability
- whether the DNS zone is managed by CURIAWEB or externally
- which email provider is used
- whether additional external shipping services are used
- in case of rejection, the complete SMTP error message
This makes it much faster to determine which part of the configuration actually needs to be checked.
Summary #
The function Email deliverability can you find in your CURIAWEB cPanel under Email → Email deliverability.
Check the status of SPF and DKIM there for the desired domain in particular. If cPanel indicates a problem, check the exact message first and then determine where the authoritative DNS zone of your domain is managed.
SPF specifies which sending sources are authorized for a domain. DKIM enables the cryptographic verification of signed messages. DMARC builds on SPF and DKIM and additionally considers alignment with the visible sender domain.
Do not change DNS records on suspicion, and in particular, do not create multiple independent SPF records for the same domain. For external mail or dispatching services, the configuration must correctly account for all actually used dispatch paths.
A technically sound SPF and DKIM configuration is an important part of clean email delivery, but it does not guarantee inbox placement. If a message is rejected, you should additionally examine the specific delivery history and the complete SMTP error message.
