26 March 2025

Mailserver, Blacklist, DNSBL and Spam: How to Get Out and Prevent the Problem

IP Address and Email Blacklisted? DNSBL blacklists block millions of emails every day. Learn how they work, why you end up on them, and how to avoid them effectively.

DNSBL

In the world of digital communication, email continues to represent a fundamental pillar, both for private users and for companies. However, precisely because of its widespread nature and ease of use, email has become a privileged tool for the dissemination of unwanted messages: spam. As the phenomenon has grown, defense tools such as DNS-based Blackhole Lists (DNSBL) have been created, which, although useful, can turn into a nightmare for those who manage a mail server and find themselves, often unknowingly, inserted into one or more blacklists.

This article aims to provide a technical insight into how DNSBLs work, the most common causes that lead to an IP being blacklisted, methods for getting out of it, alternative solutions to mitigate the impact, and, most importantly, best practices to prevent it from happening again.

What is a DNSBL and how does it work?

A DNSBL (DNS-based Blackhole List), also known as Rbl (Real-time Blackhole List), is a system designed to identify and block in real time the sending of emails from IP addresses considered suspicious or openly involved in spam, phishing or malware distribution activities.

This is a fundamental tool in the field of email security, which uses the DNS (Domain Name System) protocol not only to resolve domain names, but also to query real-time block listsThe basic idea is that of publish lists of “malicious” IPs in a DNS-queriable format, so that mail servers can consult them quickly when receiving messages.

How it works technically

The operating mechanism is as simple as it is effective:

How it works-DNSBL

  1. Receiving SMTP connection: When a mailserver receives a connection from a remote IP (e.g. 1.2.3.4), it may decide to query its reputation.

  2. Reverse IP lookup: The IP is reversed and appended to the blacklisted domain, generating a DNS query like 4.3.2.1.dnsbl.example.com.

  3. DNS Response: If the IP is in the blacklist, the DNS system responds with a special IP address, usually in the range 127.0.0.x, where the final value can also indicate the block category (spam, malware, open relay, etc.).

  4. Mailserver action: Depending on your local mail server configuration, the message may be:

    • Rejected immediately (SMTP 550)

    • Accepted but marked as suspicious/spam

    • Normally accepted, but recorded for statistical analysis

It all happens in a few milliseconds, with no perceptible impact on SMTP latency, making DNSBLs one of the most scalable and efficient defenses against spam.

Evolution of the DNSBL model

While many DNSBLs started out as open community initiatives, with the aim of improving the quality of global email, over time some of them have evolved into commercial services. Today there are blacklists that offer paid priority delisting, advanced reporting, API integrations and tailored filtering solutions for providers and enterprises.

This has created a dichotomy between purely technical lists, which automatically remove an IP after a certain period of time, and semi-commercial lists, which monetize the management of abuse by demanding payments to speed up removal.

Understanding how a DNSBL works, and how it is used by mailservers, is the first step to avoiding deliverability problems and building an effective IP reputation management strategy.

Types of Blacklists: What They Exist and How They Differ

In the email security landscape, not all blacklists work the same, nor do they have the same impact. Understanding the differences between the various types is essential to knowing how to deal with any possible inclusions and how to properly manage IP reputation.

1. Public and free DNSBLs
They are the best known and most widespread. Among the main ones are: Spamhaus, spamcop, Barracuda, SORBS, UCEPROTECT Level 1 and many others. These lists are freely queried by mail servers and operators, but generally impose limits on the number of daily queries (rate limit), especially in high-traffic environments. Some require registration or compliance with specific terms of use to prevent abuse.

Public DNSBLs are based on sources such as spamtraps, automated reporting, suspicious activity observed in real time, and behavioral analysis. Their effectiveness is high, but they can sometimes generate false positives, especially in the presence of dynamic or shared IPs.

2. Commercial Blacklists
This type of lists is managed by private companies or groups with commercial interests related to spam protection. In addition to the simple presence of the IP, they offer API, monitoring portals, detailed reports, and in some cases even temporary whitelist options. Some services allow operators to integrate the data into their own filtering infrastructures via advanced APIs.

Lists like UCEPROTECT Level 2 and 3, Invaluation, SpamRats Pro, Lashback fall into this category. Immediate removal from these blacklists may require the payment of a sum that generally varies between 50 to 150 dollars per single IPCommercial blacklists often have varying impacts on deliverability, but are used by many enterprise spam providers and appliances.

