Editing DNS records in Google Cloud DNS

IAM role you need

Your Google account or service account needs DNS Administrator (roles/dns.admin) on the project that owns the managed zone. The narrower roles/dns.readeronly lets you view records - you can't add or edit. If your org limits access, ask the project owner for the admin role on just the relevant zone.

Step 1 - Open the managed zone

1. Sign in to the Google Cloud Console and confirm you're in the project that owns the zone (top bar project picker).
2. Navigate via the left menu: Network services → Cloud DNS. (Or just search "Cloud DNS" in the top-bar search.)
3. On the Zones page, click your zone's name (the row showing your domain).

Step 2 - Add the record set

1. On the Zone details page, click Add standard (the button at the top-right of the record-sets table).
2. Fill the fields per the fix type below. Critical Cloud DNS rule: the DNS name field uses BLANK for apex - NOT the @ symbol. @ would create a literal @.yourdomain.com record, which is wrong.

DMARC

• DNS name: _dmarc
• Resource record type: TXT
• TTL: 5 + unit minutes (or 1 + hours for less frequent rollback). Cloud DNS's minimum TTL is 1 second; 5 minutes is a reasonable default for auth-stack records.
• TXT data: paste the record exactly as trustyourinbox suggested, e.g. v=DMARC1; p=quarantine; pct=100; rua=mailto:<your-rua>@rua.trustyourinbox.com

SPF

• DNS name: leave blank (apex) - the help text says "leave blank for apex," which is the opposite of GoDaddy and Namecheap's @ convention.
• Resource record type: TXT
• TXT data: v=spf1 …mechanisms… ~all
• Critical: only ONE v=spf1 record per apex. If a TXT record set already exists at apex with a v=spf1 entry, click that existing record set → Edit → modify the value - don't create a second.

DKIM (with multi-string for long keys)

• DNS name: the selector + ._domainkey (e.g., google._domainkey, k1._domainkey)
• Resource record type: TXT
• TXT data: RSA-2048 keys are ~390 chars - Cloud DNS lets you enter the entire string in the TXT data field; Cloud DNS auto-segments at 255-byte boundaries internally per RFC 1035 §3.3.14. You don't need to manually split.
• If you DO want to manually split (because you copied the raw multi-string format from another panel), enter each string enclosed in double quotes, separated by a single space, on one line: "part1" "part2".

MTA-STS DNS pointer

• DNS name: _mta-sts
• Resource record type: TXT
• TXT data: v=STSv1; id=<numeric-id>
• The actual policy file is hosted separately at mta-sts.<your-domain>/.well-known/mta-sts.txt over HTTPS - that's a web hosting concern, not Cloud DNS. trustyourinbox can host the policy file for you (separate setup).

Multiple TXT entries on the same name

If you need multiple separate TXT records at the same DNS name (e.g., site verification tokens alongside SPF), click Add itembelow the TXT data field - each item becomes a separate TXT record in the same record set. Don't put multiple records into one TXT data field with newlines; that creates one malformed multi-string record instead of multiple records.

Step 3 - Create

Click Create at the bottom. Cloud DNS propagates to its anycast network within seconds. Receivers honor the TTL on the record they last cached.

Step 4 - Verify the record published

From a terminal:

• DMARC - dig +short TXT _dmarc.yourdomain.com
• SPF - dig +short TXT yourdomain.com | grep spf1
• DKIM - dig +short TXT <selector>._domainkey.yourdomain.com
• MTA-STS pointer - dig +short TXT _mta-sts.yourdomain.com

Or paste the hostname into https://dns.google/query?type=TXT&name=<hostname>for a browser-based check (Google's own DoH endpoint hits the Cloud DNS authoritative servers directly).

Step 5 - Tell trustyourinbox to recheck

Each per-domain protocol tab has a Recheck button. Click it after the Cloud DNS edit propagates; we run a fresh DoH lookup against Cloudflare 1.1.1.1 and Google 8.8.8.8 in parallel and update the dashboard immediately.

Common Cloud DNS pitfalls

1. Using @ for apex instead of blank. The help text under DNS name explicitly says "leave blank for apex." @ creates a literal @.yourdomain.com record. This is the most common Cloud DNS mistake - most other providers accept @.
2. Adding a second SPF record set. RFC 7208 §3.2 violation. Always edit the existing apex TXT record set.
3. Confusing TXT items with TXT strings. The TXT data field accepts ONE record's value (which can have multiple strings via space-separated quotes). The Add item button creates ANOTHER record at the same name. Pick the right one for your case: multi-string single record (DKIM key) or multiple records (SPF + verification token).
4. Forgetting to switch projects.If your zone is in a different GCP project than the one currently selected in the top bar, the Cloud DNS console won't list it. Switch projects via the top-bar picker first.
5. Insufficient IAM permissions. If Add standard is greyed out or the create call fails with 403, your account doesn't have roles/dns.admin on this project. Ask the project owner.

If you get stuck

Open the per-domain page in trustyourinbox, click Recheck, and if the dashboard still shows the issue, paste the dig +short TXT <hostname>output into a support email. We'll narrow down the difference between what we expected and what Cloud DNS published.