Adding a vendor’s include makes their mail pass SPF. It does nothing for alignment, and alignment is what DMARC actually checks. This is the single most common wasted afternoon in an email-authentication project.
Why the include does nothing
From: billing@acme.com
MAIL FROM: bounce-8823@mail.vendor.example
SPF is evaluated against mail.vendor.example — the envelope domain.
The receiver fetches THAT domain's record. Yours is never consulted.
Result: spf=pass for mail.vendor.example
aligned with acme.com? no
DMARC: failYour record only matters when the envelope sender is your domain. Until that changes, you can add or remove includes all day and the DMARC result will not move.
The fix: a custom return-path
Configure the platform to use a subdomain of yours as the envelope sender. Every serious platform supports this, under some name:
| Called | By |
|---|---|
| Custom return-path | Most platforms |
| Custom bounce domain | Several ESPs |
| Custom MAIL FROM | Amazon SES |
| Authenticated domain / sending domain | Others again |
Whatever it is called, it does the same thing: the envelope becomes bounce@mail.acme.com, and a receiver now fetches your record. Under relaxed alignment — the default — mail.acme.com shares an organisational domain with acme.com, so it aligns.
Doing it
- Choose the subdomain deliberately.
mail.acme.com,mkt.acme.com,txn.acme.com— it will appear in bounce addresses and in your reports, so make it describe the traffic. - Publish the records they ask for. Usually a CNAME or MX on that subdomain, plus its own SPF record naming the platform.
- Give the subdomain its own SPF. It does not inherit the parent’s. A missing record here is a
noneand the whole exercise achieves nothing. - Verify from outside. Send one message and read
Return-Pathin the delivered headers. The platform’s UI claiming it is configured is not verification.
# after the change, in a real delivered message
Return-Path: <bounce-8823@mail.acme.com> <- yours now
From: billing@acme.com
Authentication-Results: ... spf=pass smtp.mailfrom=mail.acme.com
dmarc=pass header.from=acme.comDKIM is the better fix where you can have both
A custom return-path aligns SPF, and SPF does not survive forwarding. Getting the platform to sign with d=acme.com aligns DKIM instead, and that survives every intermediary that does not modify the message. Do both where the platform supports both; if you can only have one, take DKIM.
What it costs you
Usually nothing but records and an afternoon. Occasionally a platform charges for it, which is worth knowing before you promise a rollout date — and is a reasonable thing to raise at renewal, since the alternative is the next lesson.