• CiviCRM is running on crm.example.org
  • Bounce processing is configured to use bounce.example.org
  • Mails are send from example.org, mail.example.org and example.com


If we were to enable DMARC for example.com it would fail the SPF alignment (strict and relaxed) since the domain example.com can't be aligned with bounce.example.org. We would additionally need a bounce processing for bounce.example.org and thus using this return path. However CiviCRM currently only supports one bounce processor. At least that is my understanding of it.

Here is a usefull illustration for this issue: https://help.zoho.com/portal/en/kb/campaigns/deliverability-guide/domain-authentication/articles/when-spf-or-dkim-alignment-fails#SPF_alignment

DKIM Alignment

Adding a DKIM signature per "From Domain" works just fine and it will pass. Either by using a relaxed or strict alignment.
works for: example.org, mail.example.org and example.com

SPF Alignment

The Return-Path Domain needs to align with the organizational domain of the "From Domain" in case relaxed SPF alignment is used.
works for: example.org and mail.example.org
fails for: example.com It will never pass using a strict SPF alignment.


Since the DKIM alignment will work most of the time, the DMARC check would pass. But sometimes mailservers also mess with the mail content and thus make the DKIM alignment fail, resulting in a failed DMARC check and your mail not beeing delivered / ending in spam.
works for: example.org and mail.example.org
may fail for: example.com

Brainstorming Ideas

  1. Extend CiviCRM to use multiple mail accounts for bounce processing and let it chose the matching mail account according to the from domain.
    I have only found https://github.com/JMAConsulting/biz.jmaconsulting.ode that is slightly touching this issue, but does so by preventing from sending with different domains.
  2. Customize the outgoing mailserver to rewrite the return path domain to match the from domain and customize the incoming mailserver to rewrite the modified return path domain back to the original bounce processing domain.
    Can probably be done, but will be quite technical and brittle and we currently don't have control over the mailserver for incoming mails.
  3. Use the CiviCRM multisite feature: It should enable the use of multiple bounce processing accounts: Is it possible to configure CiviMail to send from two different domains?
    The overhead and technical challenges does not seem to be reasonable to me. We only need one instance of CiviCRM.

Is there something that I'm missing or that I have misunderstood? Any extension heading in the right direction?

  • Interesting read, I haven't implemented Strict policy with different sending domains yet! I would assume that an Extension would need to be able to handle multiple Bounce Domains and to create infrastructure for that. E.g. providing a separate settings form, disabling the normal fetch-bounces cronjob and create a custom bounce cron Job. the next step could be some logic to automatically choose a bounce provider based on the sender domain, or maintain a mapping in the Extension settings.
    – Phil_B
    Commented May 24, 2022 at 13:37
  • To my understanding, it does not work with a relaxed policy either. Later this year, we might get in contact with you to create such an extension and / or modify core. Commented Jun 1, 2022 at 10:35
  • That should work, since the return path is always the same. That domain should be used for DKIM signing, and the sender domains should be configured to allow the sending SMTP. We have systems running that use different sender domains, albeit no DMARC.
    – Phil_B
    Commented Jun 3, 2022 at 8:26
  • Yes, it is working perfectly fine for SPF or DKIM alone. But DMARC will additionally enforce an alignment between the sender domain and the return path, respectively DKIM signing domain. Commented Jun 7, 2022 at 7:43

1 Answer 1


I came across this post after noting that Gmail has tightened their policies (now your email has to have an SPF record or a DKIM record to be considered "authenticated"). We still don't need a DMARC record thankfully, but as your question indicates, when we do, many of us wil start having trouble.

In my opinion, the first option seems the most viable. Currently, it seems you can only specify one bounce provider account. I think we would need the following changes:

  • Allow multiple bounce providers
  • Allow option to select default
  • When choosing a bounce provider, first try to match the domain name of the from address strictly, then relaxed (mail.example.com will use example.com), and if still no match, then use the default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.