How to use the DNS manager with various record types

Managing DNS records seems confusing for most users, especially since changing them affects how a website gets accessed. We have put together some practical examples to help our customers better understand how to use them on the Presslabs dashboard.

Overview

You can easily add all the DNS records you wish in the DNS editor.

NOTE

Only the site owners can manage the DNS zones.

The DNS records are added for a certain DNS zone, so make sure you select the right DNS zone. The newly added DNS records may take up to 48 hours to take effect, depending on how often the Internet Service Providers are refreshing the information. For most ISPs, the DNS changes are visible in a few hours, if not minutes.

To add a record for the root domain use @ and when adding a subdomain you only need to enter the subdomain (e.g. blog), without the whole main domain (e.g. blog.example.com).

A-records

An A record maps a domain directly to its corresponding IP address.

Adding a A record

The necessary A records needed for your site to run on Presslabs (root domain, www and CDN sub-domains) are managed by us, since we handle requests with our own geographically distributed delivery network.

However, you may need to add A records when you configure your email for example.

CNAME

A CNAME is a record that points to another domain address rather than an IP address. It’s used when you want to point a subdomain to a certain domain.

Adding a CNAME record

A practical example would be if you want to set up an email with your own domain, while you are using a mail provider such as Google or Sendgrid. In this case you usually have a mail subdomain (mail.mysite.com) that needs to point to that email service:

Name Is an alias of TTL(seconds)
mail ghs.googlehosted.com. 3600
Name Is an alias of TTL(seconds)
mail sendgrid.net. 3600

Or maybe you have your own email service that you want to point to your site’s IP address. Then you set up a CNAME to your site’s domain:

Name Is an alias of TTL(seconds)
mail mysite.com 3600

MX

MX records are necessary to send and receive e-mails. The record specifies towards which servers to deliver the mails. They also come with a priority indicator to help direct content through the fastest and most efficient servers.

Adding a MX record

NOTE

We offer the possibility to quickly set up the appropriate MX records for Google or Zoho with a simple click from our dashboard. You simply choose your mail provider and we set up the appropriate MX records.

For any other email solution, you’ll have to setup custom MX records for your emails to point to their servers. They will provide you with the specific instructions.

If you want to keep your old mail host, a solution would be to add an A-record for mail.mysite.com to the IP of your old mail host.

Name Will redirect to TTL(seconds)
mail IP address of the email service 3600

Then an MX record is added to mail.mysite.com:

Name Priority Target TTL(seconds)
@ 1 mail.mysite.com 3600

TXT

TXT records contain text information for sources outside your domain. You can use TXT records for various purposes, the most common ones being verifying domain ownership and ensuring email security.

Adding a TXT record

Verify domain ownership

For example, some webmaster tools like Google will ask you to add a TXT record to your domain to prove you are that domain’s real owner, displayed such as:

Name Value TTL(seconds)
@ google-site-verification= rXOxyZounnZasA8Z7oaD3c14Jdj... 3600

You can also add TXT records to verify subdomains:

Name Value TTL(seconds)
blog google-site-verification= rXOxyZounnZasA8Z7oaD3c14Jdj... 3600

Email security

In terms of email security, TXT records are commonly used for setting up the following records:

  • Sender Policy Framework (SPF) - verifies that a mail server is authorized to send email for a domain
  • DomainKeys Identified Mail (DKIM) - adds a digital signature to make sure the messages weren’t altered in the transit
  • Domain-based Message Authentication, Reporting and Conformance (DMARC) - lets you decide what happens with the emails that fail SPF and DKIM, instead of leaving it up to you ISP

SPF

SPF is a security mechanism created to prevent others from sending emails on your behalf. The general idea is to make sure all applications that send emails on your behalf (Google, MailChimp etc.) are included in your SPF, for examples here’s Google’s instructions on how to do this.

Your mail provider will guide you in setting up these records. For example, if you are using Google Apps to send all emails from your domain, you should add the following TXT record:

Name Value TTL(seconds)
@ v=spf1 include:_spf.google.com ~all 3600

Multiple SPF records are not recommended and will cause authorization problems. So if you’re using more apps/ services for emails (for your newsletter, support messages, etc.), you will have to update the existing SPF record with multiple mail servers.

Name Value TTL(seconds)
@ v=spf1 include:serverdomain.com include:_spf.google.com ~all 3600

DKIM

DKIM requires the addition of public keys into your DNS zone. The key is often provided to you by the organization that is sending your email, for example Google Apps, SendGrid etc. The key will be inserted directly into your zone as a TXT record.

It’s easy to impersonate a trusted sender over SMTP. This led to spam for end users that appeared to come from legitimate sources. Spoofing email from trusted domains is a popular technique for malicious spam and phishing campaigns, and DKIM makes it harder to spoof email from domains that use it.

If you are given a string representing the DKIM, it will usually look something like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAraC3pqvqTkAfXhUn7Kn3JUNMwDkZ65ftwXH58anno/bElnTDAd/idk8kWpslrQIMsvVKAe+mvmBEnpXzJL+0LgTNVTQctUujyilWvcONRd/z37I34y6WUIbFn4ytkzkdoVmeTt32f5LxegfYP4P/w7QGN1mOcnE2Qd5SKIZv3Ia1

Your provider will also give you a specific subdomain to use, usually something like dk._domainkey.

Name Value TTL(seconds)
dk._domainkey v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC... 3600
NOTE

Note that if your provider sends you a fully-qualified name that ends with your domain name, you should NOT include your domain name in the Name field when you add the TXT record. For example, if you receive dk._domainkey.yourdomain.com then you will only enter dk._domainkey in the Name field.

DMARC

In order to get started with DMARC, the sending domain needs to have an SPF and DKIM record published. Once the SPF and DKIM records are in place, you can configure DMARC by adding policies to your domain’s TXT records.

Name Value TTL(seconds)
_dmarc v=DMARC1; p=none 3600
Name Value TTL(seconds)
_dmarc v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc.rua@customddomain.com 3600

SRV

SRV records are used to establish connections between a service and a hostname, usually used for advanced email settings.

Adding a SRV record

Here is an example of SRV record required to set up Office 365:

Name Priority Weight Port Target TTL(seconds)
_sip._tls 100 1 443 sipdir.online.lync.com 3600

In the example above, _sip indicates the type of service and _tls indicates the protocol. The target is the name of the host that provides the service, in this case Office 365.

The priority establishes which services should be looked at first. The lower the number value, the sooner the SRV record will look at it.

The weight is used if two or more services have the same priority, to determine which line should come first. The higher the number, the sooner the SRV record will look at it.

See Also

CDN specifications

This section is dedicated to CDN related topics. We have built our own Content Delivery Network, [...]

Collaborators section

Bring your team on board! Here you can learn how to add a collaborator to your site and details [...]

Zone Management

This page provides an overview of the DNS section, domains, nameservers and the types of records you [...]

DNS Specifications

Here you can find details about DNS management and how the DNS failover works. We also use Amazon [...]