How to add DNS records from an email or marketing service

When a newsletter tool, CRM, webinar platform or email service asks you to add DNS records, you add them next to the records you already have. The one exception is SPF: a domain has a single SPF record, so you add the service's include to the existing record instead of creating a new one. At LJPc you do this in Plesk or in the customer portal, and the service can usually verify your domain within an hour.

With an LJPc hosting plan, SPF, DKIM and DMARC for your own mail are already in place, so you only add what the new service needs. This guide shows what to do with each type of record, how to add them step by step, which records affect your email or website, and how to check that everything is set up correctly.

Which DNS records will a service ask for?

Services that send email on behalf of your domain or connect your domain to their platform almost always ask for a few of the records below. For each record, look at two things: the type and the name. Together they tell you whether you are adding something or replacing something.

Got a record that does not fit this table? Check whether that name already has a record. A record on a new name leaves everything that works untouched; changing an existing name does not.

Where do you add the records?

That depends on who manages the DNS for your domain:

• Hosting plan at LJPc: you usually manage DNS in Plesk. You open Plesk from the customer portal without a separate login, see Open Plesk from the customer portal.
• DNS management only at LJPc: you manage the records in the customer portal, under Domains in the Services menu.
• Nameservers with another provider: you add the records there. Only the DNS behind your nameservers counts.

Not sure which applies to you? Open your domain in the portal and look at DNS records. If it says the records are managed in Plesk, the Edit in Plesk button takes you straight to the right place. Every screen and button for both routes is covered in Manage DNS records in the customer portal and Plesk.

How to add a service's DNS records, step by step

1. Open the page with the records in the service's dashboard, often called domain authentication, verify domain or sender domain. Copy each value with the service's copy button rather than retyping it.
2. Check what is already in your DNS. If the same name already has a record of the same type, edit that record instead of adding a second one. This matters most for SPF on @ and DMARC on _dmarc.
3. In Plesk click Add Record, or in the portal click Add record under DNS records, and choose the type the service specifies.
4. In the name field, enter only the part before your domain name. If the service shows s1._domainkey.yourdomain.com, you enter s1._domainkey. In Plesk this field is called Domain name (Mail domain for an MX record) and your domain is already shown after it. For the main domain itself you leave the field empty in Plesk. In the portal you enter @ for the main domain; if you type the full name anyway, the portal strips your domain off for you.
5. Enter the value:
   • CNAME: in Plesk under Canonical name, in the portal under Content. Copy the full target name, for example dkim1.mail.example.com.
   • TXT: in Plesk under TXT record, in the portal under Content. Paste the whole value in one go, without quotation marks around it.
   • MX: in Plesk under Mail exchange server, with the priority under Specify priority of mail exchange server. In the portal you fill in Content and Priority.
6. Leave the TTL at its default unless the service asks for something else.
7. Save the record. In the portal you click Save. In Plesk you click OK and then Update above the list: only then does the record go into your DNS zone. Adding several records? Queue them all first, then click Update once.
8. Go back to the service and run its check, using a button such as Verify or Authenticate. If it does not pass yet, try again a little later. How long to wait is explained below.

Add an SPF include without breaking your email

A domain may have only one SPF record. With two, SPF fails for all your mail. So you add the service's include to the record you already have, before the closing all. With an LJPc hosting plan it looks like this:

; What you already had
v=spf1 include:_spf.ljpc.network -all

; What the service shows as an example
v=spf1 include:_spf.example.com ~all

; What you end up with
v=spf1 include:_spf.ljpc.network include:_spf.example.com -all

Keep three things in mind:

• Keep include:_spf.ljpc.network. It tells receiving servers that our outgoing mail servers may send email for your domain. Remove it, or replace the whole record with the service's example, and email from your mailboxes and your website may be rejected or end up in spam.
• Keep your own ending. Services often use ~all in their example. If your record ends in -all, leave it that way.
• Stay within ten lookups. Every include costs at least one DNS lookup, often more, and an SPF record may use ten in total. The LJPc include costs one. An online SPF checker counts them for you. Going over? Remove the include of a service you no longer use first.

It is also worth checking whether the include is needed at all. Many sending services use their own return address on a subdomain, such as em1234.yourdomain.com, which you set up with a CNAME or MX record. Receiving servers then check SPF on that subdomain, and the SPF record on your main domain stays as it is. The service's documentation tells you which records are required. How an SPF record is built is explained in What is an SPF record?

DKIM records and long keys

With DKIM, the service signs your mail with its own key. You usually get two or three CNAME records on names ending in ._domainkey, or one TXT record with a long key. Each service uses its own name (selector), so these records sit alongside the LJPc record default._domainkey. Keep that record as long as you also send mail through us.

