Skip to main content

​
Domain Lockdown

Domain Lockdown is a DNS-based security feature that tells MailChannels which accounts or sender identities may send email from your domain. MailChannels blocks mail when the authenticated account or sender identity is not listed in your DNS record. For each domain you send from, create a TXT record at the _mailchannels subdomain: 
_mailchannels.example.com TXT v=mc1 auth=examplecorp
This record allows the MailChannels account examplecorp to send mail from example.com.

​
Record format

A Domain Lockdown record is a space-separated list of fields: 
_mailchannels.example.com TXT v=mc1 auth=examplecorp senderid=examplecorp|x-authsender|billing@example.com sidw=examplecorp|x-authsender|billing*@example.com
  • v=mc1 identifies the Domain Lockdown record version. Always include this field.
  • auth= allows a MailChannels account or sub-account ID to send from the domain.
  • senderid= allows one exact sender ID.
  • sidw= allows one sender ID pattern with a limited wildcard *.
You must include at least one auth, senderid, or sidw field to specify the authorized account or sender. You may include more than one auth, senderid, or sidw field in the same record. A message is allowed if any field matches.
Domain Lockdown by Cloudflare Worker ID (cfid) is no longer supported as of August 31, 2024.

​
Finding your account ID and sender ID

Your MailChannels account ID is shown in the panel footer when you log in. If your plan supports sub-accounts, sub-account IDs are listed in the Sub-Account panel. To find a sender ID, check the headers of a message sent through MailChannels: 
X-MailChannels-SenderId: examplecorp|x-authsender|billing@example.com
X-MailChannels-Auth-Id: examplecorp
Content-Type: text/plain; charset="utf-8"
Date: Mon, 22 Aug 2022 14:15:57 -0500
From: billing@example.com
To: customer@example.net
Subject: Your invoice is ready
  • Use the X-MailChannels-Auth-Id value in an auth= field. Note that messages sent by a sub-account will show the sub-account ID here, not the parent.
  • Use the X-MailChannels-SenderId value in a senderid= field, or as a reference when writing a sidw= pattern.

​
Choosing a lockdown method

Use auth when every sender under a MailChannels account should be allowed to send from the domain. 
_mailchannels.example.com TXT v=mc1 auth=examplecorp
To authorize a sub-account to also send from the domain: 
_mailchannels.example.com TXT v=mc1 auth=examplecorp auth=examplecorp_sub
This is the simplest setup and works well when a small number of accounts control all authorized sending for the domain. Use senderid when only specific sender identities should be allowed. 
_mailchannels.example.com TXT v=mc1 senderid=examplecorp|x-authsender|billing@example.com senderid=examplecorp|x-authsender|alerts@example.com
Messages from the same MailChannels account with any other sender ID are blocked by this record. Use sidw to allow a controlled group of sender IDs without listing every address individually. 
_mailchannels.example.com TXT v=mc1 sidw=examplecorp|x-authsender|*.head@example.com
This is useful for hosting providers, agencies, or platforms where multiple customers send through the same MailChannels account and auth would be too broad.

​
Sender ID wildcard

The sidw field supports one * wildcard in the sender part of the sender ID. The wildcard matches any number of characters. 
_mailchannels.example.com TXT v=mc1 sidw=examplecorp|x-authsender|billing*@example.com
This allows sender IDs such as: 
examplecorp|x-authsender|billing.no-reply@example.com
examplecorp|x-authsender|billing.alerts@example.com
examplecorp|x-authsender|billing@example.com
sidw patterns must follow these rules:
  • Format: exactly three pipe-separated parts: <account>|<sender-type>|<sender>.
  • Pipe character: | is always a separator. Do not include a literal | in the sender part; use * to match across that portion instead.
  • Constraint: edge cases such as <account>|mailer-daemon|<clientip>|NOTNDR are not supported.
  • Wildcard: one wildcard is permitted only in the sender part. A standalone wildcard, such as examplecorp|x-authsender|*, is prohibited.
Invalid sidw patterns are skipped. Use Testing Your Setup to confirm that your record matches the sender IDs you expect.

​
Escaping in sidw patterns

In the sender part of a sidw pattern, * is a wildcard. To match a literal asterisk, write \*. To match a literal backslash, write \\. For example, this record matches examplecorp|x-authsender|*depart\billing@example.com and examplecorp|x-authsender|*depart\alerts@example.com: 
_mailchannels.example.com TXT v=mc1 sidw=examplecorp|x-authsender|\*depart\\*@example.com
Escaping any other character, such as \a, makes the sidw pattern invalid. Some DNS providers process backslashes before publishing the TXT record. After creating the record, verify the value DNS returns: 
resolvectl query --type=TXT _mailchannels.example.com
MailChannels evaluates the published TXT value, so adjust your input until DNS returns the intended record.

​
Testing your setup

After publishing the DNS record, confirm the expected TXT value is visible: Use the check-domain tool, or use the check-domain API to verify: 
#!/usr/bin/env bash
# Check that a domain's DKIM, SPF, and Domain Lockdown records are configured
# correctly and have propagated.
set -u
: "${MAILCHANNELS_API_KEY:?Set MAILCHANNELS_API_KEY before running}"
: "${DOMAIN:?Set DOMAIN (the sending domain, e.g. example.com)}"

curl -X POST "https://api.mailchannels.net/tx/v1/check-domain" \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: $MAILCHANNELS_API_KEY" \
  -d @- <<JSON
{
  "domain": "$DOMAIN"
}
JSON

​
Troubleshooting invalid sidw patterns

Use this table for reference when a sidw rule is present in DNS but does not match the sender ID you expect. Invalid sidw patterns are skipped while MailChannels continues evaluating any other fields in the record.
Invalid patternWhy it is skipped
sidw=*|x-authsender|sender*@example.comWildcard * is allowed only in the sender part.
sidw=examplecorp|x-authsender|*The wildcard cannot be the entire sender part.
sidw=examplecorp|x-authsender|*sender*@example.comMore than one wildcard is present.
sidw=examplecorp|x-authsender|sender|*@example.comThe extra | creates a fourth part. sidw must have exactly three pipe-separated parts.
sidw=examplecorp|x-authsender|se\nder*@example.com\n is not a valid escape sequence. In the sender part, only \* and \\ are valid escapes.

​
Best practices

  • Start with the narrowest rule that matches your sending model: auth for one trusted account, senderid or sidw for shared sending environments.
  • Keep records simple and prefer a few clear fields over broad wildcard patterns.
  • Review Domain Lockdown records when you add new sending systems, customer domains, or sender ID formats.
  • Remove old auth, senderid, and sidw fields when they are no longer needed.