Do I need a separate DMARC record for the sending subdomain?

Not to be compliant. A receiver that finds no record at the subdomain falls back to the organizational domain, so the subdomain inherits the root policy or its sp tag. Publishing one anyway is how you keep a brand new name at p=none with its own reporting address while the root stays enforced, and how you get reports for that name separately.

Does a sending subdomain protect my main domain's reputation?

Partly, and it is worth knowing which part. Gmail's reputation view is per exact signing domain, so the new name accumulates its own record once it is the DKIM d= domain. But Google counts the 5,000-a-day bulk sender threshold by primary domain, and the Compliance status dashboard for a subdomain shows data for the whole primary domain, so the sender requirements still follow you.

Can two platforms share one sending subdomain?

You can publish two DKIM selectors at one name, so it works technically. It also merges the two platforms' sending reputations at that name, which is the thing you created the subdomain to avoid. One platform per name, and a second name for the second platform.

Sending subdomain setup: SPF, DKIM, DMARC, end to end

The call usually starts as a complaint about something else. Say a twelve-person firm sends quotes and invoices out of Gmail and runs one newsletter a month through an email platform. One month the newsletter goes to a list nobody has pruned since 2023, the complaints come in, and two weeks later the quotes start landing in spam. Nothing about the quotes changed. The name that sent the newsletter and the name that sends the quotes are the same name.

Moving the newsletter onto its own name, something like news.example.com, is the right answer. It is also the job we most often find half finished: the platform shows a green check, the From address is still on the root domain, and the separation they thought they bought does not exist. Here is what a sending subdomain separates, what it does not, and the order we publish the records in.

What a sending subdomain separates, and what it does not

Gmail attributes reputation to the name that authenticated the message. Google's Postmaster Tools documentation says the Domain Reputation dashboard only displays messages sent from the exact domain used for DKIM and SPF authentication, and that it reports on DKIM-authenticated senders, falling back to the SPF domain when a sender does not sign. So a new sending name starts building its own record the moment it is the name in the DKIM d= tag and the envelope sender. That is the half you are buying, and it is real.

What you are not buying is an exemption from the bulk sender rules. Google counts the 5,000-messages-a-day threshold by primary domain: its worked example is 2,500 messages to personal Gmail accounts from solarmora.com plus 2,500 from promotions.solarmora.com, which makes you a bulk sender because all 5,000 came from one primary domain. Postmaster Tools follows that logic, and Google says adding a subdomain still shows the whole primary domain in the Compliance status dashboard. Splitting traffic changes how reputation is attributed, not which rulebook you are under.

The third gain is the SPF budget. SPF is evaluated against the name in the envelope sender, and RFC 7208 section 4.6.4 caps the DNS-querying mechanisms at ten per evaluation as a single global limit, returning permerror past it. An include living on the sending name costs the root nothing, which makes delegation cleaner than flattening when the root record is near the ceiling. See the ten lookup limit.

What we check before we create the name

Which platform, and whether it will be the only sender there. One per name, because two platforms signing at one name merges the reputations you paid to separate.
What identity the platform can actually authenticate. Twilio's SendGrid documentation tells you to enter the domain your messages will come from, and states separately that subdomains do not inherit authentication permissions from their parent domain. Read both sentences together: if the From address will live on the subdomain, the subdomain is the identity to authenticate, and a green check on the root proves nothing about it.
The root's SPF lookup count and its DMARC record, including whether that record carries an sp tag, because that is the policy the new name inherits on day one. The mechanics are in our post on subdomain policy and delegation.
Whether the name already exists in DNS. With an address record and no MX, RFC 5321 section 5.1 tells senders to treat that host as an implicit MX at preference 0, so a name you thought only served a landing page is already a mail destination.

The records, in the order that keeps mail flowing

Pick a name that says what it carries: news., mail., send. Keep it off anything serving a website or receiving mail, and decide before you publish, because changing it later means warming a new name from nothing. Then publish in this order. Nothing breaks mid-change, because the name carries no live traffic until you point the platform at it.

1. DKIM at the sending name

This is the record that matters most, because it is the one Gmail attributes reputation to. A verifier takes the s= selector and the d= domain off the signature and queries selector._domainkey.domain, the lookup RFC 6376 defines, so a selector s1 on news.example.com lives at s1._domainkey.news.example.com.

Platforms hand it to you in one of two shapes: a TXT record holding the public key, which you paste and own, or a CNAME pointing at a name the platform controls, so it can rotate the key without touching your zone. The CNAME model is easier until your DNS host refuses underscores in CNAME names. Twilio documents that case and says SendGrid's automated security is then unavailable.

2. The return path