3. Internal (private) blacklists
Many email service providers — such as Microsoft, Google, Yahoo, and several ISPs — maintain internal and non-publicly accessible lists, based on activity observed directly on their systems. These blacklists cannot be verified using tools like MxToolbox, and often their existence is only hinted at by generic SMTP rejection messages (e.g. “Our system has detected an unusual rate of spam from your IP”).

In these cases, the only way to request removal is contact technical support directly of the affected provider, providing concrete evidence of the corrective actions taken (sending logs, forensic analysis, internal audits, updating DNS records, etc.). The process can be long and does not always guarantee a positive outcome, especially if the provider has detected repeated behaviors over time.

La nature of the blacklist determines not only the impact on outgoing emails, but also the type of action needed to resolve the issue. Knowing the category of the list you've ended up in is the first step to effectively managing the situation.

Why does a mailserver end up on a blacklist?

The main reasons that can lead a mailserver to be blacklisted are multiple and often interconnected. Once an IP ends up in a blacklist, its reputation is seriously compromised and the ability to deliver emails (deliverability) can be drastically reduced, with serious consequences for corporate communication.

1. Sending actual spam:
This is the most obvious and common case. It can happen when an email account is compromised by weak or stolen credentials, allowing attackers to send large volumes of spam. Similarly, a CMS (such as WordPress, Joomla, etc.) with outdated plugins or known vulnerabilities can be exploited to generate and send malicious emails. Even the presence of unauthenticated or poorly configured PHP scripts on the web server can become a source of spam that goes undetected until the damage is done.

2. Incorrect or missing DNS configurations:
The lack of properly configured DNS records such as SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance) is often interpreted as a sign of negligence or suspicious activity. The absence or misconfiguration of these records prevents recipients from verifying the authenticity of the sender, making it easier to flag the IP as a spam source.

3. Dynamic or shared IPs:
The use of IPs provided by consumer ISPs or dynamic ones, often present in IP blocks considered "residential", is highly discouraged for sending mail. Many blacklists consider these networks potentially insecure for MTA (Mail Transfer Agent) use. Furthermore, the use of shared IPs (for example in shared hosting environments) can expose the mailserver to the bad practices of other users: if only one of the infrastructure's customers sends spam, the entire IP block can be penalized.

4. Negative feedback loops:
Some providers, such as Outlook, Yahoo, and AOL, offer feedback loop (FBL) systems that notify you when users mark emails as spam. A high rate of reports relative to total sending volume is a clear sign of unwanted content, unauthorized mailings, or poorly maintained contact lists, and may result in blacklisting even by private providers.

5. Poorly managed mailing lists:
Sending emails to outdated, unverified, or third-party purchased contact databases is a huge risk. Sending to non-existent addresses or spam traps — addresses specifically created by blacklists to detect unauthorized sending — can generate an immediate penalty. An outdated list or one without a clear opt-in/opt-out mechanism is one of the main causes of blocks.

Once blacklisted, the IP reputation is compromised and email deliverability drops dramatically.

Symptoms of a Blacklisted IP

My emails go undelivered. What can I do? - Synology Tudásközpont

Recognizing the signs of a blacklisted IP in a timely manner is essential to minimize the impact on your email infrastructure. Symptoms are usually obvious and manifest themselves on multiple levels of the delivery process. Ignoring them can mean days of blocked outgoing mail, with serious reputational and operational damage.

1. Emails that don't reach their destination:
The first warning sign is the lack of response from recipients. When an IP is blacklisted, many of the emails sent never reach their destination, being silently rejected by the receiving servers. This is particularly damaging for critical communications, such as order confirmations, system notifications or administrative deadlines.

2. Explicit SMTP error messages:
When sending, the sending server may receive SMTP error codes, often accompanied by clear messages indicating the reason for the rejection. The most common include:

550 5.7.1 Message rejected due to IP listed in ... 554 5.7.1 Service unavailable; Client host blocked ...

These messages indicate that the destination server has refused the connection or delivery based on IP reputation. In some cases, the blacklist involved (Spamhaus, SORBS, UCEPROTECT, etc.) is also specified, making diagnosis easier.

3. High bounce rates:
An abnormal increase in bounces, or return messages generated due to delivery errors, is a critical signal. If the rejected emails exceed a physiological threshold (e.g. 5-10%), it is necessary to investigate immediately. Often, among the reasons for the bounce, the indication of the block due to blacklist appears explicitly.

4. Reports from users:
Customers, partners, or colleagues may start reporting that they are no longer receiving company communications. This type of feedback is often the first “human” indicator of an ongoing problem, and should be taken very seriously, as it demonstrates a real and direct impact on the business.