• A long TXT key goes in as one piece, without quotation marks. We split values longer than 255 characters into chunks for you. If the service shows the key in several quoted chunks, paste the chunks directly after each other and leave out the quotation marks and the space between them. In the portal, quotation marks you copy along become part of the key, and then it no longer matches.
• A CNAME with an underscore in its target, such as selector1._domainkey.example.com, is accepted by Plesk. The portal shows Invalid hostname for such a target. In that case, create a support ticket and include the records from the service.
• Every character counts. One character too many or too few and the DKIM check fails. Always copy with the service's copy button.

How DKIM works and how to check it at LJPc is covered in What is DKIM?

The service also asks for DMARC

An LJPc hosting plan comes with a DMARC record on _dmarc by default: v=DMARC1; p=quarantine. A service that asks for DMARC usually wants a valid record to exist, and p=quarantine is stricter than the p=none in many examples, so it meets the requirement. Do not add a second record: with two DMARC records on the same name, no policy applies at all. Want to receive a service's reports? Add its rua address to the existing record. With DNS management only at LJPc and nothing on _dmarc, you create one. The options are explained in What is DMARC?

Which records affect your website or email?

Most records from a service go on a new name and leave everything that already works alone. Watch out for these three:

• An MX record on your main domain decides where all incoming mail goes. Replace mx1.ljpc.email and mx2.ljpc.email with a service's MX and your mail arrives at that service from then on, no longer in your LJPc mailboxes. Only do this when you move your email to that service, see What is an MX record? An MX record on a subdomain, such as send or bounce, handles bounces and feedback for the service and leaves your own mail alone.
• An A record on your main domain or a CNAME on www decides which website visitors see. If a landing page, webinar or website builder asks for this, its page replaces your current website at that address. Use a subdomain such as webinar.yourdomain.com and your website stays in place, with the service's page running next to it. How to point a subdomain at a service is explained in What is a CNAME record?
• A record on a name that already exists. Besides your main domain and www, an LJPc zone usually also has records such as mail, webmail, ftp, autodiscover and autoconfig. The last two help email apps find your settings automatically. If a service asks for a record on one of those names, create a support ticket first.

Can old DNS records be removed?

Only the records of a service you no longer use. Remove the include of a previous newsletter tool from your SPF record, which also frees up room within the ten lookups, and delete that service's DKIM records. Always keep these:

• include:_spf.ljpc.network in your SPF record and the TXT record default._domainkey, as long as you send mail through LJPc;
• your DMARC record on _dmarc;
• the MX records mx1.ljpc.email and mx2.ljpc.email (or spamfilter-mx1.ljpc.systems with the premium spam filter), as long as your mail arrives at LJPc;
• the A, AAAA and www records of your website;
• verification records of services you still use, because some services check them again later.

Not sure who a record belongs to? Leave it and ask first. A record that was still in use is often only missed once mail stops arriving.

How long until the records work?

At LJPc, a new or changed record is usually on our nameservers within a minute. A name nobody has looked up yet can be found right away. If the service checked the name before you added the record, that empty answer can be cached for up to an hour, so try the verification again after an hour. A changed record, such as your SPF record, is updated everywhere within the TTL, which at LJPc is usually one hour. Expect 24 to 48 hours only when you change your domain's nameservers. If another provider runs your DNS, that provider determines the speed. More in What is DNS propagation?

How to check that the records are set up correctly

The most reliable check is the service's own verify button, as it looks at exactly what it needs. To look yourself, use Command Prompt (Windows) or Terminal (macOS and Linux):

• SPF and verification codes on your main domain: dig TXT yourdomain.com +short, or on Windows nslookup -type=TXT yourdomain.com.
• A DKIM CNAME from a service: dig CNAME s1._domainkey.yourdomain.com +short, or on Windows nslookup -type=CNAME s1._domainkey.yourdomain.com.

Nothing showing yet? Ask our nameserver directly, with no cache in between: add @ns1.ljpc.network to the dig command, or ns1.ljpc.network to the end of the nslookup command. If the record is there, it is a matter of waiting for caches to expire. If it is not there either, check that you clicked Update in Plesk and that the name is right. See two lines starting with v=spf1? Merge them into one.

Once the service is happy, send a test email through it to an address at another provider and view the original message source. If the Authentication-Results header shows dkim=pass and dmarc=pass for your domain, you are all set. More checks are in Troubleshoot DNS problems with dig and nslookup.

Stuck? Create a support ticket with the records the service gave you, and we will help you out.