Module 7 · 7.1

English

Nederlands English Deutsch Français Español Italiano

Newsletters from your own domain

Module 7: Newsletters and mail from your website · Reading time: 11 minutes

Learning objective: After this lesson, you can connect a sending service so that your newsletter passes SPF, DKIM and DMARC on behalf of your own domain, and check in the headers whether that has succeeded.

Key concepts: sending service, From domain, Return-Path (bounce domain), DKIM domain (d=), alignment, own bounce domain via CNAME, DKIM via CNAME, subdomain for marketing, sending limit, warm-up

Why a newsletter is different from ordinary mail

You send a message to a customer or colleague from your own mailbox. A newsletter goes to hundreds or thousands of people at once. For recipients like Gmail, Outlook.com and T-Online, that's a different kind of traffic: bulk mail. They look at it more strictly, because almost all spam is also bulk mail.

Three things make the difference between a newsletter that lands in the inbox and one that disappears into spam:

Technology: the mail must be demonstrably from your domain. SPF, DKIM and DMARC arrange that, and especially the alignment between them.
Reputation: the servers and domain you send with must have a good name (lesson 5.2).
Behaviour of your recipients: do they open your mail, or click "This is spam"? That depends on your list and on consent (lesson 7.2).

This lesson covers the first point. The basics of the records are in the DNS course, lesson 7.4. Here we look at how to check in practice that everything is correct.

Why not just send via your own mailbox?

It can be tempting to send a newsletter with BCC from your regular mail program, or with a mailing list on your hosting package. For a small association of thirty members who know each other, a mailing list is fine. For a real newsletter it isn't, for four reasons:

Sending limits. Almost every provider limits how much mail a mailbox or package may send per day, to limit abuse. At WebOké you can see this limit in DirectAdmin under the user statistics; with other providers it's in the terms or the customer panel. A newsletter to 2,000 people goes well beyond that.
Shared reputation. You share the sending server with other customers. If recipients complain about your newsletter, that also affects their mail, and the other way round.
No unsubscribe button and no bounce management. A sending service automatically adds the unsubscribe headers to every mail (lesson 7.2), removes addresses that no longer exist from your list, and processes complaints. You'll never manage that properly by hand.
Privacy. One wrong click and you send everyone each other's address in the To field.

A sending service (a newsletter service such as Laposta, Brevo, MailerLite or Mailchimp, or a transactional service for confirmations and invoices) is built for this job. But then someone else sends on behalf of your domain, and you need to prove that.

Three domains in one email

Every email has at least three places where a domain appears. In ordinary mail from your own mailbox these are usually the same. With a sending service, they're not automatically the same.

Place	Where you see it	Who checks it
From (visible sender)	`From: Nieuws <nieuws@example.com>`	DMARC looks at this domain
Return-Path (envelope sender, bounce address)	`Return-Path: <bounce-8f3a@mail.sender.example>`	SPF checks this domain
DKIM domain	`DKIM-Signature: ... d=sender.example; s=s1; ...`	DKIM checks the signature of this domain

DMARC (lesson 4.4) approves a mail if SPF or DKIM passes, and the domain that passed is aligned with the From domain. Under the default setting (relaxed), aligned means it's the same organisational domain: mail.example.com is aligned with example.com, but sender.example is not.

Without your own settings, a newsletter then looks like this:

Return-Path: <bounce-8f3a@mail.sender.example>
From: Nieuws <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=sender.example; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=mail.sender.example;
       dkim=pass header.d=sender.example;
       dmarc=fail header.from=example.com

SPF passes and DKIM passes, but both for the domain of the service. Neither is aligned with example.com, so DMARC fails. If your DMARC policy is set to p=none, you'll only notice this in your reports (lesson 4.5). If it's set to quarantine or reject, your newsletter disappears into spam or is rejected.

The solution: authenticate your domain with the service

Every serious sending service has a step called "authenticate domain", "verify domain" or "set up sender domain". The service then gives you a few records to put in your DNS. Usually these are:

