Guide

The three DNS records that decide whether your email arrives

SPF, DKIM, DMARC and return-path alignment — explained for people who ship apps, not people who run mail servers.

You wire up an email API, send a signup confirmation, and it lands in spam. Nothing in your code is wrong. The problem is that Gmail has no reason to believe the message came from you, and the fix lives in DNS rather than in your application.

Here is the whole mechanism, minus the folklore.

Why receivers are suspicious

SMTP lets anyone claim to be anyone. Nothing in the protocol stops a machine from sending mail that says From: you@yourdomain.com. So inbox providers ignore the claim and ask a different question: can the domain owner prove they authorised this sender? Three records answer it.

SPF — which servers may send

A TXT record listing the servers allowed to send for a domain. The subtlety that catches people: SPF is not checked against the From: address your recipient sees. It's checked against the envelope sender (the return-path), which is a separate address used for bounces. This is why "I added SPF and it still fails" is such a common complaint — the record was added to the wrong domain.

DKIM — a signature that survives the journey

The sending server signs each message with a private key; the public key sits in DNS at <selector>._domainkey.yourdomain.com. The receiver fetches it and verifies the signature. Unlike SPF, DKIM survives forwarding, which makes it the stronger of the two signals. The selector is just a label, so one domain can hold several keys for several senders.

DMARC — the policy that ties them together

DMARC asks for alignment: it isn't enough that SPF or DKIM pass, they must pass for the same domain the recipient sees in the From line. This is the record that closes the loophole where a spammer passes SPF for their own domain while displaying yours. It also tells receivers what to do on failure — p=none (monitor), quarantine, or reject — and where to send reports.

Start at p=none. It changes no delivery behaviour and produces the reports that tell you what would break before you tighten to quarantine or reject.

What this looks like in practice

Send from a subdomain, not your root domain — something like send.yourdomain.com. Two reasons: your normal mailboxes keep working untouched, and marketing reputation stays isolated from the domain your invoices and support replies come from. If a campaign goes badly, it does not poison your corporate mail.

With Charlie the three records look like this:

No SPF record is needed on your side, which surprises people. The bounce. CNAME delegates the return-path to a domain whose SPF the platform maintains — so SPF passes and aligns without you touching it, and there's one less record to get wrong.

Then the boring part that actually matters

Authentication gets you the right to be judged on merit. It doesn't buy you a reputation. A brand-new domain has none, so a first-day blast to 50,000 addresses reads exactly like a compromised account:

• Warm up. Start small, grow daily. Weeks, not hours.
• Send transactional first. Receipts and confirmations get opened and almost never reported — the cheapest reputation you will ever build.
• Honour bounces and complaints immediately. Repeatedly mailing dead addresses is one of the strongest negative signals there is.
• Ship one-click unsubscribe. Since 2024 Gmail and Yahoo require RFC 8058 headers from bulk senders. Without them, placement degrades no matter how clean your DNS is.

Most email platforms leave all four to you. Charlie enforces them: nothing sends from an unauthenticated domain, warmup ramps automatically, suppression is applied on every path, and the one-click headers are injected per recipient. Not because it's generous — because a shared sending fleet only works if nobody on it can be careless.

Debugging, quickly

• Send a message to yourself and read the raw headers: look for dkim=pass, spf=pass and dmarc=pass in Authentication-Results.
• If DKIM fails, check the selector record resolves: dig +short CNAME s1._domainkey.send.yourdomain.com
• If SPF passes but DMARC fails, you have an alignment problem, not an SPF problem — the return-path domain doesn't match the From domain.
• Propagation is minutes to hours. Verify before assuming something is broken.