April 1, 2026 | 9 min read
The DNS Learning Curve Nobody Warns You About
When we launched our first product at Obsidian Clad Labs, we thought the hard part was building the software. Write the code, deploy it, done. What we did not expect was spending an entire Saturday staring at DNS records wondering why our emails were going straight to spam and our API subdomain was returning a 522 error.
DNS is one of those things that every SaaS founder has to deal with, but nobody really explains it in plain English. The documentation assumes you already know what you are doing. Stack Overflow answers are either five years out of date or written for someone running their own mail server. And the registrar dashboards all look different.
So here is the guide we wish someone had handed us on day one. No jargon where it is not needed. Real examples. The actual mistakes we made so you do not have to.
The DNS Records You Actually Need to Know
There are dozens of DNS record types, but as a SaaS founder you will deal with about six of them regularly. Here is what each one does and when you need it.
A Record -- This points your domain to an IP address. When someone types yourapp.com into a browser, the A record tells the internet which server to send them to. If you are hosting on a platform that gives you an IP address (like a VPS or a load balancer), this is what you set up. Example: yourapp.com -> 76.54.32.10.
CNAME Record -- This points one domain to another domain. It is essentially an alias. You use this when your hosting platform gives you a hostname instead of an IP. Most common use: pointing www.yourapp.com to yourapp.com, or pointing your Vercel deployment to your custom domain. Example: www.yourapp.com -> cname.vercel-dns.com.
MX Record -- This tells the internet where to deliver email for your domain. If you are using Google Workspace, the MX records point to Google's mail servers. If you are using any other email provider, they will give you MX records to add. Without these, nobody can email you at contact@yourapp.com.
TXT Record -- This is the Swiss army knife of DNS. TXT records hold text data that other services read for verification and security. The three TXT records you will use most are SPF, DKIM, and DMARC, which we will cover next.
SPF, DKIM, and DMARC: Why Your Emails Go to Spam
This is the part we learned the hard way. We set up our domain, configured email, sent a welcome message to our first user, and it went straight to their spam folder. Turns out, if you do not set up email authentication records, most email providers will treat your messages as suspicious.
SPF (Sender Policy Framework) tells receiving mail servers which servers are allowed to send email on behalf of your domain. It is a TXT record that looks something like: v=spf1 include:_spf.google.com include:sendgrid.net ~all. If you use Google Workspace for email and a service like Resend or SendGrid for transactional emails, both need to be in your SPF record. Miss one and those emails get flagged.
DKIM (DomainKeys Identified Mail) adds a digital signature to your outgoing emails. Your email provider generates a public/private key pair. The public key goes in a TXT record on your domain. When you send an email, the server signs it with the private key, and the receiving server checks it against the public key in your DNS. If they match, the email is legit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do if an email fails both checks. A basic DMARC record looks like: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourapp.com. Start with p=none if you want to monitor without blocking, then move to p=quarantine or p=reject once you are confident your legitimate emails are passing. We started with p=none for two weeks, reviewed the reports, and then switched to p=quarantine. This alone improved our deliverability significantly.
Setting Up Custom Domains for Your API
If you are building a SaaS product with a separate backend, you probably want api.yourapp.com instead of some-random-hash.up.railway.app. It looks more professional, it is easier for your frontend to call, and it means you can switch hosting providers without changing your client code.
The setup depends on your hosting provider, but the pattern is the same everywhere. Your provider gives you a target hostname or IP. You create a CNAME or A record pointing api.yourapp.com to that target. The provider detects the custom domain and provisions an SSL certificate. Most modern platforms like Railway, Render, and Fly handle the SSL part automatically.
One gotcha: if you are using Cloudflare as your DNS provider (which we recommend), make sure the proxy setting is correct. For most backend services, you want the orange cloud on (proxied) for your main domain but you might need it off (DNS only, gray cloud) for your API subdomain, depending on how the backend handles SSL termination. We spent hours debugging a 522 error that turned out to be Cloudflare proxying conflicting with Railway's SSL. Turning off the proxy for the API subdomain fixed it immediately.
Why Cloudflare Should Be Your First Stop
We have tried managing DNS at the registrar level and through Cloudflare. Cloudflare wins and it is not close. The free tier gives you DNS management, automatic SSL certificates, DDoS protection, and a CDN. For a small SaaS team, this is an incredible amount of infrastructure for zero dollars.
The setup is straightforward: you point your domain's nameservers to Cloudflare (they give you two), and then manage all your DNS records through their dashboard. Changes propagate fast, usually within a few minutes. And the dashboard is clean enough that you do not need a networking degree to use it.
One tip: once you move your nameservers to Cloudflare, any DNS records you had at your registrar stop working. So before you switch, screenshot or export everything from your registrar and re-create the records in Cloudflare first. We missed an MX record during migration once and did not realize our email was broken for six hours. Not fun.
SSL and Auto-Renewal: Set It and Forget It
SSL certificates used to be a paid, manual process. You would buy a certificate, install it on your server, and set a calendar reminder to renew it before it expired. If you forgot, your site would show a scary browser warning and your users would think you got hacked.
Those days are over. If you are using Cloudflare, they issue and auto-renew SSL certificates for all your domains. If you are deploying on Vercel, Railway, or similar platforms, they use Let's Encrypt to issue certificates automatically when you add a custom domain. You literally do nothing.
The only time SSL gets complicated is when you are running your own server or using a provider that does not handle it for you. In that case, certbot with Let's Encrypt is your friend. But honestly, in 2026, if your hosting platform does not auto-provision SSL, that is a sign to switch platforms.
The Mistakes That Will Cost You Hours
We have made most of the common DNS mistakes so you do not have to. Here are the ones that hurt the most.
Forgetting SPF records. Your transactional emails (password resets, welcome messages, receipts) go to spam. You do not notice for weeks because you test with your own email and Gmail is forgiving if you are logged into the same Google Workspace account. Your users, however, are on Outlook and Yahoo, and they never see your emails.
Using CNAME at the root. Technically, you should not use a CNAME record for the root domain (yourapp.com without www). Some DNS providers support it through a feature called CNAME flattening (Cloudflare does this), but others will silently break. Use an A record for the root domain or make sure your DNS provider supports flattening.
Not setting up DMARC. Even if your SPF and DKIM are perfect, without DMARC you are leaving the door open for spoofing. Plus, DMARC reports tell you if someone is trying to send email pretending to be your domain. It takes two minutes to set up and there is no reason not to.
Cloudflare proxy conflicts. When Cloudflare proxies your traffic (orange cloud), it terminates SSL at their edge and re-encrypts to your origin. Some backend platforms do not expect this and you get redirect loops or 522 errors. When in doubt, try DNS-only mode for your API subdomain first.
A Practical Checklist for Your Next Launch
Every time we launch a new product, we run through this checklist. It has saved us from repeating the same mistakes.
Register your domain. Move nameservers to Cloudflare. Add an A or CNAME record for the root domain pointing to your frontend host. Add a CNAME for www pointing to the same target. Add a CNAME for api pointing to your backend host. Add MX records for your email provider. Add a TXT record for SPF that includes all your email senders. Add DKIM TXT records from each email provider. Add a DMARC TXT record starting with p=none. Verify SSL is working on all subdomains. Send a test email to mail-tester.com and check your score. Aim for 10 out of 10.
It sounds like a lot, but once you have done it twice it takes about 20 minutes. And it means your users can find your site, your emails land in inboxes, and your API responds on a clean subdomain. That is the baseline. Everything else you build sits on top of this foundation.
Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.
tags: saas, startup, webdev, beginners
Originally published at TeachShield Blog
Built by Obsidian Clad Labs — a group of friends from Tennessee building software that protects people.
Top comments (0)