5. Abnormal delivery times (mail queues piling up):
MTA systems like Postfix, Exim or Qmail maintain a queue of undelivered messages. If the IP is blacklisted, many receiving servers will respond with a “defer” or a “temporary failure”, causing the mailserver to retry delivery according to the backoff policy. This causes a progressive slowdown and an exponential growth of the mail queue (mailq), with resource consumption and delays even on legitimate and urgent messages.

Constantly monitoring these symptoms, including through automatic alerts, is essential to quickly identify a blacklist problem and promptly activate the necessary countermeasures.

How to check if your IP is blacklisted?

The first thing to do when you suspect a reputation-related delivery problem with your mail server is to do a targeted check of the IP address status. Fortunately, there are several free and reliable online tools that allow you to simultaneously query dozens of public blacklists.

Here are the main ones:

  • mxtoolbox
    One of the most used tools in the world. By entering the IP address or domain, MxToolbox scans over 80 blacklists and returns detailed results, including any warnings and recommendations.

  • MultiRBL.valli.org
    An extremely technical and precise service, useful for those who want an in-depth check. In addition to DNSBLs, the system also checks URI-based blacklists and internal lists of providers and firewall appliances.

  • Talos Reputation Center
    Offered by Cisco, it provides a reputational assessment for both IP addresses and domains. In addition to blacklist reporting, Talos assigns a reputation score (Good, Neutral, Poor) based on the behavior observed globally.

  • Spamhaus Lookup
    It is the official tool to check if an IP or domain is present in one of the lists maintained by Spamhaus (such as SBL, XBL, PBL and DBL). Essential for those who manage mass mailings or public email infrastructures.

These tools are essential to achieve a immediate and complete overview on the status of your IP. In many cases, blacklists also provide technical details and reasons for inclusion, facilitating diagnosis and subsequent delisting requests. Performing periodic checks, even in the absence of apparent problems, is a good practice to maintain high reliability of the email service.

How to get out of a blacklist?

Getting off a blacklist requires targeted and conscious actions. Delisting is not always immediate and can vary significantly depending on the type of blacklist involved. The main removal methods are illustrated below:

1. Manual removal
Most public and semi-commercial blacklists offer a delisting procedure accessible via an official web form. The process, while varying from list to list, generally follows these steps:

  • Entering the offending IP address in the appropriate field on the blacklist site.

  • Explanation (optional or mandatory) of corrective actions taken. This may include disabling a compromised account, deleting malicious scripts, correcting SPF/DKIM/DMARC records, or implementing sending limits.

  • Waiting for manual or automatic review by blacklist managers. This can take anywhere from a few hours to several days (usually 24 hours to 7 business days), depending on the policy and load of the list in question.

It is essential that the infrastructure has been effectively secured before requesting removal, otherwise the IP could be reinstated within hours.

2. Automatic removal (decay)
Some blacklists operate in a semi-automated way: the IP is added to the list in case of anomalous behavior (spam, abuse, suspicious traffic), but is automatically removed if no further problems occur within a certain period. This “decay” can vary from 24 hours to 14 days, depending on the severity of the report. However, relying only on this mechanism means accepting a potentially prolonged interruption in email deliverability.

3. Paid Removal
Some blacklist providers, including UCEPROTECT, SORBS o Invaluation, offer immediate removal options for a fee. Costs vary, but are typically between 40 and 100 dollars per IP, and can grow further if the entire subnet is involved or if priority services are required.

Important Note: payment for removal does not solve the cause of the problem. If the source of the spam or misconfiguration is not identified and corrected, the IP will soon be listed again. In some cases, blacklists keep track of repeated removals and may apply more severe penalties to repeat offenders.

The delisting is only the last phase of a broader clean-up strategy: it serves to close the circle after it has been resolved upstream the real cause of the problem.

Technical strategies to mitigate the problem

1. Use alternative IPs

When a mail server is blacklisted, the priority is to quickly restore the ability to send email without further compromising the reputation of the infrastructure. There are several technical strategies that can temporarily (or in some cases permanently) mitigate the problem while waiting for the delisting process to be completed.

1. Use alternative IPs
If your server has multiple public IP addresses assigned, you can configure your mailserver to route email traffic through a different IP than the blacklisted one.
For example, on Postfix it is sufficient to specify in the configuration file main.cf : smtp_bind_address = 198.51.100.5 

In more advanced environments, it is possible to implement differentiated routing by recipient, domain, email type, or system load. This approach allows, for example, to use a “clean” IP only for critical sending, keeping the problematic one in the queue for scheduled retries.

