Custom MAIL FROM domain (branded Return-Path)
Pointing the invisible bounce address at a subdomain you own, so SPF aligns with your brand instead of your email provider's domain.
See it
What it is
Out of the box, your provider puts its own domain in the envelope sender: bounces land at something like bounces.mailer.example.net. SPF then authenticates the provider's domain, not yours, so SPF is unaligned for DMARC and your entire policy rests on DKIM alone. A custom MAIL FROM domain moves that invisible bounce address onto a subdomain you own, like bounce.yoursite.com, so SPF passes and aligns.
The record types depend on the provider, so take them from its current docs instead of assuming. Amazon SES has you create the subdomain with an MX record pointing at its regional bounce handler plus a TXT SPF record, because SES has to receive the bounce mail itself. Others delegate the Return-Path with a CNAME: Postmark calls it a Return-Path domain served by a CNAME, and SendGrid and Mailgun fold the same idea into their domain authentication flow. The name differs too (Custom MAIL FROM, Return-Path domain, bounce domain), and the target is usually account-generated. Do it after DKIM and before you move DMARC to p=quarantine or p=reject, so you have two aligned identifiers instead of one.
Two traps. First, on providers that use MX, never point a custom MAIL FROM at your root domain: the MX record there routes your real inbound mail, and you would hand your inbox to your ESP. Use a dedicated subdomain. Second, the payoff is authentication, not vanity. People buy it hoping to kill Gmail's 'via' line, but that annotation depends on the whole authenticated identity Gmail works out for the message, so a branded Return-Path often clears it and sometimes does not. The reliable win is a second aligned identifier, and if DKIM already aligns, your mail was not failing DMARC without it.
Ask AI for it
Set up a branded Return-Path for my domain yoursite.com sending through <provider>. Follow that provider's current custom MAIL FROM or Return-Path procedure and return only the record types it actually requires: do not assume MX plus TXT, since some providers delegate the Return-Path with a CNAME instead. Give me the dedicated subdomain to use (never the root), each required record with its host, type, and value, and the dashboard setting that switches MAIL FROM over. Mark every account-generated target clearly as a value I must copy from the provider's console rather than something you can supply. Then give me a dig command per record and a way to confirm from a received test message that Return-Path is now on my subdomain and SPF is DMARC-aligned.