What we write
Our template, in full. Public, reviewed, and short.
A Domain Connect template is the file a DNS provider runs when your customer approves a change. It is fixed and public, so what it can write is known before anyone clicks.
{
"providerId": "relaydns.dev",
"serviceId": "relay-connect",
"version": 1,
"hostRequired": true,
"syncPubKeyDomain": "relaydns.dev",
"syncBlock": false,
"syncRedirectDomain": "api.relaydns.dev,relaydns.dev",
"records": [
{
"type": "CNAME",
"host": "@",
"pointsTo": "%target%.connect.relaydns.dev",
"ttl": 3600
},
{
"type": "TXT",
"host": "relaydns-verify",
"data": "relaydns-verify=%token%",
"ttl": 3600,
"txtConflictMatchingMode": "Prefix",
"txtConflictMatchingPrefix": "relaydns-verify="
}
]
}Merged in public as Domain-Connect/Templates #1642. Logo and description lines left out.
hostRequired
The template will not run without a host, so it can never write to the root of a domain. A CNAME there is not valid DNS anyway.
%target% and %token%
The only two variables. target is a label issued for one setup; token is the proof for that setup. Everything else is fixed.
txtConflictMatchingPrefix
Only a TXT beginning relaydns-verify= at that host is ever replaced. Any other TXT stays exactly as it was.
syncPubKeyDomain
Every apply request is signed. The provider fetches our public key from this domain and checks it before writing.
syncRedirectDomain
Where the provider may send your customer back to afterwards. Nowhere else.
What we write
Two records. Nothing else.
This is our Domain Connect template, the file a provider runs when your customer approves. It was reviewed and merged in public.
Read the template%target%.connect.relaydns.dev
app.acme.com
a1b2c3.connect.relaydns.dev
Points the subdomain at a label issued for this setup alone.
relaydns-verify=%token%
relaydns-verify.app.acme.com
relaydns-verify=9f3e…
Ties the domain back to the request that asked for it.
hostRequired
Never the apex
Both records land under a subdomain your customer named.
txtConflictMatchingPrefix
Only its own TXT
An older relaydns-verify record is swapped. Other TXT records stay.
syncPubKeyDomain
Signed, checked first
The provider verifies our key before writing anything.
Coming soonThe email template is merged, and Cloudflare serves it only for our own account while testing finishes. Until then, those records are shown to copy.
One template, five groups.
relay-email is merged in #1912and Cloudflare serves it, but only for our own account while we finish testing. Until it opens up, these records are shown to copy, and nothing is written that nobody asked for.
- coreBounce MX on mail, SPF merge, DMARCAnything that sends
- byodkimOne TXT at the sender's selectorA sender with its own key
- easydkimThree CNAMEsKeys generated for you, as SES does
- trackingCNAME on linkClick tracking
- inboundMX on the domain being set upReceiving mail
Nobody loses their email to a button.
An inbound MX replaces whatever receives mail on that host, and a provider's approval screen may only list what is being added. So before offering one click for it we read the MX already there. If something would be displaced, one click is withdrawn and your customer is shown the records instead.
Get started
Try it on one domain. Nothing is charged until one connects in one click.
- 1Create an accountAn email and a password
- 2Make a project and an API keyThe key is shown once
- 3Connect your first domainOne call from your server
- The account and the key take about a minute.