A well-designed infrastructure includes the assignment of multiple IPs from the beginning to accommodate emergency scenarios like this, especially in corporate contexts and mail providers.

2. Use a smarthost
As an alternative to using your own IP directly, you can configure the mailserver to use a external smart host, that is, an SMTP relay managed by a third party (for example Amazon SE, SendGrid, Mailjet, post mark, SMTP2GO, etc.).

These services, created for the management of bulk or transactional mail, offer infrastructures with monitored, certified and high deliverability IPs, capable of temporarily bypassing the problem. Integration is simple: just configure the SMTP authentication parameters and the relay host in the mailserver.

Using a smarthost is especially useful when delisting takes time or in the presence of very penalizing blacklists, such as those used by global providers (Microsoft, Google, etc.).

3. Section your email traffic
An effective strategy not only in case of emergency, but also as a general good practice, consists in Segment email traffic based on the type of content and recipient. In particular:

  • Transactional Emails (e.g. order confirmations, password resets)

  • Administrative emails (e.g. internal company communications, technical notices)

  • Email marketing or promotional

Each category should ideally be handled by a separate IP or a dedicated SMTP channel. This allows you to isolate any reputation issues and ensure that critical mail is always delivered, even if other flows suffer penalties. In advanced systems, this type of segmentation can be implemented via MTA configurations, routing policies or email orchestration tools.

The adoption of alternative IPs, the use of smarthosts and the separation of mail flows are fundamental solutions to effectively deal with a blacklist block, but they are also useful tools in designing a resilient and professional email infrastructure.

Best Practices to Avoid Being Blacklisted

Prevention is always better than cure, especially in the context of email, where IP reputation restoration can take days and seriously compromise business communications. Here is a set of fundamental best practices that every mail server administrator should adopt to minimize the risk of blacklisting.

1. Implement SPF, DKIM and DMARC correctly
These three DNS records are the foundation of modern email authentication.

  • SPF (Sender Policy Framework) defines which IPs are allowed to send mail on behalf of a domain.

  • DKIM (DomainKeys Identified Mail) cryptographically signs the contents of the message to ensure its integrity.

  • DMARC allows you to define a policy on how recipients should handle messages that fail SPF/DKIM and enables sending diagnostic reports.
    Proper implementation significantly reduces false positives and improves the overall reputation of the domain.

2. Periodically check SMTP logs for abnormal activity
Regular log analysis (/var/log/maillog, /var/log/mail.log, etc.) helps identify suspicious sends, anomalous traffic spikes, unauthorized relay attempts, or patterns consistent with spam attacks. Automating log parsing with tools like Fail2Ban, Logwatch, or ELK Stack helps prevent risky behavior.

3. Block the ability to send from unauthenticated web scripts
Many attacks start from vulnerabilities in contact forms or misconfigured PHP scripts. The use of authenticated SMTP wrappers (such as PHPMailer, SMTPAuth) instead of the function mail() native, coupled with restrictions on sendmail_path, dramatically reduces the chances of abuse.

4. Configure sending limits per user
A compromised SMTP account can send thousands of emails in a matter of minutes. It is therefore good practice to enforce rate limit e quotas per user (e.g. 100 emails/hour), especially in shared environments. This helps contain any damage and avoids automatic blacklist triggers.

5. Protect web forms with CAPTCHA
Automated bots are often the cause of abusive form submissions. The integration of CAPTCHA (reCAPTCHA v3 or v2) and invisible honeypot systems is a simple but effective barrier against unauthorized submissions.

6. Constantly update CMS and plugins
WordPress, Joomla, Drupal and other CMS are often the target of spam exploits. Keeping your core, plugins and themes up to date is essential. Where possible, disable native email functions entirely or limit them to authenticated forms.

7. Use a monitored queue with retry for undeliverable messages
Make sure that the mailserver manages queues efficiently and in a controlled way. Undeliverable messages should not remain indefinitely in the queue: defining a maximum number of retries and a reasonable retention (e.g. 3 days) avoids overloads and keeps the system responsive.

8. Monitor IP reputation score using automated tools
Tools like Talos Reputation, Sender Score or custom scripts that query DNSBLs can be integrated to monitor IP reputation in real time. In mission-critical environments, it is advisable to automate alerts and thresholds.

9. Segment mailing lists and send only to active users
Good contact list hygiene is essential. Avoiding sending to inactive, bounced or obsolete addresses reduces bounces and minimizes the risk of intercepting spamtraps. Using double opt-in mechanisms and periodic verification systems (e.g. email validation API) is a practice to always adopt.

