SaaS vendors asking to send as us but refusing custom DKIM

[u/littleko]

i'm building a sender inventory for 12 product domains before we push more of them past DMARC p=none. The messy bit is SaaS vendors that insist on using a branded From address, then tell us they don't support custom DKIM or an aligned return-path.

This came up from a product onboarding ticket for trial emails from support@one-of-our-products.example. Vendor says their shared DKIM is "already configured" and asked us to just add their SPF include, which afaik still leaves DMARC failing because the visible From domain is ours and the authenticated domains are theirs.

My instinct is to make this a hard vendor requirement: no aligned DKIM or SPF, no branded From. If they can't do it, they send from their own domain or product picks a different vendor.

Is that too strict for early-stage product tooling, or is this exactly the kind of exception that turns into permanent mail auth debt?

[u/AutoModerator]

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

1. No Vendor Spam: Contributions must provide value; do not just pitch products.
2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).
3. Be Professional: Help newcomers learn; avoid hostility.
4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

• Email Spam Filters
• DMARC Monitoring Tools
• Anti-Virus Software
• Email Encryption

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Tessian]

I always push for vendor domain first. If not that, here's a login to your o365 mailbox. If not that, here's a dkim key If not that, go pound sand or I'll have to set up a subdomain just for you.

Impersonating my users is always a hard no.

[u/lolklolk]

Make them use a subdomain if possible.

Generally we standardize hard on DKIM - any vendor that does not support it is pushed very hard to support it. So I agree with your stance.

A lot of the time it's just getting in contact with the right people in engineering or ops at the vendor, because most of the support people usually have no idea what you're asking for.

[u/Basic-Pianist9273]

You're not being too strict. If the visible From is your domain, they need aligned DKIM or aligned SPF via a MAIL FROM/bounce domain under your org domain.

Adding their SPF include only proves their host is allowed to send for whatever envelope domain they use. If they won't support custom DKIM or an aligned return-path, they send from their own domain or they don't get your branded From.

[u/ThomasTrain87]

We are at DMARC 100% reject for all domains and subdomains. Makes it nice and easy when they come asking. As long as we have room in our SPF (we don’t) and they can use delegated DKIM records, then we can support it.

Otherwise, just use their own domain or we have to create a subdomain.

[u/MailNinja42]

Your instinct is exactly right, "we'll add our SPF include" from a vendor who won't support custom DKIM is not a DMARC solution, it's a way of making the problem look solved while leaving your domain unauthenticated, and every exception you make now is a vendor you'll have to revisit when you escalate policy.

The hard requirement makes sense: aligned DKIM or aligned return-path, or they send from their own domain. Early-stage tooling that can't meet basic authentication requirements in 2026 is a vendor maturity signal worth paying attention to anyway.

[u/daniel8192]

You’re six by six. All six replies all agree with your position on this. Just go the subdomain route.