Sending Invoices and Newsletters From Separate Subdomains

« Blog · By

A call that reaches every online shop sooner or later: a customer never received their invoice. You check — sent, accepted, delivered. At the customer's end it is sitting in the spam folder. Two weeks ago this was not happening, and nothing about the invoice has changed.

Something else changed: the seasonal campaign went out, 40,000 messages to a list last contacted a year ago. The invoice is paying for it now.

Why those two are connected

Receiving systems keep reputation per sending domain. If invoices, confirmations and marketing all leave under company.com, that produces one ledger. Complaints about the promotional send land in the same account as the invoices.

The imbalance is considerable, and it always runs the same way.

critical from 0.3% invoices confirmations newsletter all via company.com 0.01% 0.02% 0.42% 0.18% 0 0.1 0.2 0.3 0.4 0.5 complaint rate in percent
The invoice has an excellent rate. As long as it leaves under the same domain as the marketing, it is judged by the shared one anyway.

The split

The way out is to move the streams onto their own subdomains. A proven split looks like this:

SubdomainForCharacter
company.commail from people to peoplesmall volume, virtually no complaints
mail.company.comorder confirmation, invoice, password resetexpected mail, very low rate
news.company.comnewsletter, campaigns, product announcementsfluctuating rate, competes for attention

The first row is the most important and the most often forgotten. The main domain should stay reserved for the correspondence individual people actually write. It is the domain you are reachable under — and the only one whose standing should never be put at risk by sending volume.

How far the separation really carries

Honesty is in order here: subdomains are not a firewall. Receiving systems take the organisational domain into account — otherwise every bulk sender could shrug off any consequence with a new subdomain each week.

What the separation does achieve is nonetheless substantial:

  • The signals stay attributable. A provider seeing complaints on news. can throttle delivery there without touching mail.
  • A blocklist entry hits one stream only. With a single domain, everything stops at once.
  • The reports become readable. DMARC reports per subdomain say immediately which sending path has the problem.
  • A new subdomain under an established domain does not start at zero. It inherits part of the standing — which shortens the build-up noticeably without suspending the rules from warm-up.

What has to be set up

Every sending subdomain needs its own complete set of records. A common misconception is that SPF and DKIM are inherited. They are not.

news.company.com.                  TXT    "v=spf1 include:sender.example -all"
sel1._domainkey.news.company.com.  CNAME  sel1.dkim.sender.example.
_dmarc.news.company.com.           TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@company.com"

Only DMARC has an inheritance rule, and it is steered by sp= in the main domain's record:

_dmarc.company.com.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@company.com"

Without a record of its own, a subdomain follows the policy in sp=, and without sp= the one in p=. This is a place where mistakes hide well: set p=reject and forget a subdomain that has been sending invoices without DKIM for years, and you have switched those invoices off.

The opposite mistake is just as common and more dangerous: setting sp=none "to be safe". That leaves every conceivable subdomain — including invoice.company.com, which does not even exist — free for strangers to use, and that is exactly the address a fraudster would pick.

How many subdomains are too many

The temptation to split further — one subdomain per campaign, per country, per brand — is worth resisting. Reputation needs volume and regularity. Spread 20,000 messages a month across eight subdomains and you have eight times too little traffic for a standing to form anywhere.

As a rule of thumb: separate by what the recipient expects, not by the org chart. Mail the recipient asked for and mail that is offered to them are two streams. Anything beyond that scatters more than it protects.

The migration

Existing streams do not change domain in a day. A new subdomain has no history, even if the main domain has one. The usual route: set the subdomain up, move the smaller of the two streams first, raise its volume over two to three weeks, then move the second.

And: the sender in the From: line may change in the process, but it should stay recognisable. news@news.company.com is ugly; newsletter@news.company.com less so. What the recipient reads has a hand in whether they open the message — and open rate is one of the signals this whole subject turns on.