Two models, and the platform picks, not you. SendGrid's automated security mints the sending hostname itself and manages SPF and DKIM through CNAMEs, which is why its records look like a host such as em1234 plus s1._domainkey and s2._domainkey. Amazon SES hands the job back. Its custom MAIL FROM feature replaces the default amazonses.com envelope sender with a name under a domain you own, and that name must sit under the parent domain of a verified identity and must not be a subdomain you send mail from or receive mail on, so an SES setup can end up with two names. There you publish an MX record so bounce and complaint notifications reach you, plus an SPF TXT record, then choose what SES does when that MX is wrong: fall back to the default domain, or reject with a MailFromDomainNotVerified error. The MX target follows a regional pattern and the console prints the exact values.

3. SPF at the sending name, not the root

One TXT record at the name, with the platform's include and nothing else. Two SPF records at one name is a permanent error, not a redundancy. Some DNS panels want the TXT value wrapped in quotation marks and others add them for you, a detail the SES documentation calls out, so copy the convention of the records already there.

4. DMARC at the sending name

A receiver looks for a policy at the From domain and falls back to the organizational domain only when it finds none, the discovery sequence in RFC 7489. That gives you something useful: publish p=none with a rua address at _dmarc.news.example.com while the name is new, and the root keeps the enforcement it already has. Reports from the new name arrive separately, which is how you see what the platform is doing before tightening anything.

s1._domainkey.news.example.com.  CNAME  <value from your platform>
s2._domainkey.news.example.com.  CNAME  <value from your platform>
news.example.com.                TXT    "v=spf1 include:<platform> -all"
bounce.example.com.              MX     10 <feedback host from your platform>
_dmarc.news.example.com.         TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Prove it before the first campaign

Resolve every record from outside your own network first, because Twilio's guidance is to allow up to 48 hours for DNS to validate and an early click on verify tells you nothing.

dig +short TXT s1._domainkey.news.example.com
dig +short TXT news.example.com
dig +short MX  bounce.example.com
dig +short TXT _dmarc.news.example.com

Then send one real message to an address you control and read the headers instead of the dashboard. Three things: an Authentication-Results line showing SPF and DKIM pass, a d= equal to the sending name, and a Return-Path under your own domain rather than the platform's. If any is wrong, the records are published but the platform has not picked them up, which is not a DNS problem. Our guide to reading email headers shows where each sits.

The traps we keep finding

A CNAME that quietly replaces something. Twilio is blunt: if your custom return path CNAME matches an existing DNS CNAME record, the record you add overwrites the existing one. Check the name is free first.
Strict alignment at the root. With aspf=s or adkim=s the names must match exactly and a subdomain sender fails. Google says strict alignment can send mail from associated subdomains to spam or have it rejected, and recommends it only in specific cases, such as mail sent for your domain from a subdomain outside your control.
Leaving the old include at the root. Once the platform sends from the subdomain, its root include is a lookup you pay for and an authorisation you still grant.

Warm the name up, because it starts from nothing

A new sending name has no history anywhere, and a strong root domain does not lend it one. Google's bulk email guidance is to start at a low volume to engaged recipients and increase slowly, suggesting a daily step between 25% and 100%, and noting that the more you send, the more slowly you should increase. Pace counts as much as volume: Google contrasts sending 60 messages as fast as possible then waiting a minute with sending one per second consistently, and recommends the second. On a deferral, its suggested recovery is to wait 15 minutes, then send below the volume that triggered it for a day.

Two numbers to hold onto. Google asks senders to keep the user-reported spam rate below 0.1% and never to let it reach 0.3%, and it defines a new domain as one that has not sent more than 5,000 messages a day to personal Gmail accounts since 1 January 2024, with enforcement for new domains on an accelerated timetable. A subdomain created this week is that definition exactly, which is the argument against moving the whole list across on a Monday. Both figures come from Google's sender guidelines and their FAQ, checked 8 October 2026. Add the new name to Postmaster Tools as you added the primary domain: Google says subdomains of a verified primary need no separate verification.

What we watch for the first month

The sending name's own spam rate and authentication rows, separately from the root.
The subdomain's DMARC aggregate reports, which show every source using that name, not only the one you set up.
Bounces reaching the platform. A silent bounce stream is a list that has stopped being cleaned.

Then raise the subdomain's policy to match the root. Starting at p=none was to see the traffic, not to leave an unenforced name under an enforced domain.

How Guanacos Tech helps

We take this as one scoped piece of work: decide the name, publish the records, prove the first message authenticates as the new identity, warm it on a schedule, and hand back a zone somebody else can read without calling us. Getting it wrong is never dramatic, which is why it drifts for years: mail keeps arriving, slightly worse each quarter. How we work sets out how an engagement runs, and our email deliverability consulting for small business page is where to start. A 30-minute call is enough to say whether your setup separates anything at all.

A sending subdomain for one platform: the records, in the order that keeps mail flowing