Click here to sign up for the Spam Resource newsletter

Run an email discussion list? Here's how to deal with DMARC

Yahoo's recent DMARC policy changes have made it so that Yahoo subscribers will now have trouble participating in old fashioned LISTSERV-style discussion lists. When a Yahoo user posts to your discussion list, very few subscribers will receive that message, because any ISP that respects DMARC policy will bounce that message. (And I believe that at least half of the top ten mailbox providers in the US now respect DMARC policy.)

It can be a very frustrating thing to deal with. I've seen people complaining that "discussion lists worked just fine for the last 30 years, I shouldn't have to change anything!" And suggesting that Yahoo users be immediately expelled from every discussion list, or that those users be forced to change webmail providers. I don't think that's a very good way to handle it. One of the discussion lists I run has enough active users with Yahoo email addresses that I didn't think it was wise to do something that would effectively have me pick a fight with them, since it's not their fault that Yahoo implemented this policy. I don't know that I have the power, or will, to force them to have to migrate from Yahoo to Gmail or (Besides, what if Google or Microsoft implement a similar DMARC policy tomorrow? Then I'd have to start all over again.)

Thus, I decided that the better path was to make modifications to my mailing list manager software to make it "play nice" with Yahoo's DMARC policy. Here's some of what I've done, and related considerations. I'm hoping readers might find my thoughts useful if they decide to make their own modifications.
  • Disable or remove the existing DKIM signature. Your mailing list manager software was probably doing this already, because most lists add a footer, or a subject line tag or otherwise change headers in a way that would cause the existing DKIM signature to fail. Because I'm lazy, I just rewrite the original authentication headers, putting "X-" in front of them but leaving them in the message. They're hidden from the end subscriber by default, harmless, and yet still available for viewing if you need them for troubleshooting purposes.
  • Identify potentially affected messages as they are submitted to the list. Check to see if a message submitted to the list came from a user at a domain with a "p=reject" DMARC policy. Because I'm lazy, I started with a static list of domains I know that are impacted:,, I'll update this soon to do a live DNS check to look at the DMARC policy for the domain used in a submitted message.
  • If a submitted message is from a user at an affected domain, rewrite headers as follows:
    • From address: Was "Al Iverson" <> - should now be "Al Iverson via DISCUSSIONLIST" <>
    • Reply-to address: By default I choose to make this the list posting address. For these submitted messages from affected subscribers, I'm changing it to include both the list posting address and the email address of the original submitter: Reply-to: "DISCUSSIONLIST" <>, "Al Iverson" <> -- Yes, it's OK to have more than one address in the reply-to header, and no, the reply-to header is not affected by a DMARC policy.
    • You could choose to make these header changes to all messages submitted, so that all messages to the list are received with consistently formatted headers. I've chosen not to do this, to minimize header changes to only when they're needed. Time will tell if this was the best choice, I guess.
I am told that for subscribers using Microsoft Exchange, changing these headers could mean that "out of office" auto-replies from those users will now go to the mailing list, instead of previously going to the original submitter of the message. Look here for more information. (Either way, it's a bug, no matter how you slice it.) I suggest having your mailing list manager filter these out, disallowing them from being posted to the list. I'll likely do this as well, but I haven't done so as of yet.

Part of this was original thinking on my part, and part of it was based on feedback from members of a mailing list set up to discuss how best to make DMARC and mailing lists play nice together. Feel free to contact me if you'd like information on how to participate in that discussion.

There's no question that for some folks, it is a big undertaking to have to rewrite parts of their mailing list manager software. And certainly, beyond the ability of some. It can feel very unfair to have to respond quickly and significantly to some new requirement that came out of nowhere and nobody consulted you on. That part, I'm not sure I can help you with. All I can say is, welcome to my world. Working for an ESP, it feels like every day some ISP somewhere imposes some new restriction or requirement, never after consulting me, rarely after consulting anyone at all. I suppose being able to react to these kind of things easily is what will help keep me employed for years to come. I choose to focus on the fix, not to fight to the death over whether or not the change was right or wrong.

April 12, 2014 Update: Yahoo has posted a statement explaining their rationale for this policy change, and they've also posted their suggestions for how senders should deal with this change.

April 13, 2014 Update: has updated their FAQ with regard to mailing list interoperability, including a draft requirements document for MLM Patches to Support Basic DMARC Compliance.


Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.

  1. Thanks for publishing your ideas on this topic. I'm using your idea of dynamically checking the sender's domain name, and this dig statement is doing the job.

    dig +short txt _dmarc.$SENDERDOMAIN | grep -i "p=reject"

    We've had a feature to put the list address in the From header for a while, but the intent was to make it simple to whitelist the sending address for subscribers of the list.

    So we've had to tweak things to apply it to all Yahoo addresses.

    We include the sender's name and email address in the From header, but substitute "at" for "@" so it does not get confused with the list address.

    In addition, we stick the sender's name and email address in the first line of the body of the message, to clarify who sent it.

    If you want to see pictures of this, please see

    mark david mcCreary

  2. I'd like to suggest an Addition to the From-rewriting. Maybe put the original From-Header into a (new) Author-Header?
    Then MUAs could show a seperate Button or so to send a private reply.

  3. Patrick: There is already Sender: for (something like) what you propose. Creating an entirely new header for a marginal purpose is probably not a good idea.

  4. And adding new headers, even if it's the best idea, is going to take time and a lot of effort to convince various MUA and spam filter vendors that they need to provide support for the new header.

    Though it may be more "hack-y," I think it's better to make things work with that's out there today.

Previous Post Next Post