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, the API or the Winnr Agent, without risk of breaking the records that keep your mail flowing.

Why We Built This

Winnr handles the mail records on its domains: SPF that covers its sending servers, DKIM keys that match the signing configuration, and MX records that route to your inbound server. Those records are not optional. Get one wrong and inbound stops or 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.
• Cold email teams want a tracking-domain CNAME on each sending domain for their sequencer.
• Engineering teams want A records pointing at servers and AAAA records for IPv6.

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). Because Winnr hosts the zone, a new record is in the zone as soon as you save it. Resolvers that cached an older answer keep it until that answer's TTL runs out.

For tracking domains there is a one-click Quick add tracking CNAME row with shortcuts for track, inst and emailtracking, which cover common sequencers. If your tool uses a different tracking host, add the CNAME by hand.

What Stays Protected

Five kinds of records are off-limits, because changing them would break inbound mail or outbound authentication:

• inbound.<your-domain> A record: points at your inbound mail 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 the SPF policy needs more entries than fit in a single TXT record)

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, so a rejected request leaves your zone untouched. Tracking CNAMEs are not in this list: they are ordinary custom records you add, edit or remove yourself.

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 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 report tool (for example dmarcian, EasyDMARC or 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 it resolves.

To edit or delete a record, hover the row and use the pencil or trash icons. Adding a record with the same name and type as an existing one replaces it.

To make the same change on many domains, select them on the Domains page and use the DNS button in the action bar, or ask the Winnr Agent in the app (up to 50 domains per request, and nothing changes until you click Confirm).

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: 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.

Which Domains Support It

Custom DNS works wherever Winnr hosts the zone:

• Domains bought through Winnr. See cold email domains on Winnr.
• Connected domains on the nameserver method, where you pointed the domain's nameservers at Winnr.
• Connected domains on the Cloudflare-token method. Winnr writes records with your token directly to your own Cloudflare zone.

Domains connected with manual DNS (where you copied the records to your own DNS provider) don't show the DNS Records tab. You already control those zones outside Winnr, so add extra records there.

Related guides: Check every record with our cold email DNS setup checklist, audit your domains with the deliverability audit checklist, see our cold email best practices guide, or learn how BIMI uses DNS to display your logo next to outbound mail.