Custom DNS Records on Winnr Domains: Add TXT, CNAME, A & AAAA Without Breaking Mail

If you've ever needed to add a Google Search Console verification, point a subdomain at a landing page builder, or set your own DMARC policy on a Winnr-managed domain, you used to have to ask support. Now you can do it yourself from the dashboard or the API -- without any risk of breaking the records that keep your mail flowing.

Why We Built This

Winnr handles the hard parts of cold email infrastructure: SPF that aligns across hundreds of sending IPs, DKIM keys that match your mailcow signing config, MX records that route to your inbound server, and click-tracking CNAMEs that keep your engagement data flowing. Those records are not optional -- get one wrong and inbound stops or your authentication fails.

But there's a whole second category of DNS records that have nothing to do with mail and everything to do with running a business on your domain:

• Google Search Console, Bing Webmaster Tools, Facebook Business Manager, and a dozen other platforms all want a TXT record at your apex to prove you own the domain.
• Marketing teams want subdomain CNAMEs pointing at landing-page builders (HubSpot, Webflow, Framer), analytics endpoints, and shortlink services.
• Compliance and security teams want custom DMARC policies -- different report destinations, a specific pct, a softer or stricter enforcement level than the default.
• Engineering teams want A records pointing at servers, AAAA records for IPv6, CAA records for certificate authority pinning.

None of those should require a support ticket. They also shouldn't be allowed to clobber the records that make mail work. The Custom DNS feature draws a clean line between the two.

What You Can Add

You can create, update, and delete the following record types on any Winnr-managed domain:

Each record has a TTL you can set between 60 seconds and 24 hours (default 300 seconds, which is what Winnr uses for the records it manages). Changes propagate at the speed of your DNS provider -- usually under a minute for Cloudflare and CloudDNS, sometimes longer for Route 53.

What Stays Protected

Eight categories of records are off-limits, because changing them would break inbound mail, outbound authentication, or click tracking:

• inbound.<your-domain> A record -- points at your mailcow inbound server
• Apex MX record -- routes inbound mail to inbound.<your-domain>
• Any *._domainkey TXT record -- DKIM signing keys
• Apex TXT records starting with v=spf1 -- your SPF policy
• s1, s2, s3... TXT records -- SPF overflow subdomains (used when your SPF includes more IPs than fit in a single TXT record)
• track.<your-domain>, inst.<your-domain>, emailtracking.<your-domain> CNAMEs -- click and open tracking

If you try to add a record that collides with any of these, the API returns a clear error code (managed_record_collision) with a human-readable reason. The check runs before anything is written to your DNS provider, so a rejected request leaves your zone untouched.

One important nuance: TXT records at the apex are allowed as long as they aren't SPF. Google site verification (google-site-verification=...), Stripe Apple Pay verification, and similar tokens live happily at the apex alongside your SPF record without any conflict -- DNS allows multiple TXT records at the same name, and only the SPF-prefixed one is treated as policy.

DMARC Override

DMARC is a special case. The Winnr default is v=DMARC1; p=reject; rua=mailto:dmarc-reports@<your-domain>, which is the right policy for cold email in most cases. But some teams need something different:

• A different reporting address that ties into your existing DMARC aggregator (Postmark, dmarcian, EasyDMARC, Valimail)
• A softer policy (p=quarantine or p=none) during a phased rollout
• Additional tags like sp= for subdomain policy, pct= for partial enforcement, or fo= for forensic reporting

Custom DNS has a dedicated DMARC override path, separate from the general custom-record table. Set your value once, and Winnr stores it on your domain. Every time Winnr re-applies DNS records (on initial setup, after a domain repair, or during any future re-sync), it reads your override first and writes your value instead of the default. You don't have to re-enter it.

Reset to the default at any time, also from the dashboard.

How to Add a Record

From the dashboard:

1. Open your Domains page and find the domain you want to edit. Click the row's action menu and choose Manage DNS, or navigate directly to app.winnr.app/domains/<domain-id>.
2. Open the DNS Records tab. You'll see three sections: the records Winnr manages (read-only), your DMARC policy (editable), and your custom records.
3. Click Add record. Pick a type, enter the name (use @ for the apex, otherwise the short subdomain), set the value, and adjust the TTL if needed.
4. Save. The record is created at your DNS provider immediately and shows up in the table. Use dig or your favorite DNS checker to confirm propagation -- typically under a minute.

To edit or delete a record, hover the row and use the pencil or trash icons. Edits replace the record at your DNS provider in a single atomic write -- your record never disappears mid-update.

Using the API

Every dashboard action has a matching REST endpoint. The full schema is in our API documentation, but here are the basics:

List custom records

GET /v1/domains/{domain_id}/custom-dns-records

Create a record

POST /v1/domains/{domain_id}/custom-dns-records

Body:

{
  "name": "_test",
  "type": "TXT",
  "value": "google-site-verification=abc123",
  "ttl": 300
}

Update a record

PATCH /v1/domains/{domain_id}/custom-dns-records/{record_id}

Delete a record

DELETE /v1/domains/{domain_id}/custom-dns-records/{record_id}

Set a DMARC override

PUT /v1/domains/{domain_id}/dmarc

Body: {"value": "v=DMARC1; p=quarantine; rua=mailto:dmarc@your-domain.com"}

Reset DMARC to the Winnr default

DELETE /v1/domains/{domain_id}/dmarc

Authentication is the same as the rest of the Winnr API -- either a Firebase ID token from your dashboard session or a wnr_ API token. The same validation rules apply to API writes as to dashboard writes: managed-record collisions return a 409 with a clear error code, and the change is rejected before reaching your DNS provider.

Provider Support

Custom DNS works on every Winnr-supported DNS backend:

• Winnr-managed Cloudflare -- the default for most customers. Records propagate in seconds.
• Bring-your-own Cloudflare -- if you connected your own zone using your own Cloudflare API token, Winnr writes records via that token directly to your account.
• Route 53 -- for domains hosted in AWS.
• CloudDNS (accounts 1, 2, and 3) -- Winnr's redundant DNS infrastructure for domains that aren't on Cloudflare.

Domains with manual or external DNS providers (where you manage records yourself at a third-party registrar) don't show the Custom DNS Records tab -- you already have full control over those zones outside of Winnr.

Custom DNS is available to all paid Winnr plans (Startup and Enterprise) and to any billing-exempt account.

Related guides: Set up your domains correctly with our deliverability audit checklist, see our cold email best practices guide, or learn how BIMI uses DNS to display your logo next to outbound mail.