What is 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:
This record allows the MailChannels account examplecorp to send mail from
example.com.
A Domain Lockdown record is a space-separated list of fields:
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:
- 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.
To authorize a sub-account to also send from the domain:
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.
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.
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.
This allows sender IDs such as:
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:
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:
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:
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.
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.