Domains
DKIM, SPF & DMARC
The three DNS record sets that authenticate your mail so inboxes trust it — and how Deckle verifies each one.
When you add a domain, Deckle creates the SES identity and shows you the exact DNS records to publish at your provider. Three families of records do the work: DKIM proves the message wasn’t tampered with, SPF authorizes the sending host, and DMARC tells inboxes what to do when a check fails. Once they resolve, your mail authenticates cleanly and you can send from your own domain.
Why three records#
Mailbox providers won’t take your word that a message came from you — they check the DNS on your domain. Each record answers a different question, and Gmail’s and Yahoo’s bulk-sender rules expect all three to line up.
Because Deckle uses Model A, you send from a domain you own and verify, so authentication builds your reputation rather than a shared pool’s. That makes these records the foundation of your deliverability. Add them once in your DNS provider and Deckle keeps them under watch.
Where these come from
You don’t hand-craft any of this. In the dashboard, open Domains, add your domain, and Deckle generates the exact host and value for every record. This page explains what each one is for.DKIM#
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message so the receiving inbox can confirm it really came from your domain and wasn’t altered in transit. Deckle provisions the keys through AWS SES, so you publish three CNAME records that point at SES-hosted values.
Each record lives at a host of the form <token>._domainkey.<domain>, where the tokens are generated for your identity:
; DKIM — three CNAME records (values shown in the dashboard)
abc123._domainkey.acme.com. CNAME abc123.dkim.amazonses.com.
def456._domainkey.acme.com. CNAME def456.dkim.amazonses.com.
ghi789._domainkey.acme.com. CNAME ghi789.dkim.amazonses.com.DKIM is SES-attested and gates sending: until AWS confirms all three CNAMEs resolve, the domain stays unverified and you can’t send from it. Verification auto-polls, and you can trigger a one-click recheck from the domain page.
Don't flatten the CNAMEs
Some DNS providers try to be helpful by resolving a CNAME to its target and storing an A record instead. DKIM breaks if that happens — the host must remain a real CNAME pointing at the*.dkim.amazonses.com value.SPF#
SPF (Sender Policy Framework) lists which servers are allowed to send mail for your domain. Publish a single TXT record at the root host @ that authorizes Amazon SES:
; SPF — TXT at the root of the domain
acme.com. TXT "v=spf1 include:amazonses.com ~all"The ~all at the end is a soft-fail: unlisted senders are flagged rather than hard-rejected, which is the right default while you roll out. Keep one SPF record per domain — if you already have a v=spf1 record, merge include:amazonses.com into it rather than adding a second.
Custom MAIL FROM#
If you configure a custom MAIL FROM subdomain (recommended so the bounce/return-path domain aligns with yours), Deckle shows two more records at mail.<domain>: an MX record so SES can receive bounces, and its own SPF TXT.
; Custom MAIL FROM — records at mail.<domain>
mail.acme.com. MX 10 feedback-smtp.us-east-1.amazonses.com.
mail.acme.com. TXT "v=spf1 include:amazonses.com ~all"DMARC#
DMARC (Domain-based Message Authentication, Reporting & Conformance) ties DKIM and SPF together: it tells inboxes what to do with mail that fails those checks, and where to send aggregate reports. Publish a TXT record at _dmarc.<domain> whose value starts with v=DMARC1.
; DMARC — TXT at _dmarc.<domain>
_dmarc.acme.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@acme.com"Start with p=none. That’s a monitor-only policy — nothing gets blocked while you confirm your legitimate mail is authenticating. Once the aggregate reports look clean, you can tighten to p=quarantine and eventually p=reject.
A DMARC record is required for bulk senders
Gmail and Yahoo require at least ap=none DMARC policy to send bulk mail. Adding it early costs nothing and unlocks the stricter policies later.Record summary#
Here’s every record at a glance. The exact hosts and values for your domain appear on its page in the dashboard.
| Record | Host | Type | Purpose |
|---|---|---|---|
| DKIM (×3) | <token>._domainkey.<domain> | CNAME | Signs mail; SES-attested and gates sending. |
| SPF | @ (root) | TXT | Authorizes SES: v=spf1 include:amazonses.com ~all. |
| MAIL FROM MX | mail.<domain> | MX | Receives bounces for the custom return-path (optional). |
| MAIL FROM SPF | mail.<domain> | TXT | Authorizes SES for the MAIL FROM subdomain (optional). |
| DMARC | _dmarc.<domain> | TXT | Policy for failed checks; start with p=none. |
How verification works
DKIM is confirmed by SES and gates whether the domain can send. SPF and DMARC are verified by real DNS lookups and shown per-record on the domain page, so you can see exactly which one is still propagating. DNS changes can take up to a few hours to appear.