r/DMARC

So I have a few small customers (<10 users) that I manage e-mail for. I use Avanan for mail filtering, and use their DMARC package as well for DMARC monitoring. I guess I'm a bit at a loss of what to do with any failures that are not from legitimate sources. I'm pretty sure the answer is "nothing", especially when the volumes of failure are low (last months success as this particular customer was 99.37%.

It just feels weird to be monitoring something I can't do anything about, but I realize that is likely what it is. For instance the two failures this month were from:

https://preview.redd.it/p6u0z7s24djh1.png?width=282&format=png&auto=webp&s=54d6247ec40a8d2fbb1201bba03dc1d99373cc86

https://preview.redd.it/lbc0pa954djh1.png?width=280&format=png&auto=webp&s=df375ab3cd7bad67e9b7b56af6decfb161bf2637

So....what do I do with that information? I mean I feel n-able/solarwinds should not have their infrastructure being used to send spoofing e-mails. And while this is great to know it is going on, I don't even know WHO it was sent to (besides outlook.com reported it), because nobody sends any RUF reports.

I mean it's good to know it is working I guess. I just hate monitoring something I can't do anything about. Unless I'm missing something. So do I just ignore it and move on? Thanks!

I registered an expired DMARC reporting domain (gca-emailauth[.]org) for $10. It had been published as the aggregate-reporting address in Global Cyber Alliance DMARC training docs going back to a 2019 bootcamp, and at some point it lapsed.

Shortly after registration, aggregate DMARC reports for 86 domains across 20+ organizations started arriving.

56 belonged to The Toro Company (NYSE-listed), including myturf[.]com, their distributor platform, which sits at p=none. The rest - University of Wisconsin–Stevens Point (14 subdomains), the North Carolina School of Science and Mathematics, Ennis ISD (Texas), Great Prairie AEA (an Iowa education agency serving 35,000 students), two county governments, and several commercial domains.

For most of these it was a second rua address sitting behind a working commercial processor (Proofpoint, in Toro's case). Reports still arrived at the primary.

GCA's engineers later traced it to a former partner who'd held the domain and let it lapse - the dependency was never written down.

As of my last sweep, 65 of the 86 still publish the endpoint. We disclosed to everyone whose reports we were receiving; only 21 domains stopped publishing the endpoint, and almost nobody replied.

After 8 months of owning the domain, we coordinated a transfer back to GCA.

Hello! I'm new to DMARC, to the point that I think I know the point of it but haven't actually progressed beyond p=none.

I have already a few months worth of reports, and from what I've been able to get from them, is that about 20% of our mails are failing DMARC, mostly because the receivers are forwarding them and they lose SPF and DKIM. Mostly because of google/outlook it seems.

Is that normal, and something that I can ignore? Normal but something that I need to deal with before changing the policy? Or something unusual?

Also, is there any good app to which I can just load the xml reports and they get me the analysis? I have seem the usual services recommendations but it seems you need to have the dmarc report mails sent to them. I used claude to analyze the reports, and it did a good job of creating a sensible report but I cannot judge how correct it actually is.

Thanks!

Hi everyone,

I need your expertise and take on this.

• Identical Google Workspace IPv6 addresses sent on the same date (2a00:1450:4864:20::132 on August 6)
• one email shows: DKIM and SPF Authentication PASS and the DKIM and SPF Alignment PASS.
• But the other one shows: DKIM and SPF Authentication PASS but the DKIM and SPF Alignment FAIL.
• Both emails are showed delivered.

My conclusion is that this is just a bad reporting. Is this parsing bugs or errors from Microsoft?

But I would love to get your take on this matter.

Last month we posted month two of our monthly measurement of DMARC, MTA-STS, DANE and BIMI across the top million domains. In that thread someone asked a question we didn't have an answer to: how many MX servers refuse all connections that aren't encrypted?

It's a sharper question than it looks. MTA-STS and DANE are both ways for a domain to tell senders "use TLS when you deliver to me." Neither of them says anything about what happens when a sender ignores that. So this month we went and asked the servers directly.

We took all 366,215 unique MX hostnames in the top million, resolved each to an address, connected on port 25, read the EHLO capability list, and then tried to start a mail transaction in the clear.

290,230 gave a conclusive answer. Shares below are of those, not of 366,215:

• Offers STARTTLS, accepts cleartext anyway (opportunistic): 278,502, 96.0%
• Offers no STARTTLS at all: 11,135, 3.8%
• Offers STARTTLS and refuses cleartext: 593, 0.20%

Two in a thousand. Per domain it's thinner: 598 of 620,240 cleanly measured domains, 0.096%, require TLS on every one of their MX hosts.

The cross-tab is the part we think this sub will care about, and the two protocols split. Domains publishing MTA-STS at enforce enforce inbound TLS at 0.82% against a 0.096% baseline, so 8.5x. Domains publishing DANE come in at 0.12%, which is 1.2x, i.e. no signal at all. That fits: MTA-STS is still mostly something an operator switches on deliberately, while DANE is overwhelmingly inherited from a provider default, and a default says nothing about the domain that inherited it.

Either way: 99.18% of the domains publishing an enforce policy will cheerfully accept your plaintext mail. For DANE publishers it's 99.88%.

Two things about who the 598 are. We went looking for an industry pattern and mostly didn't find one, so we're not going to pretend otherwise. What we did find was geography: .de is 4.7x over-represented, .eu 3.7x, .cz 3.5x, and German-speaking Europe overall is 15.4% of the enforcers against 3.8% of mail-eligible domains. The German names skew regulated: comdirect, DZ Bank, the federal debt agency, two hospital groups, a handful of city and regional governments. Our guess is BSI TR-03108 plus GDPR practice in health and finance, but we've measured the clustering, not the cause, so take that as a hypothesis.

The other thing: 71 of the 598 are on AWS SES Mail Manager, and 13 of that product's 14 measured hostnames enforce. That's not 71 security decisions, it's one product default. The customer list gives it away: 22 of the 71 are online casinos and gambling affiliates, 36 more are SEO and content-farm domains (seven of them near-identical .live search-spam sites), and the recognizable names left are Supercell's clashroyale.com and SAP's concursolutions.com.

Meanwhile the providers carrying most of the world's mail enforce essentially nothing: 0 of 116,692 measured Microsoft 365 tenant hostnames, 0 for Google, 0 for Cloudflare, Zoho, Proton, Fastmail and Yandex. Cisco's iphmx is the only one above zero, at 22 of 2,546. Microsoft's 119,676 hostnames collapse onto 130 addresses and exactly one refuses cleartext: not a tenant endpoint and not a consumer frontend, but outlook.com itself. Looks isolated rather than the front of a rollout, since the consumer domains that would flip first all still accept plaintext. That's our September watch item.

On method, since that's usually where these threads go. The probe stops at MAIL FROM with a null sender. Never RCPT, never DATA, so it never delivers mail and never does anything resembling a sender callout. The price of that restraint is that a server enforcing TLS only at a later stage reads as opportunistic to us, so 0.20% is a floor. Unlike a DNS lookup this is answered by a mail server that can decline to talk to you at all, so the 75,985 hostnames we couldn't measure (16,113 with no address to dial, 54,940 that resolved but wouldn't hold an SMTP conversation, 4,932 that rejected us for non-TLS reasons like greylisting or IP reputation) are kept in their own buckets and excluded from the denominator rather than counted as "doesn't require TLS." Folding those in would bias the number in exactly the flattering direction, and the hosts that refuse a prober are never a random sample of the internet.

The rest of this month, briefly: DANE grew 5.18% on a same-domain basis, its fastest reading yet, and 85% of that is Strato switching on TLSA for its entire customer base (995 of its 1,001 domains in our data gained it in one month). Last month was Migadu deleting theirs. Strip both provider events out and organic DANE growth was 0.82% in July and 0.77% in August, which is the most stable number in the whole dataset. Migadu's records never came back.

Happy to get into any of it, especially the classification logic if anyone wants to poke holes in it. And thanks to @slfyst who asked the original question, it turned into the most interesting thing we measured this month.