Newsletter and sending services

Module 7: Connecting external services · Reading time: 8 minutes

Learning objective: After this lesson, you'll be able to connect a newsletter or sending service so your mail doesn't end up in spam.

Key concepts: domain verification (authentication), DKIM via CNAME, selector, SPF include only when the service asks for it, limit of 10 lookups, DMARC alignment via DKIM, don't touch MX

Why a newsletter service asks for records

A newsletter service such as Mailchimp, Brevo or MailerLite, or a sending service for invoices and confirmations, sends mail using your address as the sender, for example nieuws@example.com. But the mail comes from that service's servers, not from your mail server.

Recipients such as Gmail and Outlook.com check: is this server allowed to send mail on behalf of example.com, and does the signature check out (lessons 4.3 to 4.5)? If this isn't set up, your newsletter ends up in spam, or the service rewrites your sender address to one of its own. That's why the service asks you to authenticate your domain: a few records in your DNS.

What the service does not need: your MX records. Those determine where your incoming mail goes. A newsletter is only sent out; replies simply arrive in your own mailbox. So never change your MX for a newsletter service.

DKIM via CNAME

Most services let you set up DKIM using CNAME records. The service keeps the key itself; you just point to it. That way, the service can replace the key without you having to do anything.

At the time of writing, Mailchimp uses two records for newer accounts:

k2._domainkey.example.com.   3600   IN   CNAME   dkim2.mcsv.net.
k3._domainkey.example.com.   3600   IN   CNAME   dkim3.mcsv.net.

Older accounts often have a single record, k1._domainkey, pointing to dkim.mcsv.net. Other services use different selectors, such as brevo1._domainkey or ml._domainkey. Use exactly what your service's dashboard shows. The names and targets differ per service and per account, and they sometimes change.

k2 and k3 are selectors (lesson 4.4). Each service has its own selector, so the records don't get in the way of each other or of the DKIM key of your own mail server.

Three mistakes almost everyone makes at some point

1. Duplicate domain name. Your panel often appends your domain name automatically. If you enter k2._domainkey.example.com, it becomes k2._domainkey.example.com.example.com. Enter only k2._domainkey, unless your panel explicitly asks for the full name. Below the field, it usually shows what the name will become.
2. Forgetting the trailing dot on the value. Without the dot, your panel might turn dkim2.mcsv.net into dkim2.mcsv.net.example.com. Some panels add the dot themselves; check what the record looks like after saving (lesson 2.2).
3. TXT instead of CNAME. If the service asks for a CNAME, create a CNAME. A TXT record containing dkim2.mcsv.net as text does nothing.

SPF: only when the service asks for it

With SPF, many people think: every service that sends mail must be in my SPF record. That's not always true.

SPF checks the address in the mail's envelope (the Return-Path), not the sender address you see. Many newsletter services, including Mailchimp, use their own domain in the envelope. Their SPF check therefore runs against their own domain, and your SPF record plays no role. That's why Mailchimp doesn't ask for an include in your SPF record.

Other services do use an address on your domain in the envelope, or have you set up your own subdomain (for example bounce.example.com). These ask for an include: in your SPF record, or for an SPF record on that subdomain. So do exactly what the service asks:

• if the service asks for an include, add it to your existing SPF record, never to a second one (lesson 4.3);
• if the service doesn't ask for it, don't add anything.

Why be sparing with this? An SPF record may cause at most 10 DNS lookups during a check. Every include, a, mx, exists and redirect counts, and a service's includes often contain further includes themselves. With a web host, Microsoft 365, a newsletter service, an accounting package and a CRM, you can easily go over the limit. That makes your entire SPF record invalid (permerror). Remove includes for services you no longer use, or that don't ask for one.

DMARC: this is what it's all about

DMARC (lesson 4.5) approves a message if SPF or DKIM passes and matches the domain in the sender address (alignment). With a newsletter service that uses its own domain in the envelope, SPF can never align with example.com. DMARC can then only pass via DKIM: a signature with d=example.com, which you only get once you've set up the CNAME records.

So:

1. set up the service's DKIM records first;
2. wait until the service reports that your domain is authenticated;
3. send a test message to yourself and check the headers to see if DKIM shows pass with d=example.com;
4. only then change your DMARC policy from none to quarantine or reject.

If you don't have a DMARC record yet, many services will ask you to create one. Start with p=none (lesson 4.5). Since 2024, major recipients such as Gmail and Yahoo have required bulk senders to have a DMARC record.

Replies and bounces

If a reader replies to your newsletter, it goes to the reply address you set in the service, and via your MX to your own mailbox. Undeliverable messages (bounces) go to the envelope address and therefore to the service, which handles them. Here too, you don't need to change anything about your MX.

In practice: what it looks like in a panel

In the example panel DirectAdmin, you open DNS Administration, click Add Record, choose CNAME, enter only k2._domainkey under Name and dkim2.mcsv.net. with the dot under Value. Then you do the same for k3. In My WebOké, it works the same way on the DNS tab; the window shows the full name below the name field and warns you if the dot is missing.

In other panels, such as cPanel, Plesk, Cloudflare or your registrar's DNS screen, the buttons are named differently, but they're the same fields. With Cloudflare, watch out for the proxy: set records for DKIM to "DNS only" (Cloudflare usually does this automatically for CNAMEs containing _domainkey).

Summary

• A newsletter service doesn't need your MX records; leave them as they are.
• DKIM is usually set up via CNAME records with their own selector. Use exactly what your dashboard shows.
• Enter only the first part of the name, and watch out for the trailing dot in the value.
• Only add an SPF include when the service asks for it, in your existing record, and stay under 10 lookups.
• With such services, DMARC passes via DKIM alignment; only tighten your policy once DKIM is working.

Quiz

Exercise

Exercise Z7.4: Recognising a newsletter service. Look at how a newsletter service sets up its own DKIM.

1. Find the CNAME record of k2._domainkey.mailchimp.com and of k3._domainkey.mailchimp.com. Write down the target names.
2. Find the SPF record of mailchimp.com and count how many include: parts it contains.

The check looks up the records live when you submit.

Exercise O7.4: Setting it up yourself in your practice zone. Connect a simulated newsletter service to your practice zone <code>.dnspractice.eu. In the practice zone, you'll use the fake service newsletter-demo.dnspractice.eu; for your real domain, you'd use the values from your newsletter service's dashboard.

1. Create a CNAME k2._domainkey.<code>.dnspractice.eu pointing to dkim2.newsletter-demo.dnspractice.eu. Watch out with the name: no duplicate zone appended.
2. Create a CNAME k3._domainkey.<code>.dnspractice.eu pointing to dkim3.newsletter-demo.dnspractice.eu.
3. Make sure <code>.dnspractice.eu has exactly one SPF record that starts with v=spf1 and ends with ~all or -all. Do not add an include for this service.
4. Leave your MX records on <code>.dnspractice.eu as they are: this service doesn't need them.

Further reading

These pages describe the steps in WebOké's panels (DirectAdmin and My WebOké). In other panels, it works the same way.

• Managing DNS records in My WebOké (with examples for CNAME, TXT, and external services)
• DirectAdmin guide 5.4: CNAME records and the trailing dot
• DirectAdmin guide 5.8: Turning on and checking DKIM
• DirectAdmin guide 5.7: Setting up and adding to SPF
• What is DMARC? Explanation in plain language