The Three DNS Records That Decide If Your Email Lands

Every business email goes through the same three-question interview before it lands in the recipient’s inbox. Are you allowed to send? Was it really you? What if it fails? The receiving inbox — Gmail, Outlook, Apple Mail — is asking. And it’s not asking the sender. It’s asking the sender’s domain.

If any of those three answers come back wrong, the message goes to spam. Not because the wording was bad. Not because the logo was off-brand. Not because the offer was weak. Because the domain didn’t have the right paperwork on file.

That paperwork lives in three DNS records: SPF, DKIM, and DMARC.

SPF — are you allowed to send?

SPF (Sender Policy Framework, RFC 7208) answers question one: which servers are permitted to send mail on behalf of this domain?

The record is a published allowlist — the email provider (Google Workspace, Microsoft 365), the marketing platform (Mailchimp, Klaviyo), the transactional sender (Resend, Postmark), the CRM, the helpdesk. If a server tries to send mail from a domain whose IP isn’t on that list, the receiving inbox marks it down.

Most small businesses already use four to six different services to send mail without realizing it. SPF has to know about every one of them. Adding a new tool last quarter and never updating SPF is the most common reason a previously-clean domain starts landing in spam.

DKIM — was it really you?

DKIM (DomainKeys Identified Mail, RFC 6376) answers question two: was this message actually signed by the sender, or did somebody spoof it?

Every outgoing email gets a cryptographic signature. The receiver checks the signature against a public key published in the sender’s DNS. Match: the email is authentic. No match: somebody else sent it.

DKIM is what stops a stranger from emailing customers from a lookalike of the company’s own address. Without DKIM, that lookalike attack works.

DMARC — what if it fails?

DMARC (Domain-based Message Authentication, Reporting & Conformance) — specified in RFC 7489 — answers question three: when SPF or DKIM fails, what should the receiver do?

The DMARC record sets a policy — none (just monitor), quarantine (send to spam), or reject (refuse delivery outright). It also tells receivers where to email aggregate reports, so the domain owner can see who’s trying to forge their address.

A domain without DMARC is a domain where forged email gets through. Setting DMARC to none is fine for the first two weeks while reports come in. Leaving it at none forever defeats the point.

Two places, two jobs

The email provider generates the values — the SPF allowlist, the DKIM signing key, the DMARC policy. The DNS host (Cloudflare, GoDaddy, Namecheap, the registrar where the domain actually lives) is where those values get pasted as TXT records. (For specific provider setup, see Google Workspace’s SPF guide or Microsoft 365’s email authentication docs.)

This is where most small businesses get stuck. The IT person sets up Google Workspace, sees a “verified” green check, and walks away. The DNS records still need to be added at the registrar. Until they are, the domain is sending mail without proof of identity.

Five minutes to know — two free tools

Send a test email from the domain to check-auth@verifier.port25.com. A reply comes back within seconds with a full SPF / DKIM / DMARC report for that specific message — pass, fail, or partial. The port25 verifier has been free since 2009 and is still the fastest sanity check on the internet.

If port25 doesn’t reply (some corporate firewalls block it), there are two browser-based fallbacks worth knowing: AboutMy.email and Mail-tester.com. Both run the same SPF / DKIM / DMARC checks against a test send, presented in a web UI instead of an email reply.

If it fails — the usual suspects

Most failures aren’t subtle:

• The SPF record was published once, then a new sending tool got added and SPF was never updated.
• The DKIM record was generated by the email provider but never pasted into the DNS host.
• The DMARC policy is set to none, which technically passes but doesn’t protect anything.

The fix is rarely a code change. It’s usually one TXT record at the DNS host. The hard part is pulling the right values from the email provider and knowing exactly where to paste them at the registrar.

When it’s worth handing off

For most one-domain businesses, fixing all three records is a half-day of focused work — if the email provider’s docs are clear and the DNS host’s interface isn’t fighting back. For multi-domain setups, sending platforms with rotating signing keys, or any company that’s been forwarding mail through three providers since 2017, it’s worth handing off.

Orange County Design runs a flat-fee email-auth audit. The deliverable is the three correct records, configured at the DNS host, with a confirmation report from port25 showing all three pass. No retainer. No surprise charges. Most domains get it done same-day.

Related reading

• Our automation services — when email plumbing is one piece of a larger systems-integration build.
• Our web design services — DNS, including email auth, is part of every site we launch.
• The hour that cleared the backlog — sister piece on the blog; same shape of post (unglamorous infrastructure decides whether the visible thing works) applied to AI-assisted operational leverage.

---

Set in Orange County, CA. Orange County Design builds websites, software, and the systems between them — for businesses that outgrew their last freelancer.