DKIM via CNAME, for example s1._domainkey.example.com pointing to a name at the service. The service then signs your mail with d=example.com. This is the most important record: it makes DMARC pass via DKIM.
Your own bounce domain, often a CNAME on a subdomain, for example bounce.example.com pointing to the service. The Return-Path then becomes ...@bounce.example.com. SPF for that subdomain points via the CNAME to the service, and SPF is then also aligned. Not every service offers this; DKIM alone is enough for DMARC.
Sometimes an SPF include in your own record, if the service uses your main domain as the Return-Path. Only do this if the service asks for it, and always add it to your existing SPF record (lesson 4.2).
Sometimes a verification TXT record to prove the domain is yours.

With the right settings, the same newsletter looks like this:

Return-Path: <bounce-8f3a@bounce.example.com>
From: Nieuws <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Always copy the names and targets exactly from your service's dashboard. They differ per service and sometimes per account.

A separate subdomain for marketing?

Large senders often use a dedicated subdomain for newsletters, such as nieuws.example.com or info.example.com, with nieuwsbrief@nieuws.example.com as the sender. The idea: the reputation of your marketing mail is then separate from your ordinary mail. If a campaign goes wrong, your daily mail with customers suffers less.

For anyone sending a newsletter a few times a month, this isn't necessary. It does make management more complicated: the subdomain needs its own DKIM, and your DMARC policy for subdomains (sp=) must match. Consider it if you send a lot, or if you have a lot of transactional mail (orders, passwords) alongside newsletters. You never want that to suffer because of a failed campaign.

Important: don't set an MX record on a sending subdomain pointing to the service if you don't need one, and never change the MX of your main domain for a newsletter. The MX determines where mail arrives; replies to your newsletter should simply land in your own mailbox.

Warming up: don't start with everything at once

Are you sending for the first time with a new service or a new domain, or suddenly sending ten times as much as usual? Then recipients don't know you yet. Large recipients slow down unfamiliar senders (with Microsoft you'll see temporary refusals such as 451 4.7.500, lesson 6.4). So start small: first your most active readers, then a larger portion each time. This is called warming up. With a shared sending service, the service handles much of this itself, but even there your domain's reputation counts.

In practice: what it looks like in a panel

You put the service's records in the DNS administration of your domain. At WebOké that's the DNS tab in My WebOké or DNS Administration in DirectAdmin; with other providers it's called DNS management, zone management or DNS records, and works in a similar way. Watch out for the two classic mistakes: the domain name appearing twice in the name (s1._domainkey.example.com.example.com), and creating a TXT record where the service asks for a CNAME.

Done? Send a test newsletter to your own Gmail or Outlook.com address and open the headers (lesson 1.5). In Authentication-Results you want to see: dkim=pass with header.d= your domain, and dmarc=pass.

Summary

A newsletter is bulk mail: recipients look at it more strictly. Use a sending service, not your ordinary mailbox.
Every email has three domains: From (DMARC), Return-Path (SPF) and the DKIM domain d=.
DMARC only passes if SPF or DKIM passes for a domain that's aligned with the From domain.
Authenticate your domain with the service: DKIM via CNAME is the most important, your own bounce domain is a bonus.
Check with a test email: dkim=pass header.d=<your domain> and dmarc=pass. Start small with a new service.

Quiz

Exercise

Exercise Z7.1: Checking a newsletter's alignment. Send a newsletter from your own sending service to yourself (or use the example file nieuwsbrief-kopregels-1.txt from the course) and paste in the headers. Fill in: the From domain, the Return-Path domain, the DKIM domain (d=) and whether you think DMARC passes (yes/no) and via which route (SPF, DKIM, both or neither). The program parses the headers itself, checks the DKIM selector live in the DNS and the DMARC record of the From domain, and compares its outcome with yours.

Exercise Z7.1: Checking a newsletter's alignment

File for this exercise: nieuwsbrief-kopregels-1.txt, nieuwsbrief-kopregels-2.txt, kopregels-1.txt

Paste the headers of a newsletter you send yourself, or choose an example file. The server parses the headers itself (in memory only) and, for real headers, looks up the DKIM key and the DMARC record.

Which headers?

Pasted headers (optional)

From domain

Return-Path domain

DKIM domain (d=)

Does DMARC pass?

Via which route?

What you enter and what we find isn't stored. Your browser remembers your answers and whether you've passed the exercise. If you're signed in, we only save that you got the exercise (almost) right in My courses; you can delete that there too.

Cookies at WebOké

Cookie settings

Necessary

Marketing