开云体育

Mark,

Okay with the help of the raw reports and the MxToolbox visualizer, I
have a new insight: SPF and DKIM are _authenticating_ correctly, but
they are not _aligned_ and thus fail DMARC.

Right.

The key purpose of DMARC is to flag "spoofed" messages - ones where the domain of the header From: field does not match the domain of the actual sending server. The intent is to be able to automatically reject those scam emails that claim to be from your bank, USPS, or UPS, or other trusted businesses from which you may expect to receive messages.

Short form:

Don't use DMARC (specifically p=reject) with an email domain from which you intend to use any email list or forwarding service.

Long form:

DMARC does not work well with public mailbox domains (yahoo.com, aol.com, etc.) because mailbox users frequently also use email lists, email groups, and other services which legitimately pass along messages from mailbox users. The decision by Yahoo Mail, and shortly thereafter AOL mail, to implement DMARC p=reject on behalf of their mailbox users was highly controversial at the time, as it broke the delivery from most of the traditional email forwarding services used by those mailbox customers.

Yahoo side-stepped the problem with regard to Yahoo Groups versus Yahoo Mail by including Yahoo Group's outbound servers in the DNS records for Yahoo Mail. But when AOL followed suit with p=reject there was a paroxysm in Yahoo Groups when suddenly messages posted by AOL users were being rejected by users of other email services, causing the /receiving/ members to be put on "bouncing" status. A similar problem happened with more traditional email lists, with many old-school list services automatically unsubscribing the /receiving/ member because they had rejected a list message. Oops. Some email list managers reacted by banning users with AOL and Yahoo mail domains, and ultimately any p=reject domain.

Those who believe that DMARC is a good thing for all email, including mailbox services, claim that email email list and forwarding services should never have been passing the poster's From address through unmodified. They make that claim despite precedent going back as far as internet email has existed.

In response to the AOL debacle Yahoo Groups changed their email handling to rewrite all From addresses so that the outbound header From would now have the yahoogroups.com domain. Thus creating the needed alignment.

Facing the same issue Groups.io rewrites the outbound From header (in a more sensible way), but only when the posting member's domain has a DMARC p=reject policy. Many services do not do that (including Gmail) so you'll see unmodified From addresses from many members (including me).
/helpcenter/faq/1/group-member-faq/q-why-are-some-people-s-email

By the way, some people conflate "spoofed" (aka "forged From") messages with spam messages, but the two ideas are distinct. The confusion comes about because forging a legit header From address is a technique that email viruses, spambots, and all manner of scammers have often used in an attempt to fool people into opening and acting on their messages.

What I don't get is why I suddenly have _thousands_ of emails going
out "from" my domain that would fail: ...
* Perhaps the biggest concern are the 1665 emails purportedly from my
domain sent yesterday from two adjacent IP addresses in Moldava.
That looks like a determined effort to spoof my domain.

That seems likely. The scammers never give up trying.

I don't know if that's related to groups.io, but the timing overlaps.
(Third attachment) Unfortunately, I do not seem to have the raw report
for these failures.

It might be.

Or it might be from any other usage of your domain which might be collected by scammer's bots. Such as having it posted as contact info on a web site.

Shal


--
Help: /helpcenter
More Help: /g/GroupManagersForum/wiki
Even More Help: Search button at the top of Messages list