You've connected a sending domain in Customer.io but DMARC still fails, or you're unsure whether the DMARC record goes on the sending subdomain or the root.
Customer.io's setup has one non-obvious step: it needs an MX record on the sending subdomain to create a custom Return-Path, which is what lets SPF align for DMARC (the mail-from subdomain and the header-from parent match under relaxed alignment). Keep alignment relaxed (aspf/adkim = r, the default) — a strict setting would require an identical domain match and make Customer.io mail fail DMARC. And the DMARC record itself belongs on your root domain (_dmarc.root-domain.com), not on the sending subdomain. Source: Customer.io Docs — Domain Authentication · verified 2026-07-18.
aspf=s or adkim=s, which would break Customer.io alignment._dmarc.yourdomain.com, not on the subdomain.No. Adding SPF includes and DKIM records (whether TXT or CNAME) only adds authentication — it never blocks mail. The only step that can affect delivery is tightening your DMARC policy to quarantine or reject, and that comes later, once reports confirm every legitimate sender passes.
Yes. Most platforms handle DKIM (and sometimes SPF) so their mail can pass, but the DMARC record is published on your own domain and controlled by you — it's what tells receivers to act on failures. Providers rarely publish it for you, and you want your own rua= address to see the reports.
Send yourself a test message and check the headers for dkim=pass and dmarc=pass — or run the free check below on your domain to see SPF, DKIM and DMARC state, and which sending services currently align, in one place.