10. Sign up for Feedback Loops (FBL) from major providers
Services like Microsoft SNDS, Yahoo CFL, AOL Feedback Loop allow you to receive notifications when a recipient reports a message as spam. This allows you to identify and isolate problematic accounts before they damage your entire infrastructure.

Implementing these best practices takes time, but ensures a proactive posture against blacklists and deliverability problems, keeping the mailserver efficient, clean and reliable over time.

What to do if you are a customer mail server provider or manager

For those who manage multi-tenant email infrastructures — such as hosting providers, resellers, MSPs, or system administrators managing shared mail servers — email is both critical and vulnerable. The complexity increases exponentially compared to a single-tenant environment: It only takes one compromised customer to compromise your entire IP reputation. and blacklist the entire mailserver.

For this reason, it is essential to adopt preventive and structural measures capable of containing the risk and facilitating rapid containment in the event of an accident.

Recommended actions:

1. Isolate mail flows per customer
Logical (and where possible physical) separation of email traffic is one of the most effective strategies. Using dedicated queues for each domain or user allows you to immediately track and block any anomaly, preventing abuse from spreading to the entire infrastructure. In advanced environments, you can configure mail servers like Postfix or Exim to use separate queues, logs, and policies for user groups or hostnames.

2. Offer dedicated IPs for email marketers
Customers who send newsletters or high volumes of promotional mail should use dedicated IPs, completely isolating their reputation from that of other customers. This approach allows for direct accountability, facilitates delisting in case of problems, and protects users who send normal or transactional mail.

3. Enable outgoing spam rules
Outgoing mail filtering is often overlooked, but it is an indispensable defense. It is good practice to apply:

  • Rate limit per user or domain (e.g. max 100 emails/hour)

  • Content Filters to block known spam patterns

  • Internal blacklists and outbound DNSBLs to prevent relays to suspicious recipients

  • Checks for potentially dangerous attachments (e.g. executables, compressed scripts)

Tools like Rspamd, Amavis, or dedicated modules in control panels (e.g. Plesk, cPanel) can be integrated to automate outbound filtering.

4. Actively monitor sending patterns
Behavioral analysis of mail volumes, most frequent destinations, and bounce or defer rates can help identify problems early. Monitoring and alerting solutions (such as Zabbix, Grafana, Prometheus, or custom log parsing systems) should be configured to detect anomalies in real time.

5. Offer authenticated SMTP on alternate ports (587, 465)
The use of standard ports 25 may be restricted or filtered by many ISPs. Offer authenticated access on port 587 (Submission) o port 465 (SMTP over SSL) ensures greater compatibility and security. In addition, it is possible to implement more granular authentication and tracking policies on users, controlling suspicious access or anomalous sending.

Managing a mail server for clients requires a constant balance between performance, security and reputation. Proactivity in segmenting traffic, configuring strict controls and constant visibility into SMTP activity are essential to guarantee a professional, resilient service that is immune to recurring blacklists.

Conclusions

Effectively managing a mailserver's reputation is not an activity to be underestimated: it requires advanced system skills a in-depth knowledge of SMTP dynamics, and the implementation of monitoring and prevention tools able to anticipate critical issues before they become harmful.

Ending up on a blacklist can happen even to the most careful administrators. No infrastructure is completely immune from risks: application vulnerabilities, configuration errors, incorrect customer behavior or simple carelessness can quickly lead to compromising the reputation of an IP and blocking email deliverability.

However, getting off a blacklist is possible — and often within a reasonable time frame — provided that we intervene with method, clarity and adequate tools. The most effective short-term solutions include the use of Secondary IPs or external smarthosts, to ensure business continuity and empty SMTP queues while waiting for the delisting to complete.

In the medium-long term, what makes the difference is a solid prevention strategy: traffic segmentation, strong authentication, outbound spam controls, rate limiting, and constant IP reputation monitoring.

For those who do not have the necessary skills internally, rely on a specialized technical partner it can make the difference between being blocked for days - with economic and image impacts - or restoring the service within a few hours, in a structured and definitive way.

Managed Server SRL offers professional technical support in the management, configuration and security of Postfix, Qmail, Exim, Sendmail mail servers, as well as advanced monitoring and protection systems against spam and blacklists.
If your email system has been blacklisted or you would like advice on how to prevent it in the future, contact us: our team is ready to help you.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

INFORMATION

Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

Back to top