Adding DNS records to send email is one of those tasks where most developers do exactly what the dashboard tells them without understanding why. That works until it doesn't — and when deliverability breaks, debugging without understanding the underlying mechanisms is genuinely painful.
This post covers the five DNS record types involved in email authentication, what each one actually does, which ones are required, and how to verify your setup is correct.
Why email authentication exists
Email was designed in an era of trust. The original protocols have no mechanism for verifying that the server claiming to send mail from acme.com actually has permission to do so. Anyone can configure a mail server to say it is sending from your domain. This is why spam and phishing exist at industrial scale.
SPF, DKIM, and DMARC are the three authentication layers built on top of the original protocols to address this. Mailbox providers at Google, Microsoft, Apple, and others evaluate all three when deciding whether to deliver your mail, send it to spam, or reject it outright.
SPF: who is allowed to send for your domain
SPF (Sender Policy Framework) is a TXT record on your root domain that lists the IP addresses and services authorized to send email on your behalf. A receiving mail server checks this record when it receives a message claiming to be from your domain.
A minimal SPF record looks like this:
v=spf1 include:amazonses.com ~all
This says: servers listed in Amazon SES's SPF record are authorized to send for this domain. The ~all at the end is a soft fail — messages from unauthorized servers are flagged but not rejected. -all is a hard fail — reject them. ~all is the recommended starting point.
The include: mechanism is how you authorize third-party senders. Every service you send email through needs to be listed. If you use multiple services, you chain them: v=spf1 include:amazonses.com include:sendgrid.net ~all.
SPF has a 10-lookup limit. If your include chain requires more than 10 DNS lookups to resolve, SPF evaluation fails. This is a real problem for organizations using many email services simultaneously.
DKIM: cryptographic signing for your messages
DKIM (DomainKeys Identified Mail) lets the sending server cryptographically sign outgoing messages. The receiving server retrieves your public key from DNS, verifies the signature, and confirms the message was not modified in transit.
The DNS record is a CNAME or TXT record published at a selector subdomain. SES uses three CNAME records, each pointing to SES-managed keys:
selector1._domainkey.acme.com → selector1._domainkey.REGION.dkim.amazonses.com
selector2._domainkey.acme.com → selector2._domainkey.REGION.dkim.amazonses.com
selector3._domainkey.acme.com → selector3._domainkey.REGION.dkim.amazonses.com
All three must be present and resolving correctly. The private key lives in SES; you publish only the public key via CNAME. Key rotation is handled automatically by SES when you use the CNAME delegation approach — no manual intervention required.
DKIM is the most important of the three from a deliverability perspective. Gmail, for example, heavily weights DKIM alignment when scoring inbound mail. It is also the only record required by SendFleet before you can send — without DKIM, your domain identity is not fully verified.
DMARC: policy and reporting
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM and adds two things: a policy telling receivers what to do with mail that fails authentication, and a reporting mechanism that sends you data about what is happening to your email.
The record lives at _dmarc.yourdomain.com and looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@acme.com
The p= field is the policy:
- p=none: do nothing, just send reports. This is monitoring mode - the right place to start.
- p=quarantine: send failing mail to spam
- p=reject: reject failing mail entirely
Start with p=none and review the aggregate reports (rua) for at least a few weeks before moving to quarantine. The reports show you every source sending mail claiming to be from your domain — including misconfigured legitimate senders you might not know about.
MAIL FROM subdomain: proper bounce routing
The MAIL FROM subdomain (also called the envelope from or return path) is a subdomain you configure — typically send.yourdomain.com — that SES uses as the bounce address for your emails.
Two records are required:
An MX record on the subdomain pointing to SES's feedback servers:
send.acme.com MX 10 feedback-smtp.us-east-1.amazonses.com.
And a separate SPF TXT record on the subdomain:
send.acme.com TXT "v=spf1 include:amazonses.com ~all"
Without a custom MAIL FROM, SES uses its own domain as the return path, which can cause SPF alignment failures under DMARC. With a custom MAIL FROM on your subdomain, the return path is under your domain and SPF alignment passes.
Domain ownership TXT record
This is the simplest of the five: a TXT record on your root domain that proves to SES (and through it, to SendFleet) that you control the domain. It looks like this:
_amazonses.acme.com TXT "some-verification-token"
This must be verified before any other verification can proceed.
What is required versus what is recommended
Required to send with SendFleet: domain ownership TXT and all three DKIM CNAMEs.
Strongly recommended: SPF, MAIL FROM subdomain, DMARC in p=none mode.
Without SPF and MAIL FROM, some mailbox providers will mark your mail as suspicious. Without DMARC, you have no visibility into authentication failures and cannot protect your domain from spoofing at the policy level.
SendFleet's domain dashboard shows per-record verification status with individual verify buttons. Use these to confirm propagation - the dashboard checks DNS directly.
Top comments (0)