One place for hosting & domains


      Apache Configuration Error AH00558: Could not reliably determine the server’s fully qualified domain name

      Part of the Series:
      Common Apache Errors

      This tutorial series explains how to troubleshoot and fix some of the most common errors that you may encounter when using the Apache web server.

      Each tutorial in this series includes descriptions of common Apache configuration, network, filesystem, or permission errors. The series begins with an overview of the commands and log files that you can use to troubleshoot Apache. Subsequent tutorials examine specific errors in detail.


      An Apache AH00558: Could not reliably determine the server's fully qualified domain name message is generated when Apache is not configured with a global ServerName directive. The message is mainly for informational purposes, and an AH00558 error will not prevent Apache from running correctly.

      In this tutorial you will learn how to detect an AH00558 message using the methods described in the How to Troubleshoot Common Apache Errors tutorial at the beginning of this series. You will also learn how to set a ServerName directive to resolve the message.

      If you have already determined that your Apache server is affected by an AH00558 message and you would like to skip the troubleshooting steps, the Setting a Global ServerName Directive step at the end of this tutorial explains how to resolve the message.

      Troubleshooting Using systemctl

      The first step when you are troubleshooting an AH00558: Could not reliably determine the server's fully qualified domain name message is to check Apache’s status using systemctl. The output from systemctl will in many cases contain all the information that you need to resolve the message.

      On Ubuntu and Debian-derived Linux distributions, run the following to check Apache’s status:

      Ubuntu and Debian Systems

      • sudo systemctl status apache2.service -l --no-pager

      On CentOS Fedora, and RedHat-derived systems, use this command to examine Apache’s status:

      CentOS and Fedora Systems

      • sudo systemctl status httpd.service -l --no-pager

      The -l flag will ensure that systemctl outputs the entire contents of a line, instead of substituting in ellipses () for long lines. The --no-pager flag will output the entire log to your screen without invoking a tool like less that only shows a screen of content at a time.

      You should receive output that is similar to the following:


      ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: active (running) since Wed 2020-07-29 14:30:03 UTC; 33min ago Process: 34 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS) Main PID: 46 (apache2) Tasks: 55 (limit: 2344) CGroup: /system.slice/apache2.service ├─46 /usr/sbin/apache2 -k start ├─47 /usr/sbin/apache2 -k start └─48 /usr/sbin/apache2 -k start Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Starting The Apache HTTP Server... Jul 29 14:30:03 68e2cf19f3f1 apachectl[34]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using Set the 'ServerName' directive globally to suppress this message Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Started The Apache HTTP Server.

      The highlighted line that contains the AH00558 message is the important one. Essentially, it informs you that Apache couldn’t find a valid ServerName directive in its configuration file, so it will use the first IP address it detects. In this example, it’s the server’s public IP address: 172.17.02. If you are troubleshooting an AH00558 message, the IP address that is detected may be different, or it may be a human readable DNS name.

      If your systemctl output contains an auto-detected value of any IP address or hostname, skip to the last section of this tutorial, Setting a Global ServerName Directive to resolve the issue. In that section you will configure Apache with a safe default ServerName value using the IP address for localhost:

      If your systemctl output does not indicate a value that you can use for the ServerName directive, the next section of this tutorial explains how to examine the systemd logs using journalctl to locate an AH00558 message.

      Troubleshooting Using journalctl

      To examine the systemd logs for Apache you will use the journalctl command. When invoking journalctl, there are two specific flags that will help you locate specific messages if there is a large volume of log entries.

      The first flag that you will add to the journalctl invocation is the --since today flag. It will limit the output of the command to log entries beginning at 00:00:00 of the current day only. Using this option will help restrict the volume of log entries that you need to examine when checking for errors.

      The second flag that you will use is the same --no-pager option that you used with systemctl, which will output the entire log to your screen at once.

      On Ubuntu and Debian-derived systems, run the following command:

      • sudo journalctl -u apache2.service --since today --no-pager

      On CentOS, Fedora, and RedHat-derived systems, use this command to inspect the logs:

      • sudo journalctl -u httpd.service --since today --no-pager

      If your Apache server is generating an AH00558 message, look through the journalctl command output for lines like the following:


      -- Logs begin at Wed 2020-07-29 14:30:02 UTC, end at Wed 2020-07-29 14:45:03 UTC. -- . . . Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Starting The Apache HTTP Server... Jul 29 14:30:03 68e2cf19f3f1 apachectl[34]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using Set the 'ServerName' directive globally to suppress this message Jul 29 14:30:03 68e2cf19f3f1 systemd[1]: Started The Apache HTTP Server.

      The second line of output is the AH00558 message. The line includes the server’s public IP address, which is the address that Apache automatically detects and sets as a default at runtime. With this message as confirmation of an AH00558 error, you can proceed to the Setting a Global ServerName Directive to resolve the issue.

      Otherwise, the next section explains how to diagnose an AH00558 error message using the apachectl command.

      Troubleshooting using apachectl

      An AH00558: Could not reliably determine the server's fully qualified domain name error can be detected using Apache’s apachectl utility. With apachectl you can catch messages like these before reloading or restarting Apache, and you can avoid having to search through systemctl and journalctl logs to locate errors.

      To check your Apache configuration for an AH00558 message, run the following command:

      • sudo apachectl configtest

      You should receive output like the following if your server is affected by an AH00558 error message:


      AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using Set the 'ServerName' directive globally to suppress this message Syntax OK

      As with the previous sections in this tutorial that used systemctl and journalctl to locate AH00558 messages, the line that contains the AH00558 message, highlighted in the previous example, is the important one. Again note that the IP address in this example may be different on your server.

      The next section of this tutorial explains how to set the ServerName directive to resolve AH00558 error messages.

      Setting a Global ServerName Directive

      To resolve an AH00558: Could not reliably determine the server's fully qualified domain name error message, you will need to add a ServerName directive to your Apache configuration. Apache uses the ServerName directive to map incoming HTTP requests to an IP address or DNS hostname using VirtualHost directives in order to handle requests for multiple sites using a single server.

      The error message notes that a global ServerName directive should also be set. Doing so will ensure that Apache can gracefully handle incoming requests that do not map to a VirtualHost without generating additional errors.

      For maximum compatibility with various Apache configurations, use the value of for your global ServerName directive. You can use a different IP address or DNS name that corresponds to your server’s configuration if you need to, but it is safest to use

      On Ubuntu and Debian-derived systems, open the /etc/apache2/apache2.conf file with root privileges using nano or your preferred text editor:

      • sudo nano /etc/apache2/apache2.conf

      Add a line containing ServerName to the end of the file:


      . . .
      # Include the virtual host configurations:
      IncludeOptional sites-enabled/*.conf
      # vim: syntax=apache ts=4 sw=4 sts=4 sr noet

      On CentOS, Fedora, and RedHat-derived systems, open the /etc/httpd/conf/httpd.conf file with root privileges using nano or your preferred text editor:

      • sudo nano /etc/httpd/conf/httpd.conf

      Add the ServerName line to the end of the file:


      . . .
      # Supplemental configuration
      # Load config files in the "/etc/httpd/conf.d" directory, if any.
      IncludeOptional conf.d/*.conf

      Save and close the file when you are finished. If you used nano, do so by pressing CTRL + X, Y, and then ENTER.

      Once you have added the ServerName directive to your configuration, run apachectl to test that the configuration is valid.

      • sudo apachectl configtest

      A successful apachectl configtest invocation should result in output like this:


      Syntax OK

      You can now restart Apache using the appropriate systemctl restart command for your Linux distribution.

      On Ubuntu and Debian-derived systems, run the following:

      • sudo systemctl restart apache2.service

      On CentOS, Fedora, and RedHat-derived systems use this command to restart Apache:

      • sudo systemctl restart httpd.service

      After you restart Apache, the AH00558 error message will no longer appear in your logs. You can confirm the messages are silenced by running any of the three systemctl, journalctl, or apachectl commands that are demonstrated in this tutorial.


      In this tutorial you learned about AH00558: Could not reliably determine the server's fully qualified domain name error messages. While these messages do not prevent Apache from running, they can be resolved by setting a global ServerName directive.

      You learned how to search for AH00558 error messages using the systemctl, journalctl, and apachectl commands. Finally, you learned how to edit your Apache configuration on various Linux distributions to silence the messages.

      If you would like to learn more about how Apache uses ServerName directives, the Apache documentation about Name-Based Virtual Hosts explains the directive in more detail.

      Source link

      How To Configure MTA-STS and TLS Reporting for Your Domain Using Apache on Ubuntu 18.04

      The author selected Electronic Frontier Foundation Inc to receive a donation as part of the Write for DOnations program.


      Mail Transport Agent Strict Transport Security (MTA-STS) is a new internet standard that allows you to enable strict force-TLS for email sent between supported email providers. It is similar to HTTP Strict Transport Security (HSTS), where a force-TLS policy is set and then cached for a specified amount of time, reducing the risk of man-in-the-middle or downgrade attacks.

      MTA-STS is complemented by SMTP TLS Reporting (TLSRPT), which gives you insight into which emails are successfully delivered over TLS, and which aren’t. TLSRPT is similar to DMARC reporting, but for TLS.

      The primary reason for implementing MTA-STS for your domain is to ensure that confidential email that is sent to you is transmitted securely over TLS. Other methods for requiring TLS for email communications are still susceptible to man-in-the-middle attacks, as the initial connection is unencrypted. MTA-STS ensures that the initial incoming connection is using TLS by default, which greatly reduces the risk of these attacks.

      An example use case for MTA-STS and TLS Reporting is to help create a secure customer service email system for your business. Customers may send support tickets via email that contain confidential personal information, which needs a secure TLS connection. MTA-STS provides that secure connection, and TLSRPT will deliver daily reports identifying any emails that weren’t sent securely—giving crucial insight into any ongoing or previous attacks against your email system.

      In this tutorial, you will learn how to configure MTA-STS and TLSRPT for your domain name, and then interpret your first TLS Report. While this tutorial covers the steps for using Apache on Ubuntu 18.04 with a Let’s Encrypt certificate, the MTA-STS/TLSRPT configuration will also work on alternatives, such as Nginx on Debian.


      Before you begin this guide, you’ll need:

      Once you have these ready, log in to your server as your non-root user to begin.

      Note: Once you have completed the implementation steps for MTA-STS and TLSRPT, you may have to wait up to 24 hours to receive your first TLS Report. This is because most email providers send reports once per day. You may resume the tutorial from Step 5 once you’ve received your first report.

      Step 1 — Creating an MTA-STS Policy File

      MTA-STS is enabled and configured using a plain text configuration file that you host on your website. Supported mail servers will then automatically connect to your website to retrieve the file, which causes MTA-STS to be enabled. In this first step you’ll understand the available options for this file and choose the most appropriate for your file.

      Firstly, open a new text file in your home directory so that you have somewhere to write down your desired configuration:

      We will first go over an example, and then you will write your own configuration file.

      Following is an example of an MTA-STS configuration file:

      Example MTA-STS Configuration File

      version: STSv1
      mode: enforce
      mx: mail1.your-domain
      mx: mail2.your-domain
      max_age: 604800

      This example configuration file specifies that all email delivered to mail1.your-domain and mail2.your-domain from supported providers must be delivered over a valid TLS connection. If a valid TLS connection cannot be established with your mail server (for example, if the certificate has expired or is self-signed), the email will not be delivered.

      This will make it much more challenging for an attacker to intercept and snoop on/modify your email in a situation like a man-in-the-middle attack. This is because having MTA-STS enabled properly only allows email to be transmitted over a valid TLS connection, which requires a valid TLS certificate. It would be hard for an attacker to acquire such a certificate, as doing so usually requires privileged access to your domain name and/or website.

      As shown in the example earlier in this step, the configuration file consists of a number of key/value pairs:

      • version:

        • Purpose: To specify the version of the MTA-STS specification to use.
        • Accepted Values: Currently the only accepted value is STSv1.
        • Example: version: STSv1
      • mode:

        • Purpose: Specify which mode MTA-STS should be enabled in.
        • Accepted Values:
          • enforce: Force all incoming email from supported providers to use valid TLS.
          • testing: Report-only mode. email will not be blocked, but TLSRPT reports are still sent.
          • none: Disable MTA-STS.
        • Example: mode: enforce
      • mx:

        • Purpose: To specify which mail servers are allowed to handle email for your domain. This should match the servers specified in your mx records.
        • Accepted Values: Fully-qualified domain name of a mail server, or a wildcard host. Multiple mx: values must be used to specify multiple mail servers.
        • Example: mx: mail1.your-domain, mx: mail2.your-domain, mx: *
      • max_age:

        • Purpose: To specify the maximum lifetime of the MTA-STS policy, in seconds.
        • Accepted Values: Any positive integer up to 31557600.
        • Example: max_age: 604800 (1 week)

      You can also view the official specification for the key/value pairs in Section 3.2 of the MTA-STS RFC.

      Warning: Enabling MTA-STS in enforce mode could unexpectedly cause some email not to be delivered to you. Instead, it is recommended to use mode: testing and a low max_age: value at first, in order to ensure that everything is working correctly before turning on MTA-STS fully.

      Using the example file earlier in the step, as well as the preceding key/value pair examples, write your desired MTA-STS policy file and save it to the file that you created at the start of the step.

      The following example file is ideal for testing MTA-STS, as it will not cause any emails to be unexpectedly blocked, and has a max_age of only 1 day, meaning that if you decide to disable it, the configuration will expire quickly. Note that some email providers will only send TLSRPT reports if the max_age is greater than 1 day, which is why 86401 seconds is a good choice (1 day and 1 second).

      Example Test MTA-STS Configuration File

      version: STSv1
      mode: testing
      mx: mail1.your-domain
      mx: mail2.your-domain
      max_age: 86401

      In this step you created your desired MTA-STS configuration file and saved it to your home area. In the next step, you will configure an Apache web server to serve the file in the correct format.

      Step 2 — Configuring Apache to Serve Your MTA-STS Policy File

      In this step, you’ll configure an Apache virtual host to serve your MTA-STS configuration file, and then add a DNS record to allow the site to be accessed from a subdomain.

      In order for your MTA-STS configuration file to be automatically discovered by mail servers, it must be served at exactly the right path: https://mta-sts.your-domain/.well-known/mta-sts.txt. You must use the mta-sts subdomain over HTTPS and the /.well-known/mta-sts.txt path, otherwise your configuration will not work.

      This can be achieved by creating a new Apache virtual host for the mta-sts subdomain, which will serve the MTA-STS policy file. This step builds upon the base configuration that you’ll have set up in the prerequisite step How to Install the Apache Web Server on Ubuntu 18.04.

      Firstly, create a directory for your virtual host:

      • sudo mkdir /var/www/mta-sts

      If you’re hosting multiple different domains on your web server, it is recommended to use a different MTA-STS virtual host for each, for example /var/www/mta-sts-site1 and /var/www/mta-sts-site2.

      Next, you need to create the .well-known directory, which is where your MTA-STS configuration file will be stored. .well-known is a standardized directory for ‘well-known’ files, such as TLS certificate validation files, security.txt, and more.

      • sudo mkdir /var/www/mta-sts/.well-known

      Now you can move the MTA-STS policy file that you created in Step 1 into the web server directory that you just created:

      • sudo mv ~/mta-sts.txt /var/www/mta-sts/.well-known/mta-sts.txt

      You can check that the file was copied correctly if you wish:

      • cat /var/www/mta-sts/.well-known/mta-sts.txt

      This will output the contents of the file that you created in Step 1.

      In order for Apache to serve the file, you’ll need to configure the new virtual host and enable it. MTA-STS only works over HTTPS, so you’ll use port 443 (HTTPS) exclusively, rather than using port 80 (HTTP) as well.

      Firstly, create a new virtual host configuration file:

      • sudo nano /etc/apache2/sites-available/mta-sts.conf

      Like with the virtual host directory, if you are hosting multiple different domains on the same web server, it is recommended to use a different virtual host name for each.

      Then, copy the following sample configuration into the file, and populate the variables where required:


      <IfModule mod_ssl.c>
      <VirtualHost your-server-ipv4-address:443 [your-server-ipv6-address]:443>
          ServerName mta-sts.your-domain
          DocumentRoot /var/www/mta-sts
          ErrorDocument 403 "403 Forbidden - This site is used to specify the MTA-STS policy for this domain, please see '/.well-known/mta-sts.txt'. If you were not expecting to see this, please use <a href="https://your-domain" rel="noopener">https://your-domain</a> instead."
          RewriteEngine On
          RewriteOptions IgnoreInherit
          RewriteRule !^/.well-known/mta-sts.txt - [L,R=403]
          SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
          SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
          Include /etc/letsencrypt/options-ssl-apache.conf

      This configuration will create the mta-sts virtual host, which will be served at mta-sts.your-domain. It will also redirect all requests, except for those to the mta-sts.txt file itself, to a custom 403 Forbidden error page, with a friendly explanation of what the subdomain site is for. This is to help ensure that any visitors who accidentally come across your MTA-STS site aren’t inadvertently confused.

      Currently, a self-signed TLS certificate is used. This is not ideal, as a fully valid/trusted certificate is required for MTA-STS to work correctly. In Step 3, you will acquire a TLS certificate using Let’s Encrypt.

      Next, ensure that the required Apache modules are enabled:

      After that, enable the new virtual host:

      Then, run a syntax check of the Apache configuration files, to ensure that there aren’t any unexpected errors:

      • sudo apachectl configtest

      When the test passes with no errors, you can restart Apache to fully enable the new virtual host:

      • sudo service apache2 restart

      Now that the Apache virtual host has been set up and configured, you need to create the required DNS record(s) to allow it to be accessed using the fully-qualified domain name mta-sts.your-domain.

      The way that this is done depends on the DNS hosting provider that you use. However, if you use DigitalOcean as your DNS provider, simply navigate to your project, followed by clicking on your domain.

      Finally, add the required DNS records for the mta-sts subdomain. If your Droplet only uses IPv4, create an A record for mta-sts, pointing to your-server-ipv4-address. If you use IPv6 as well, create an AAAA record pointing to your-server-ipv6-address.

      A screenshot of the DigitalOcean DNS control panel, showing an example DNS record for mta-sts pointing to an IPv4 address.

      In this step, you created and configured a new Apache virtual host for your MTA-STS subdomain, then added the required DNS record(s) to allow it to be accessed easily. In the next step, you will acquire a trusted Let’s Encrypt certificate for your MTA-STS subdomain.

      Step 3 — Acquiring a Let’s Encrypt Certificate for Your MTA-STS Subdomain

      In this step, you’ll acquire a TLS certificate from Let’s Encrypt, to allow your mta-sts.your-domain site to be served correctly over HTTPS.

      In order to do this, you’ll use certbot, which you set up as part of the prerequisite step How To Secure Apache with Let’s Encrypt on Ubuntu 18.04.

      Firstly, run certbot to issue a certificate for your mta-sts subdomain using the Apache plugin verification method:

      • sudo certbot --apache -d mta-sts.your-domain

      This will automatically issue a trusted certificate and install it on your Apache web server. When the Certbot wizard asks about configuring a HTTP -> HTTPS redirect, select 'No’, as this is not required for MTA-STS.

      To finish, test your new virtual host to ensure that it is working correctly. Use a web browser to visit https://mta-sts.your-domain/.well-known/mta-sts.txt, or use a command-line tool such as curl:

      • curl https://mta-sts.your-domain/.well-known/mta-sts.txt

      This will output the MTA-STS policy file that you created in Step 1:


      version: STSv1 mode: testing mx: mail1.your-domain mx: mail2.your-domain max_age: 86401

      If an error occurs, ensure that the virtual host configuration from Step 2 is correct, and that you have added a DNS record for the mta-sts subdomain.

      In this step, you issued a Let’s Encrypt TLS certificate for your mta-sts subdomain, and tested that it’s working. Next, you’ll set some DNS TXT records to fully enable MTA-STS and TLSRPT.

      Step 4 — Configuring the DNS Records Required to Enable MTA-STS and TLSRPT

      In this step, you’ll configure two DNS TXT records, which will fully enable the MTA-STS policy that you have already created, and also enable TLS Reporting (TLSRPT).

      These DNS records can be configured using any DNS hosting provider, but in this example, DigitalOcean is used as the provider.

      Firstly, log on to your DigitalOcean control panel and navigate to your project, followed by clicking on your domain.

      You then need to add the following two TXT records:

      _mta-sts.your-domain IN TXT "v=STSv1; id=id-value"
      _smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=reporting-address"

      id-value is a string used to identify the version of your MTA-STS policy in place. If you update your policy, you’ll need to also update the id value to ensure that the new version is detected by mail providers. It is recommended to use the current date stamp as the id, for example 20190811231231 (23:12:31 on 11th Aug 2019).

      reporting-address is the address where your TLS reports will be sent to. This can be either an email address prefixed with mailto:, or a web URI, for example for an API that collects reports. The reporting address doesn’t have to be an address on your-domain. You may use a completely different domain if you wish.

      For example, the following two sample records are both valid:

      _mta-sts.your-domain IN TXT "v=STSv1; id=20190811231231"
      _smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@your-domain"

      Adjust the variables as required, and set these DNS TXT records in your DigitalOcean control panel (or whichever DNS provider you’re using):

      A screenshot of the DigitalOcean control panel, showing the _mta-sts DNS TXT record being set.

      A screenshot of the DigitalOcean control panel, showing the _smtp._tls DNS TXT record being set.

      Once these DNS records have been set and have propagated, MTA-STS will be enabled with the policy that you created in Step 1, and will begin to receive TLSRPT reports at the address that you specified.

      In this step, you configured the DNS records required for MTA-STS to be enabled. Next, you will receive and then interpret your first TLSRPT report.

      Step 5 — Interpreting Your First TLSRPT Report

      Now that you’ve enabled MTA-STS and TLSRPT (TLS Reporting) for your domain, you will begin to receive reports from supported email providers. These reports will show the number of emails that were or were not successfully delivered over TLS, and the reasons for any errors.

      Different email providers send their reports at different times; for example, Google Mail sends their reports daily at around 10:00 UTC.

      Depending on how you configured the TLSRPT DNS record in Step 5, you will either receive your reports via email, or via a web API. This tutorial focuses on the email method, as that is the most common configuration.

      If you’ve just completed the rest of this tutorial, wait until you receive your first report, then you can resume.

      Your daily TLSRPT report via email will usually have a subject line similar to the following:

      Report Domain: your-domain Submitter: Report-ID: <>

      This email will have an attachment in .gz format, which is a Gzip compressed archive, with a file name similar to the following:!your-domain!1565222400!1565308799!001.json.gz

      For the rest of this tutorial this file will be referred to as report.json.gz.

      Save this file to your local machine, and extract it using whichever tool you prefer.

      If you’re using a Debian-based Linux system, you will be able to run the gzip -d command to decompress the archive:

      This will result in a JSON file called report.json.

      Next, you can view the report either directly as the raw JSON string, or use your favorite JSON prettifier to put it into a more readable format. In this example, jq will be used, but you could also use Python’s json.tool if you wish.

      Note: If you don’t have jq installed, you can install it using apt install jq. Or, for other operating systems use the necessary installation instructions from jq.

      This will output something similar to the following:

      Prettified report.json

      { "organization-name": "Google Inc.", "date-range": { "start-datetime": "2019-08-10T00:00:00Z", "end-datetime": "2019-08-10T23:59:59Z" }, "contact-info": "", "report-id": "2019-08-10T00:00:00Z_your-domain", "policies": [ { "policy": { "policy-type": "sts", "policy-string": [ "version: STSv1", "mode: testing", "mx: mail1.your-domain", "mx: mail2.your-domain", "max_age: 86401" ], "policy-domain": "your-domain" }, "summary": { "total-successful-session-count": 230, "total-failure-session-count": 0 } } ] }

      The report shows the provider that generated the report and the reporting period, as well as the MTA-STS policy that was applied. However, the main section that you’ll be interested in is summary, specifically the successful and failed session counts.

      This sample report shows that 230 emails were successfully delivered over TLS from the mail provider that generated the report, and 0 email deliveries failed to establish a proper TLS connection.

      In the event that there is a failure—for example, if a TLS certificate expires or there is an attacker on the network—the failure mode will be documented in the report. Some examples of failure modes are:

      • starttls-not-supported: If the receiving mail server doesn’t support STARTTLS.
      • certificate-expired: If a certificate has expired.
      • certificate-not-trusted: If a self-signed or other non-trusted certificate is used.

      In this final step, you received and then interpreted your first TLSRPT report.


      In this article you set up and configured MTA-STS and TLS Reporting for your domain, and interpreted your first TLSRPT report.

      Once MTA-STS has been enabled and working stably for a while, it is recommended to adjust the policy, increasing the max_age value, and eventually switching it to enforce mode once you are sure that all email from supported providers is being delivered successfully over TLS.

      Finally, if you’d like to learn more about the MTA-STS and TLSRPT specifications, you can review the RFCs for both of them:

      Source link

      What’s My Domain Worth? How to Value Your Domain Name

      Many of us nurture a dream of finding out that something we own is secretly immensely valuable. Perhaps that old vase in the attic is actually worth thousands of dollars, for example. However, it’s not just dusty antiques that could be unexpectedly profitable. Something as simple as a domain name could be worth a considerable amount.

      However, in order to find out if you’re sitting on a potential moneymaker, you’ll need to know what makes a domain valuable in the first place. Fortunately, this is not nearly as complex or time-consuming to figure out as you might expect. In practice, estimating the value of your domains simply requires you to do a little research.

      In this article, we’ll discuss the importance of domain valuation. We’ll also explore some of the most critical factors that determine a domain’s worth, and show you what you can do to estimate your own domain’s price. Let’s get started!

      An Introduction to Domain Valuation

      Whether you’re planning on selling a domain, or you just want to know how much one you own is worth, you’ll be looking to perform a process called domain valuation. This can also be referred to as domain appraisal, but the principle remains the same. Either way, this is a method for estimating the value of a specific domain name.

      Before moving on, let’s quickly recap some domain name basics. A domain name refers to the main part of a site’s URL, which visitors use to access the main page of that site. For example, our domain name is

      In turn, a domain name consists of two primary components:

      • Second-Level Domain (SLD): This refers to the main part of the URL, which most commonly contains the name of the website or the business that owns it. In our example, this is “dreamhost”.
      • Top-Level Domain (TLD): This is what comes at the end of the domain name, which in our case is .com. There are hundreds of TLDs available to use, but some of the most popular include .com, .net, .org, .gov, and .edu.

      To add a domain name to your site, you’ll need to register one with a vendor known as a Domain Name Registrar (DNR). You can also buy domain names from several hosting companies. In fact,  DreamHost specializes in domains by providing an easy interface to search for, purchase, and manage your assets. This can be particularly useful if you want to get your website hosting and domains from the same provider and keep the administration of your entire site under one roof.

      Once you’ve purchased a domain name and linked it to your site, you’ll often give it little more attention. However, sometimes it’s worth finding out how valuable a domain you own is. The main reason to do this is when you’re considering selling a domain you’re not using, or one you no longer need. In these cases, it’s smart to find out how much your domain is worth ahead of time, so you know if you’re selling it at a fair price.

      What Makes a Domain Name Valuable

      Regardless of your reasons for wanting to find out, estimating the value of a domain doesn’t have to be too difficult. However, it will require you to understand what makes a domain desirable in the first place.

      Of course, it’s significant to note that as with most evaluations of this nature, this is not an exact science. A domain will always be worth what people are willing to pay for it, and the bottom line is that sometimes the theory may not line up with the practical reality. By calculating the estimated worth, however, you’re providing yourself with a handy baseline — so you don’t end up selling a valuable domain for pennies.

      With that in mind, let’s look at some of the features generally considered important when it comes to domain names. These include:

      • The Top-Level Domain. A domain’s TLD can be a big part of what makes it desirable. For example, .com remains the most popular option (as it’s recognizable and common), so many buyers will gravitate towards it. However, newer alternatives can also become trendy (and valuable).
      • Popularity and traffic. If the domain name is currently used for a specific website, the level of traffic that site receives can become a vital factor in calculating the domain’s worth. The reason for this is pretty straightforward. If the domain comes with an existing audience attached, the buyer can leverage that traffic for their site right away. If the domain has been active for a while, this can also help its Search Engine Optimization (SEO) for the new owner, which may make it even more appealing.
      • Keywords. Including the right keywords in your domain name is another crucial aspect of SEO. According to a study by Higher Visibility, in most industries, a majority of sites include high-quality keywords in their domains. For example, the top-rated website for the search query “hotel” is As such, if your domain contains a desirable keyword, this could increase its value.
      • Brandability. While a domain’s brandability can be very difficult to define, it’s also an important consideration many site owners make when choosing a name. Many of the most visited websites in the world have clear, memorable, and unique domains, such as,, and If your domain is similarly catchy and attention-grabbing, it may make buyers take special notice.
      • Spelling. This may seem obvious, but making sure your domain is spelled correctly can be critical. After all, few buyers will be swayed to use something that looks sloppy and unprofessional. At the same time, using unexpected spelling can sometimes be a benefit, as it could make the domain more brandable. For example, and have taken technically incorrect spellings and used them to create memorable, lasting brands.
      • Length. A general rule of thumb is that the shorter a domain is, the more people will pay for it. This isn’t always the case – brevity alone isn’t going to make an otherwise cumbersome domain like more appealing to potential buyers. However, a concise domain is often considered rarer and therefore more valuable. This is due to shorter domains being more memorable, easier to share, and more marketable.

      These points are all worth paying attention to as you research your domain’s potential value. However, remember that there are no guarantees,and that the value of a domain can shift dramatically over time.

      How to Determine the Value of Your Domain Name (In 3 Steps)

      Theory is all well and good, but to find out how much your domain might be worth, you’ll need to get practical. To do this, we’re going to show you how to perform a domain valuation in three simple steps.

      Bear in mind that these steps don’t need to be performed all at the same time or in this specific order. However, what follows is a recommended process that can help you get a clear and comprehensive understanding of your domain’s worth. Let’s get started!

      Step 1: Research What Similar Domains Are Sold For

      To figure out what people may be willing to pay for your domain name, you need to know what people are charging for similar domains. We mentioned earlier that the value of a given domain can shift dramatically over time, so you probably can’t use what you initially paid for the domain as a baseline.

      At this stage, you will need to do some digging to see what domain names are currently being sold for and compare them to the ones you own. Fortunately, several sites collect information about domain sales. One of these is DN Journal, which can tell you about the past three weeks’ highest reported sales.

      The DN Journal website.

      Another site that does something similar is Domain Name Wire. On its blog, you can find regular roundups of prominent, recent domain sales.

      The Domain Name Wire website.

      If your domain is concise, you may find ShortNames especially useful. This site also collects recent sales, but specializes in (you guessed it) short domain names.

      The ShortNames website.

      These sites are all handy resources to help you track what names are selling for the highest amounts. For example, if we take a look at the most recent list provided by DN Journal (at the time of this writing), we can spot several domains that match the criteria we outlined earlier.

      The top 10 recent domain sales from DN Journal.

      Featured prominently in this list are short, memorable, clear, and keyword-heavy domains. If one of your domains is very similar, you might be sitting on a potential goldmine. These roundups can also help you catch recent trends in domain names.

      However, if you want to find information about sales for domains that are more directly comparable to yours, you will need to dig a little deeper. Let’s look at how to do that next.

      Step 2: Use an Appraisal Service

      A domain appraisal service is exactly what it sounds like. It’s a website that enables you to find information about your domain, helping you estimate its value and compare it to similar names.

      This kind of service will do a lot of the hard work for you. It automatically compares your domain against similar names and collects information about what those other domains sold for. It will also measure your domain’s worth, based on many of the factors we outlined previously. If you’re serious about putting an estimated price on your domain, this is one of the easiest methods for getting an educated answer.

      While there are many appraisal sites you can use, we’re going to look specifically at one of the most well-known. Say hello to EstiBot.

      The EstiBot website.

      EstiBot is the most widely used domain appraisal tool, with over two million appraisals performed on a daily basis. To try it for yourself, you can start by entering the domain you want to check in the field on the homepage and clicking Appraise.

      At that point, you should be presented with a report on the specified domain.

      A domain appraisal in EstiBot for

      At the top of the page, you’ll see the estimated value and some basic information about the domain. However, if you scroll down, you’ll find more details regarding how EstiBot arrived at this value. For instance, you can see the total amounts that similar domains sold for.

      Comparable domain sales in EstiBot.

      You can also view a huge amount of statistics and analytics for the domain, giving you an even clearer picture of its ultimate worth.

      Domain analytics and statistics.

      All of this information should give you a pretty good picture of what you could potentially ask for your domain. You may also want to use some appraisal tools to get an even better average, by comparing their different evaluations. For this, you could use DomainIndex and NamePros, to name a few options.

      This should provide you with a substantial theoretical value for your domain. However, as we’ve already mentioned, a domain’s real value is what someone is actually willing to pay for it. As such, if you want a definite answer, you may need to go straight to your potential buyers.

      Step 3: Find Out What People Are Willing to Pay for Your Domain Name

      Taking the time to do research and use estimation tools will undoubtedly be useful. This gives you an idea of the potential price you may be able to charge for your domain. However, it’s often best to go straight to potential buyers for a definitive answer.

      For instance, a domain could theoretically tick many of the boxes we outlined earlier, but still not be one that people are keen to purchase. It could be that the domain simply isn’t relevant to anyone, is too similar to an existing prominent site, or it has an unfortunate connotation that makes it less desirable.

      On the flip side, the opposite could also be true. A domain that shouldn’t be particularly valuable might be just what a particular website owner is looking for. This can make it much more lucrative than anticipated.

      The best way to find these things out is by putting the domain name up for sale. That might sound drastic, especially if you don’t actually want to lose the domain just yet, but it doesn’t have to be a risk. In fact, many sites that enable you to buy and sell domains will also let you set a reserve price for them. If you’ve ever sold anything on eBay before, this should be a familiar concept.

      Essentially, a reserve price is a figure you specify that serves as the minimum price you will accept. If the reserve is not matched or exceeded by any offers, the auction ends without a transaction actually taking place. This lets you put up a domain for auction and see what people are willing to pay, without the risk of selling the domain for less than you’re satisfied.

      Let’s try this out for ourselves to illustrate the process. The site we’ll use is Flippa, which is an online marketplace for domains.

      The Flippa homepage.

      To get started, you’ll need to sign up for an account. Bear in mind that while accounts are free, actually selling a domain costs at least $9 per listing. As such, you should only do this if you’re willing to spend a little money on valuing your domain. Other sites vary, but most charge similar token fees.

      If you decide that the cost of entry is worth it, click Sign Up on Flippa’s homepage and enter your personal details.

      Signing up for a Flippa account.

      You’ll then receive a confirmation email to activate your account. Click on the attached link and you’ll be taken back to Flippa, where you’ll be asked if you’re signing up as a buyer or a seller.

      Choosing to be either a buyer or seller.

      Naturally, you’ll want to select the latter option for now. When you do so, you’ll be asked some further questions, so add in your details as appropriate.

      Activating a Flippa account.

      Once you’ve done that, you’re ready to start selling. Select the Domains option, and enter the domain you want to value in the text field that’s provided.

      Start selling on Flippa.

      The next step entails providing information about the domain and how you want to sell it. You should select the Auction method, as this will let other users set whatever price they’re willing to pay.

      Creating a domain auction.

      You also need to specify a duration for your auction. Fourteen days should generally be enough to give you a good estimate of your domain name’s value. Then, towards the bottom of the page, you can also set the domain’s starting price and your Reserve price.

      Setting the start and reserve price.

      If you don’t want to sell the domain under any circumstances, you should set this value very high. In addition, make sure that the Show reserve price option is not checked, as users will otherwise be able to see it. Bear in mind that the highest you can set a reserve price on Flippa is $10,000.

      The next few steps in this process will ask how much you want to pay for the listing, which determines its visibility. Stick with the cheapest option for now, and provide your payment details.

      Paying to create a domain listing.

      Once you’ve provided all your details, you can verify your listing. When this is done, it will appear on the site, where other users will be able to bid on it.

       An example of a Flippa domain auction.

      You can now sit back and watch as the bids roll in, giving you an accurate estimate of your domain’s value to real users. If you’re lucky, somebody will take a fancy to your domain, and may even bid above the reserve right away. Either way, at the end of this process you should have a much clearer idea of how much your domain name is worth.

      Claim That Domain

      Whether you’re planning on selling your domain name or you simply want to know what it’s worth, performing domain valuation will help you find the answer. By understanding what factors are essential in determining a domain’s value and conducting a little research, you can quickly learn how badly other people might want to own it.

      Do you have any questions about estimating the value of a domain name? Join the DreamHost Community and start the conversation!

      Source link