While it is strongly encouraged that you read this document entirely and follow these steps, it is difficult to encompass every scenario for DNS settings and configuration as DNS administration can vary largely from region and country. We recommend seeking advice from your Domain Registrar if you are unsure on how to carry out the following changes.
SoCast does not provide DNS Support unless you've purchased our DNS Concierge Services.
In the event you require assistance with making your DNS changes to launch your SoCast website, please contact your DNS Panel Administrator or your Domain's Registrar directly for support.
1. About the DNS Records
While onboarding with a support specialist, you will receive a CSV file containing the necessary records you must create in your domain's DNS configuration:
DKIM record set:
A group of CNAME records used for digitally signing e-mails generated by the Socast platform. Digitally signing e-mails provides a layer of security by verifying that an e-mail sent from your domain originated from where it was supposed to. In some cases this can aid deliverability as it allows a receiver to better identify if the message can be trusted or not. While configuring these records is optional, it is still strongly recommended that these records be properly configured in your domain's DNS configuration. These records can be added at any time between receiving them and launching your website.
Website record set:
A list of CNAME and A records for pointing your website domain to the Socast platform. This record set should
be added last and should only be done when you are ready to officially launch your Socast website. You will also need to make sure that the proper domain names have been added to your
before configuring these records to prevent any service interruption.
2. E-mail Validation Records
This portion of the DNS configuration can be done at any point of the onboarding process. This involves adding a series of TXT and CNAME records to your domain's DNS configuration which allows the Socast platform's e-mail provider to send e-mail on behalf of your website's domain. Without these records in place, any e-mail driven communication will be impaired, so it is important to make sure these records are properly implemented to avoid any service interruption.
These records are responsible for digitally signing any e-mails sent on behalf of your website's domain which ensures that they are delivered, unaltered from where they originated from. While these records are not a requirement for e-mail capabilities on the Socast platform, it is strongly advised that you still implement these records as they can impact deliverability of any e-mail based communications. From our example CSV file above (or your own CSV file if you are following along), you will need to make note of the following information:
Record Name (Column A):
Highlighted in yellow, this is normally referred to as the "Name" or "Host". Most DNS providers will automatically append your domain's name to the end of whatever is entered in this column, so including it in the DNS entry isn't necessarily required. When properly configured, any requests to this hostname (ie. jkczwvh47ninm3wppq54yesranacazfh._domainkey.ourtestdomain.com) should respond with the corresponding record value from column C (ie. jkczwvh47ninm3wppq54yesranacazfh.dkim.amazonses.com).
Record Type (Column B):
Highlighted in green, this is the type of record that should be created. In this case, we need to create CNAME records since the Value (column C) contains another fully qualified hostname (ie. jkczwvh47ninm3wppq54yesranacazfh.dkim.amazonses.com).
Record Value (Column C):
Highlighted in blue, this is normally referred to as the "Value". Some providers may provide text similar to "Points to..." which essentially represents the same thing. This should reflect the value of column C (ie. jkczwvh47ninm3wppq54yesranacazfh.dkim.amazonses.com).
Implementing DKIM Records
Login to your DNS provider's configuration panel
Create a new CNAME record for each of the three (3) entries using the values from columns A, B and C in your CSV file:It is not necessary to include the domain name itself in the "Host" or "Name" portion of the record (ie. ourtestdomain.com) as it appears in the CSV file. If you do choose to include the domain name itself in the "Host" or "Name" field, you must append a dot ( . ) to the end of it (ie. jkczwvh47ninm3wppq54yesranacazfh._domainkey.ourtestdomain.com . ) to instruct DNS that this is a complete record (fully qualified domain name) instead of one that requires the domain name (ie. ourtestdomain.com) appended to it. If you do not include this dot ( . ) the record will saved incorrectly (ie. jkczwvh47ninm3wppq54yesranacazfh._domainkey.ourtestdomain.com.ourtestdomain.com) since the default behaviour of DNS is to append the domain name to a record.
The Socast platform checks for valid e-mail verification DNS records daily. If everything has been configured correctly, there should be no action required or any further communication from Socast on the topic. However, if there is an issue with a record's configuration (ie. a record is removed by accident or added/modified incorrectly), the Socast platform will send out a daily automated e-mail to your site's administrative contact notifying them of this issue. It will also further offer the corrective steps to solve the issue (ie. what records are incorrect or missing and what their expected values should be). If you or somebody in your group has received one of these e-mails, it is likely that there is an issue with your configuration and you should the suggested steps as soon as possible to avoid any interruption in e-mail service.
3. Website Records
At this point, you should already have the verification records for e-mail in place as proceeding any further will launch your Socast hosted website. If you are already using your domain to host your website on another provider, be advised that this will cause all traffic to stop reaching your old hosted content and will begin reaching your new Socast hosted content.
Launching the Site
This part of the configuration process should be done carefully, as any improper configuration could result in outages or availability issues. From our example CSV file above (or your own CSV file if you are following along), you will need to make note of the following information:
Record Name (Column A):
Highlighted in yellow, this is normally referred to as the "Name" or "Host". Most DNS providers will automatically append your domain's name to the end of whatever is entered in this column, so including it in the DNS entry isn't necessarily required. When properly configured, any requests to this hostname (ie.
urtestdomain.com) should respond with the corresponding record value from column C (ie. 220.127.116.11 or ourtestdomain.com).
Record Type (Column B):
Highlighted in green, this is the type of record that should be created. In this case, we need to create A and CNAME records since the Value (column C) contains either an IP address or a fully qualified hostname (ie. 18.104.22.168 or ourtestdomain.com respectively).
Record Value (Column C):
Highlighted in blue, this is normally referred to as the "Value". Some providers may provide text similar to "Points to..." which essentially represents the same thing. This should reflect the value of column C (ie. 22.214.171.124 or ourtestdomain.com).
Preparing the Platform
You will similarly need to create DNS records as you did for e-mail, however you will first need to configure the platform to respond to the host names you want to use. In this example we will set our site up to respond to three (3) different host names (substitute your own values if you are following along):
This will be the primary host name that the site should be reachable on.
This will be a secondary (alias) address that the site should be reachable on. This always forwards to the primary host name (ie. ourtestdomain.com)
This will be another secondary (alias) address that the site should be reachable on. This always forwards to the primary host name (ie. ourtestdomain.com)
You'll note that by default Socast only provides DNS examples for the root domain (ie. ourtestdomain.com) and the "www" prefix (ie.
These are just suggested host names as you are free to modify, add or remove host names as required. In our example we will create the two suggested hostnames (ourtestdomain.com and
but also follow similar instructions to create an additional domain (news.ourtestdomain.com).
To configure the platform to use these names:
Login to the Socast backend with an account that has permission to modify
- In the upper-right navigation strip, click the Settings option
- Select Website Settings from the available options
- Under the Vitals section begin by setting your Website Domain . This should reflect the primary host name (ie. ourtestdomain.com from above)
- Under the Website Redirect portion, click the Add Row button to add another secondary host name that should point to your Socast hosted content (ie. www.ourtestdomain.com from above).
Implementing Website Records
Login to your DNS provider's configuration panel
First you will need to create an A record for your primary domain to point to the Socast platform. Since the primary domain in this example is ourtestdomain.com this will be the first record to createNote that we use an " @ " symbol in the "Host" or "Name" field to represent to domain name (ie. ourtestdomain.com). This is standard DNS syntax, although alternatively you could specify the entire domain name and append it with a dot " . " instead (ie. outestdomain.com . )
- Next you will need to create a CNAME record for the desired secondary domains that point back to the primary domain record configured earlier (ie. "Name" or "Host" would be www.ourtestdomain.com and "Value" or "Points to..." would be ourtestdomain.com)
You should also be sure to set the TTL value for these records to a value under 1 hour to allow these changes to propagate around the internet quickly.
Securing your Site
The Socast platform offers a number of security related features that are automatically implemented once a site has been successfully launched. These features and countermeasures ensure a safe, secure browsing experience which clients engage with any Socast hosted content.
4. Web Application Firewall
The Socast platform is secured by a web application firewall that has been designed to respond and defend against many common types of attacks on the internet such as (but not limited to):
Denial of service
XSS (Cross Site Scripting)
Because Socast has taken these measures, it is requested that any customers who are using a third-party vendor for this type of security opt to disable these features as they can cause false positives and impact your website's availability. A good example of this would be Cloudflare's website proxy. If your website's DNS is hosted or routed through a service like Cloudflare to protect against things like denial of service, you will need to be certain that this traffic is not in any way routed or modified by Cloudflare as it will trigger Socast's own application firewall and prevent access to your website(s).
5. SSL Certificates
All Socast platform customers are provided with an ongoing, free SSL certificate to secure their websites with. This is done automatically and supports the adding and removing of additional website aliases (providing they are properly configured in your DNS settings). Upon either launching a new site or modifying an existing site's host names in the backend and all the required DNS records are in place, an SSL certificate will be automatically generated (or modified if already existing) to include the names configured in your
. Normally these changes can be seen within an hour, approximately - however if it has been longer than 12 hours and your site still isn't secured with an SSL certificate, please reach out to Client Services for further investigation. The certificate can only ever contain names that resolve via DNS to the Socast platform. So if there are any host names configured in the backend that have either been removed from your DNS configuration or are otherwise absent, these names will not be included in your SSL certificate.