Modern email has three authentication mechanisms, layered on top of one another. Each answers a slightly different question.
§ SPF — who is allowed to send
SPF is a TXT record on the sending domain that lists the IP ranges (or, more commonly, the include: pointers) authorised to emit letters on its behalf. For domains bound to Folio, the correct directive is:
@ IN TXT "v=spf1 include:amazonses.com ~all"The ~all is a soft-fail: non-listed senders are flagged suspicious, not outright rejected. Stricter operators prefer -all; we recommend starting soft and tightening once deliverability is stable.
§ DKIM — signed in whose hand
DKIM signs every outgoing letter with a cryptographic key whose public half is published under em1._domainkey.<your-domain> as a CNAME. The receiving server reassembles the signature and asks: does the letter I'm holding match the hand that signed it? If yes, DKIM passes.
Each domain gets its own 2048-bit key, generated at bind-time. The private half lives encrypted on our side with Fernet; the public half lives at your registrar. We never share keys between domains.
§ DMARC — what to do if neither matches
DMARC is the policy. It tells receivers: if a letter claiming to be from studio.example fails both SPF and DKIM, should you quarantine it, reject it, or do nothing? For a live domain with real reputation at stake, we recommend:
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@emcognito.com"The rua field tells receivers where to send aggregate reports. For domains bound to Folio, those reports go to dmarc@emcognito.com; any external reporting authorization under _report._dmarc.emcognito.com is handled on Folio's side, not in your DNS zone.
§ Bounces and complaints
SES publishes bounce and complaint events to an SNS topic we consume at the edge. A hard bounce (mailbox doesn't exist) is recorded once; a second send to the same address is refused silently. Complaints (reader hit report spam) suppress that address entirely, on every domain bound to your account.