[{"data":1,"prerenderedAt":551},["ShallowReactive",2],{"\u002Fblog\u002Femail-on-subdomain":3,"\u002Fblog\u002Femail-on-subdomain-surround":540},{"id":4,"title":5,"authors":6,"badge":12,"body":14,"date":528,"description":529,"extension":530,"image":531,"meta":533,"navigation":534,"path":535,"seo":536,"stem":537,"updatedAt":538,"__hash__":539},"posts\u002Fblog\u002Femail-on-subdomain.md","Email on a Subdomain: Subdomain Email Without Moving Gmail",[7],{"name":8,"to":9,"avatar":10},"Rares Serban","\u002Fabout",{"src":11},"\u002Fimages\u002Frares-serban.jpg",{"label":13},"Guide",{"type":15,"value":16,"toc":510},"minimark",[17,34,37,42,61,71,75,91,94,104,111,114,121,125,131,197,213,232,236,248,269,280,284,294,314,342,355,384,388,419,423,433,436,440,446,458,462,467,473,477,480,484,496,500],[18,19,20,21,25,26,29,30,33],"p",{},"Yes, you can run email on a subdomain. MX records are looked up per hostname, so an MX record for the subdomain sends mail for ",[22,23,24],"code",{},"updates.yourdomain.com"," somewhere new while ",[22,27,28],{},"you@yourdomain.com"," keeps the MX it has today. Subdomain email is how you add a hello@ address, or an address for your app's email, without touching the inbox that already works. The trade-off is worth saying first: the address becomes ",[22,31,32],{},"hello@updates.yourdomain.com",", and that longer name is what your customers will see and type.",[18,35,36],{},"I run this setup on my own company domain, so below are the real records, how DMARC treats the subdomain, and the DNS conflict that catches most people.",[38,39,41],"h2",{"id":40},"how-email-on-a-subdomain-works","How email on a subdomain works",[18,43,44,45,47,48,50,51,54,55,60],{},"When someone sends to ",[22,46,32],{},", their mail server asks DNS for the MX records of ",[22,49,24],{},". It never looks at the MX records of ",[22,52,53],{},"yourdomain.com",". Every hostname gets its own answer, and that's the whole trick: Gmail or Google Workspace keeps the apex MX, and the subdomain points wherever you want. If your app sends with Resend from a subdomain, that's also where its replies go (",[56,57,59],"a",{"href":58},"\u002Fblog\u002Fwhere-do-resend-replies-go","where Resend replies go",").",[18,62,63,64,70],{},"One detail from the spec is worth knowing. If a hostname has no MX at all, the sending server falls back to its A or AAAA record and tries to deliver there (",[56,65,69],{"href":66,"rel":67},"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc5321.html#section-5.1",[68],"nofollow","RFC 5321, section 5.1",", the \"implicit MX\" rule). So a subdomain that only hosts a website can still get delivery attempts aimed at your web server. Once you add a real MX, mail goes to the MX and the A record is left alone.",[38,72,74],{"id":73},"what-we-run-on-beyondfoldercom","What we run on beyondfolder.com",[18,76,77,78,81,82,86,87,90],{},"My company domain, ",[22,79,80],{},"beyondfolder.com",", receives mail through Cloudflare Email Routing, which forwards it to an inbox I already read. Email Routing only receives, so on its own it can't send a reply as the domain (",[56,83,85],{"href":84},"\u002Fblog\u002Fcloudflare-email-routing-reply","I covered why, and the fixes, here","). I didn't want to touch that MX, so I connected ",[22,88,89],{},"updates.beyondfolder.com"," to Mailyond instead. Both run side by side.",[18,92,93],{},"This is what DNS returned for both, queried over DNS over HTTPS (Cloudflare's 1.1.1.1) on 2026-10-16, with the DMARC report address redacted:",[95,96,101],"pre",{"className":97,"code":99,"language":100},[98],"language-text","beyondfolder.com.                    300 IN MX 3 route1.mx.cloudflare.net.\nbeyondfolder.com.                    300 IN MX 72 route2.mx.cloudflare.net.\nbeyondfolder.com.                    300 IN MX 93 route3.mx.cloudflare.net.\nupdates.beyondfolder.com.            300 IN MX 10 inbound.postmarkapp.com.\npm-bounces.updates.beyondfolder.com. 300 IN CNAME pm.mtasv.net.\n_dmarc.beyondfolder.com.             300 IN TXT \"v=DMARC1; p=none; rua=mailto:[redacted]@dmarc-reports.cloudflare.net\"\n\n_dmarc.updates.beyondfolder.com: no record\n","text",[22,102,99],{"__ignoreMap":103},"",[18,105,106,107,110],{},"The apex has its three Cloudflare MX records. The subdomain has its own MX pointing at Postmark (which delivers Mailyond's mail) and a Return-Path CNAME. Neither set of records knows the other exists. There's no DMARC record at ",[22,108,109],{},"_dmarc.updates.beyondfolder.com",", so the subdomain falls back to the apex record, which matters more than it looks (more on that below).",[18,112,113],{},"These are our live records for updates.beyondfolder.com:",[18,115,116],{},[117,118],"img",{"alt":119,"src":120},"Mailyond Configure DNS screen for updates.beyondfolder.com showing verified DKIM TXT, bounce CNAME and MX records","\u002Fimages\u002Femail-on-subdomain.png",[38,122,124],{"id":123},"the-three-records-for-subdomain-email","The three records for subdomain email",[18,126,127,128,130],{},"Connecting ",[22,129,24],{}," to Mailyond means adding three records. The dashboard shows the exact values for your domain, but they always have this shape:",[132,133,134,150],"table",{},[135,136,137],"thead",{},[138,139,140,144,147],"tr",{},[141,142,143],"th",{},"Type",[141,145,146],{},"Name",[141,148,149],{},"Value",[151,152,153,167,182],"tbody",{},[138,154,155,159,164],{},[156,157,158],"td",{},"TXT",[156,160,161],{},[22,162,163],{},"\u003Cselector>pm._domainkey.updates.yourdomain.com",[156,165,166],{},"your DKIM public key",[138,168,169,172,177],{},[156,170,171],{},"CNAME",[156,173,174],{},[22,175,176],{},"pm-bounces.updates.yourdomain.com",[156,178,179],{},[22,180,181],{},"pm.mtasv.net",[138,183,184,187,191],{},[156,185,186],{},"MX",[156,188,189],{},[22,190,24],{},[156,192,193,196],{},[22,194,195],{},"inbound.postmarkapp.com",", priority 10",[18,198,199,200,203,204,206,207,212],{},"The TXT record is DKIM, the key receivers use to check your signature. The CNAME is the Return-Path, the bounce address stamped on every message, and ",[22,201,202],{},"pm-bounces"," pointing at ",[22,205,181],{}," is Postmark's default (",[56,208,211],{"href":209,"rel":210},"https:\u002F\u002Fpostmarkapp.com\u002Fsupport\u002Farticle\u002F910-adding-a-custom-return-path-domain",[68],"Postmark's Return-Path guide","). The MX is what makes mail to the subdomain arrive.",[18,214,215,216,219,220,223,224,227,228,231],{},"The mistake that's specific to subdomains happens in the Name field. Panels like Cloudflare take the name relative to your zone, so you type ",[22,217,218],{},"updates",", ",[22,221,222],{},"pm-bounces.updates"," and ",[22,225,226],{},"\u003Cselector>pm._domainkey.updates",". If you paste the full name into a panel that appends the zone itself, you get ",[22,229,230],{},"updates.yourdomain.com.yourdomain.com",", and the record looks saved but never verifies. When one of the three stays pending, check that first. In Cloudflare, also leave the CNAME on DNS only (grey cloud).",[38,233,235],{"id":234},"mx-record-for-a-subdomain-the-cname-conflict","MX record for a subdomain: the CNAME conflict",[18,237,238,239,241,242,247],{},"An MX record for a subdomain can't go on a name that already has a CNAME. Say ",[22,240,24],{}," already points at your changelog or status page host with a CNAME. The DNS spec says a CNAME can't share its name with any other data (",[56,243,246],{"href":244,"rel":245},"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc1034.html#section-3.6.2",[68],"RFC 1034, section 3.6.2","), so the MX can't be added at that name while the CNAME is there.",[18,249,250,251,219,254,257,258,261,262,265,266,268],{},"There are two ways out: pick a different label for mail, like ",[22,252,253],{},"mail.",[22,255,256],{},"inbound."," or ",[22,259,260],{},"hello.",", or move the website to another name. The first is nearly always less work. It's also why Mailyond's Add Domain dialog uses ",[22,263,264],{},"inbound.yourdomain.com"," as its subdomain example, since ",[22,267,256],{}," is rarely taken by anything else.",[18,270,271,272,223,274,276,277,279],{},"The other two records live one level deeper (",[22,273,222],{},[22,275,226],{},"), so a CNAME on ",[22,278,218],{}," itself doesn't block them. Only the MX collides.",[38,281,283],{"id":282},"spf-dkim-and-dmarc-on-a-subdomain","SPF, DKIM and DMARC on a subdomain",[18,285,286,287,290,291,293],{},"SPF and DKIM are checked per hostname, so the SPF TXT on your apex does nothing for mail sent as the subdomain. With Mailyond you don't add an SPF record on ",[22,288,289],{},"updates."," at all. Receivers check SPF against the Return-Path host, ",[22,292,176],{},", and that name is a CNAME to Postmark, which publishes the SPF behind it.",[18,295,296,297,300,301,304,305,308,309,313],{},"DKIM signs as ",[22,298,299],{},"d=updates.yourdomain.com",", the same domain as the From address, so it aligns for DMARC even under strict DKIM alignment (",[22,302,303],{},"adkim=s","). SPF alignment is the weaker side. The Return-Path is a deeper subdomain than the From, which passes relaxed alignment and fails strict. If your apex record has ",[22,306,307],{},"aspf=s",", SPF never aligns and DMARC rests on DKIM alone. That's fine while DKIM verifies, but it's good to know before you go debugging a failed report. (Alignment is also what breaks replying as your domain through Gmail Send-as, which I wrote up in ",[56,310,312],{"href":311},"\u002Fblog\u002Freply-to-email-from-custom-domain","how to reply from a custom domain",".)",[18,315,316,317,322,323,326,327,330,331,334,335,338,339,341],{},"DMARC is where subdomains surprise people. The current standard is ",[56,318,321],{"href":319,"rel":320},"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9989.html",[68],"RFC 9989",", which replaced RFC 7489. Section 4.7 defines the record's tags, and section 4.10.1 describes the lookup. The receiver first asks for ",[22,324,325],{},"_dmarc.updates.yourdomain.com",". If nothing is there, it walks up the DNS tree to your organizational domain and uses ",[22,328,329],{},"_dmarc.yourdomain.com",". For a subdomain that exists, the policy then comes from that record's ",[22,332,333],{},"sp="," tag, or from ",[22,336,337],{},"p="," when there is no ",[22,340,333],{},".",[18,343,344,345,348,349,351,352,354],{},"RFC 9989 also makes ",[22,346,347],{},"np="," part of the main DMARC standard (it came over from RFC 9091, which 9989 also replaces). ",[22,350,347],{}," sets the policy for subdomains that don't exist in DNS at all, like a made-up name someone invents to spoof you. Your updates subdomain has an MX, so it exists, and ",[22,353,347],{}," never applies to it.",[18,356,357,358,361,362,364,365,367,368,361,371,373,374,376,377,380,381,383],{},"The practical warning: if your apex is at ",[22,359,360],{},"p=reject"," with no ",[22,363,333],{},", the new subdomain is at reject from its very first message. Get DKIM verified before you send anything from it. For comparison, when I captured the records above on 2026-10-16, ",[22,366,80],{}," was on ",[22,369,370],{},"p=none",[22,372,333],{},", so ",[22,375,89],{}," inherited monitoring only. As of 2026-10-18 the apex is on ",[22,378,379],{},"p=quarantine",", still with no ",[22,382,333],{},", so the subdomain now inherits quarantine, and receivers are asked to treat mail from it that fails DMARC as suspicious, which usually means the spam folder.",[38,385,387],{"id":386},"check-it-in-one-paste","Check it in one paste",[18,389,390,391,395,396,223,398,400,401,403,404,257,406,408,409,411,412,416,417,341],{},"The ",[56,392,394],{"href":393},"\u002Ftools\u002Fdmarc-checker","DMARC checker"," takes up to 10 domains at once, so paste ",[22,397,53],{},[22,399,24],{}," together, one per line. For a subdomain with no record of its own, it tells you it inherits the one at ",[22,402,329],{}," and which tag applies (",[22,405,333],{},[22,407,337],{},"). It also flags ",[22,410,307],{}," on the apex, since that's the setting that takes SPF out of the picture for a Postmark Return-Path. To confirm the subdomain's own MX, paste the same two names into the ",[56,413,415],{"href":414},"\u002Ftools\u002Fmx-record-checker","MX record checker",": the apex should still show your current provider, and the subdomain should show ",[22,418,195],{},[38,420,422],{"id":421},"when-a-subdomain-is-the-wrong-call","When a subdomain is the wrong call",[18,424,425,426,429,430,432],{},"People type ",[22,427,428],{},"hello@yourdomain.com"," from memory. A longer address gets mistyped more, and I think ",[22,431,32],{}," reads a bit less familiar to a customer who's never seen it before.",[18,434,435],{},"If your apex receives no mail today, skip the subdomain and connect the apex directly. You get the short address and there's nothing to protect. A subdomain makes sense when the apex already has a mailbox you don't want to risk, like a Workspace account with years of mail in it, or a forwarding setup you rely on.",[38,437,439],{"id":438},"where-mailyond-fits","Where Mailyond fits",[18,441,442,443,445],{},"A subdomain is the way I'd suggest anyone try Mailyond, because your current inbox doesn't change at all. You connect ",[22,444,24],{}," with one 5-minute DNS setup with 3 records, the apex MX stays exactly where it is, and mail to the subdomain lands in Mailyond. Replies go out from the address the customer wrote to, signed with the subdomain's own DKIM key, and your app can send from the same subdomain through the REST API with an API key. If it doesn't work out, you delete three records and you're back to what you had.",[18,447,448,449,453,454,341],{},"A connected subdomain counts as one domain on your plan. Basic is $10 a month for up to 5 domains and Agency is $40 for up to 30, and the mail you receive counts toward the monthly email allowance along with what you send. If you run a few products, each one can get its own subdomain, and they all end up in ",[56,450,452],{"href":451},"\u002Fblog\u002Fone-inbox-for-multiple-domains","one inbox for every domain",". Basic comes with a 7-day free trial: ",[56,455,457],{"href":456},"\u002Fsignup","connect your first subdomain",[38,459,461],{"id":460},"faq","FAQ",[463,464,466],"h3",{"id":465},"can-a-subdomain-have-its-own-mx-record","Can a subdomain have its own MX record?",[18,468,469,470,472],{},"Yes. MX records belong to a hostname, so ",[22,471,24],{}," can have its own MX whatever the apex uses. The one thing that blocks it is an existing CNAME on the same name.",[463,474,476],{"id":475},"does-email-on-a-subdomain-hurt-deliverability","Does email on a subdomain hurt deliverability?",[18,478,479],{},"Only if the authentication is broken. With DKIM verified and DMARC aligned, mail from the subdomain passes the same checks as mail from the apex. It does start as a name receivers haven't seen before, so the first sends carry less history than an apex you've used for years.",[463,481,483],{"id":482},"do-i-need-a-separate-dmarc-record-for-the-subdomain","Do I need a separate DMARC record for the subdomain?",[18,485,486,487,489,490,492,493,495],{},"No. Without one, receivers use the apex record, its ",[22,488,333],{}," tag if set and ",[22,491,337],{}," otherwise (RFC 9989, section 4.10.1). Add ",[22,494,325],{}," only if you want a different policy or separate reports for the subdomain.",[463,497,499],{"id":498},"will-adding-an-mx-on-a-subdomain-break-my-google-workspace-mail","Will adding an MX on a subdomain break my Google Workspace mail?",[18,501,502,503,505,506,341],{},"No. Workspace's MX records sit on the apex, and the subdomain's MX is a separate name, so ",[22,504,28],{}," keeps arriving in Workspace as before. If you're deciding whether each project needs a Workspace seat at all, I compared ",[56,507,509],{"href":508},"\u002Fblog\u002Fgoogle-workspace-alternative-for-multiple-domains","the options for email across several domains",{"title":103,"searchDepth":511,"depth":511,"links":512},2,[513,514,515,516,517,518,519,520,521],{"id":40,"depth":511,"text":41},{"id":73,"depth":511,"text":74},{"id":123,"depth":511,"text":124},{"id":234,"depth":511,"text":235},{"id":282,"depth":511,"text":283},{"id":386,"depth":511,"text":387},{"id":421,"depth":511,"text":422},{"id":438,"depth":511,"text":439},{"id":460,"depth":511,"text":461,"children":522},[523,525,526,527],{"id":465,"depth":524,"text":466},3,{"id":475,"depth":524,"text":476},{"id":482,"depth":524,"text":483},{"id":498,"depth":524,"text":499},"2026-10-16","Set up email on a subdomain like updates.yourdomain.com while your main inbox stays on Gmail. Subdomain email MX, DKIM and DMARC, tested on a live domain.","md",{"src":532},"https:\u002F\u002Fimages.pexels.com\u002Fphotos\u002F4348401\u002Fpexels-photo-4348401.jpeg?auto=compress&cs=tinysrgb&h=650&w=940",{},true,"\u002Fblog\u002Femail-on-subdomain",{"title":5,"description":529},"blog\u002Femail-on-subdomain","2026-10-18","HDjSw67I-Vn826r-mXXV_Tq_9pX2HZrrwMg_adDdG-o",[541,546],{"title":542,"path":543,"stem":544,"description":545,"children":-1},"Email Hosting for Multiple Domains Without Per-Seat Fees","\u002Fblog\u002Femail-hosting-for-multiple-domains","blog\u002Femail-hosting-for-multiple-domains","Email hosting for multiple domains usually bills per user per domain. Here are the real options, their costs, and how to run every domain from one inbox.",{"title":547,"path":548,"stem":549,"description":550,"children":-1},"Gmail Send As Alternative: What to Use Before January 2027","\u002Fblog\u002Fgmail-send-as-alternative","blog\u002Fgmail-send-as-alternative","Google is removing Gmail Send As for third-party addresses in January 2027. The real Gmail Send As alternatives, what each costs, and what is not changing.",1792503338613]