For each vendor, make either its DKIM signing domain or its SPF return-path domain align with your visible From domain, then verify the actual messages it sends.
Your CRM says SPF passed. Your DMARC report says its messages failed. Both can be correct. SPF may have authenticated a domain owned by the CRM, while the address your customers see in From belongs to you. DMARC needs those identities to align.
This is a common onboarding trap for transactional mail, marketing platforms, help desks, and billing tools. Adding a vendor to your SPF record is not, by itself, proof that the vendor's messages will pass DMARC.
Find the three domains in one real message
Imagine an invoice sent as billing@example.com. The provider uses bounce@mailer.vendor.example as the SMTP MAIL FROM address, and signs with d=vendor.example. SPF and DKIM may both pass for the provider's domains. Neither domain aligns with example.com, so DMARC fails for that visible From address.
The relevant SPF identity is the envelope MAIL FROM domain, often displayed as Return-Path after delivery. The relevant DKIM identity is the validated signature's d= domain. DMARC passes if either authenticated identity aligns with the visible From domain. These rules are defined in RFC 9989, section 4.4.
Path one: sign with your domain
Configure the provider to DKIM-sign as your domain, or as an aligned subdomain where relaxed alignment is in use. For example, a valid signature with d=mail.example.com can align with From: billing@example.comunder relaxed DKIM alignment. With strict adkim=s, the domains must match exactly. Check the provider's domain-verification and selector instructions, then inspect a message sent from the actual workflow.
This is often the sturdier path for forwarded mail: forwarding typically changes the connecting IP and breaks SPF, while an intact DKIM signature can survive. It is not guaranteed; a forwarder or mailing list that changes signed content can also break DKIM. See our forwarding guide for the distinction.
Path two: use an aligned return path
Some providers let you configure a custom MAIL FROM or bounce domain, such as bounce.example.com. If SPF passes for that domain, it can align with From: billing@example.com under relaxed SPF alignment. With strictaspf=s, the domains must be identical, so this subdomain example would not align. The provider may require SPF and MX records on the bounce subdomain, not only an SPF include on example.com.
Amazon SES documents this pattern and its required DNS records in its custom MAIL FROM guide. It also documents a provider-default return path fallback when custom MAIL FROM setup fails. If your service offers a similar fallback, verify what identity appears on a delivered message after a DNS error rather than assuming the custom path stayed active.
- List every visible From domain and subdomain the provider uses, including test and automated workflows.
- Send a real message from each workflow to a mailbox where you can inspect full headers.
- Read the visible From, Return-Path, DKIM d= domain, and Authentication-Results together.
- Confirm an aligned SPF or DKIM pass under your actual aspf and adkim settings.
- Check fresh aggregate reports for that provider after DNS propagation, including failures and traffic volume.
Do not infer alignment from a green vendor dashboard, a published DNS record, or an SPF pass alone. If the provider signs with several DKIM domains, identify which valid signature aligns. If neither path aligns, fix the provider configuration or use a dedicated sending domain you control before moving that traffic to p=reject.
Keep both paths where practical. RFC 9989 recommends using SPF and DKIM, and says domain owners with p=reject must not rely solely on SPF for a DMARC pass. For the day-to-day owner, the operational rule is simpler: record the working identity for every vendor and check it again after a provider or DNS change.
Disclosure: AI tools were used in the process of creating this blog post.