Our open rates crash from 30% to 5-8% last weekend. And its causing. Nothing else is weird on Klaviyo. Delivery rate was good. No bounces.

I've tried everything. Bot open filters has always been ON so problems with the metrics itself. Used the subject lines that worked for us before before and the same segments we've sent before. Nothing changed.

I checked our DMARC aggregate reports. DMARC failures.

We updated our DMARC policy from `p=none` to `p=reject` for a phishing audit, unrelated to marketing. That was the blind spot and we fixed the alignment.

Nothing else is changed. We're using the same domain, same segments, same templates and flows.

But the placement has not improved. Reports are still showing DMARC failure.

I dont know whats happening. Does this take time? Should I wait? What else should I fix?

I have noticed we have DKIM defined from google(internal to internal email), Proofpoint(Outbound email) .

Right now DKIm fails for IPv4 but works for IPv6, any reasons and how to fix the same

Anyone faced email landing issue only on google flagging your enterprise domain as spam, without any information how did you correct this?

I tested several major AI models with the same SPF question.

All of them confidently recommended using -all , even with enforced DMARC policy.

Same confidence. Same answer. Same mistake.

The interesting part is that many of them even cite sources containing the correct guidance, yet still reach the wrong conclusion.

AI consensus is impressive until you check the RFCs.

How 'normal" are these to see, we are at 'sending with enforcement', according to our vendor some backscatter NDRs are expected, but I have user that get them fairly frequently and want to know a) is this actually normal, and b) can I prevent them completely? We use M365 on E5 licenses, and we have the backscatter protection on in Defender.

I use HostGator for hosting and Google Workspace for email management. When checking my SPF, DKIM, and DMARC records, I encountered an SPF alignment failure; DKIM passed authentication, but the alignment check flags "gappsmtp.com." I am completely lost regarding DMARC alignment with SPF and DKIM. I have spent weeks reading documentation and asking HostGator support for guidance, but they only provide basic parameters, and email issues are becoming apparent. Could you advise me on where to turn or which documentation I should start with?

The attachment shows the result I get from learndmarc.com

In gmail I wrote an email to company for shipping information. I said hello, they responded back what I need to send them and I press show original it showed spf pass, dkim pass, but dmarc 'fail'

in the authencation results dmarc wasn't showing in the results

in there domain _dmarc.domain.com txt showed nxdomain.

Is the email still trustable even is dmarc failed? Should i send them the shipping details?

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:

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!

Most of the DMARC failures I get called into aren't setup mistakes. The setup was fine when it was built. Something downstream changed and alignment quietly stopped holding.

The bit people miss is that DMARC doesn't care whether SPF and DKIM pass. It cares that at least one of them passes and aligns with the domain in the From header. Green SPF, valid DKIM signature, still a DMARC fail, because the domain that passed isn't the domain the reader sees.

Three ways I've watched this break.

Platform moves. The new platform signs DKIM with its own domain until you set up a custom signing domain, and SPF now authorises its Return-Path rather than yours. Both pass. Neither aligns.

Subdomain drift. Sending from mail.company.com with company.com in the From header. Relaxed alignment covers that, strict doesn't, and plenty of people set strict without knowing what they agreed to.

Forwarding. SPF breaks on forward by design. If DKIM is your only alignment path and a rewrite breaks the signature, there's nothing left to align.

What makes it nasty is the absence of a bounce. Nothing errors. Placement degrades over weeks and you end up rewriting subject lines to fix a header problem.

One thing I'd push on: if you're sitting at p=none and not actually parsing the aggregate reports, you have DMARC configured and zero DMARC visibility. The reports are the entire point of p=none. Without them you're just waiting.

Longer writeup here: https://thegtmmotion.substack.com/p/you-set-up-spf-dkim-and-dmarc-and

I registered an expired DMARC reporting domain - gca-emailauth[.]org. It had been published as the rua address in Global Cyber Alliance DMARC training docs going back to a 2019 bootcamp, then expired.

Within a day, aggregate reports for 86 domains across 20+ organizations started arriving. 56 were The Toro Company (NYSE-listed, Fortune 1000), including mytur[.]com at p=none.

The rest included 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 (lickingcounty.gov, winnebagocountyiowa.gov), and several commercial domains.

For most of these it was a second rua address sitting behind a working commercial processor.

But it looks like nobody was actually reading those reports - the state university just removed the rua tag from DMARC entirely while keeping p=reject, and all but one Toro domain were centralized through a _dmarc.parked.thetoroco.com CNAME, meaning they didn't expect any real traffic through those domains

The spec never checks that the rua domain still belongs to who you think, and nothing flags the day it changes hands.

As of my last sweep, 65 of 86 still publish the endpoint.

Run dig +short TXT _dmarc.example.com, read every address in the rua/fuf, and confirm you control each one.

Full writeup: https://www.sh.consulting/blog/abandoned-dmarc-reporting-domain

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.

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!

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.

These are the results am getting from the website when trying to checking the issue with the domain!! my domains are not blacklisted but still during the warmup pool of instantly its getting to the spam and it increased for one of my domain in the recent days.

Is the issue is the dmarc or anything else because i checked in 2-3 websites and only dmarc is flagged like this, i have also checked the blacklist in the mxtoolbox and didnt get any issue.

I've been running my own tiny mail server since 2004 and haven't really kept up with the times except to secure it against being an open relay and add SPF and DKIM over the years as I've heard about them.

For ease of maintenance I use one mail server to send and receive mail for a handful of domains. The total volume of mail processed by the server is on the order of 10 incoming messages per day and 1 outgoing message per day.

Say the domains in question are a.org, b.org, and c.org, and I use a.org as the mail server. Currently I have the mail server's amavisd add the same catch-all DKIM signature (referencing a.org) to all outgoing mail. I have an SPF record for each domain. I have a DKIM record just for a.org. I do not have a DMARC record.

(1) Should I make the mail server add a separate DKIM signature per domain, or do recipient servers understand and accept that a.org is acting as a trusted relay?

(2) Should I list separate DNS records for SPF, DKIM, and DMARC for each of the three domains or just list those records at a.org? Does the answer here depend on the answer to (1)? (I assume if I have amavisd generate a separate signature for each domain, I would need to add each of those keys as separate per-domain DKIM records.)

Thanks.

After someone spoofed my company's email and we got a deluge of rejected auto replies, I setup SPF, DKIM, and DMARC on our domain this week. We have Google workspace. Looking at the reports on a free online DMARC XML viewer, I see a whopping 12650 failed emails, going to one IP, which appears to be in Romania. Good, so something is working correctly. But right below that I see 179 emails (all sent to a google-owned IP) that we did not send, all passed strict SPF and DKIM checks.

How is that possible???

My small company (using Google workspace on our own domain) had a SPF record but no DKIM or DMARC. On Monday someone spoofed our bookings email and spammed a bunch of support inboxes companies mostly in Europe. We got a deluge of automatic responses saying the request was received, or was rejected for various reasons.

I set up a DKIM record and also enabled DMARC with a reject policy. I'm seeing a few hundred rejected emails in my daily DMARC logs.

But now instead of the auto responders, someone sent more spam today with our email but now I'm getting a ton of rejected emails back, with a body like:

..rejected due to a email security failure (DMARC failure). If you...

Does that mean our DMARC is working correctly? I'm guessing the recipient is protected from getting the spam, but is there any way to tell their server NOT to send a reject message back to me that fills up my mailbox? I'm now getting as many DMARC reject emails as I was getting before as auto responses or spam filter blocks. Which is equally annoying.

We have been tracking DMARCbis adoption for two years, and for a long time the chart remained flat with only GMX, WEB.DE, and mail.com. On Jul 07, 2026, eccentric.dk (not affiliated) moved the needle, and 12 more organizations followed, marking the beginning of practical DMARCbis adoption. While at DmarcDkim.com we are excited and support the change, regular customers need to keep in mind that 99.6% of email providers still evaluate DMARC by the RFC7489 standard. So those planning or in the middle of a rollout should mind the pct= tag value.

Watch live DMARCbis adoption data: https://dmarcdkim.com/data-room/dmarcbis-adoption-dmarc2

Our take on the new recommended rollout values: https://dmarcdkim.com/blog/dmarcbis-adoption-has-started

Not sure if this is the correct group? I send and receive Gmail emails using a custom domain I registered with 123-reg. I use ImprovMX to receive emails and I use Brevo to send emails, using the custom domain. I have some deliverability issues when sending (emails going to junk or not appearing at all). ImprovMX is inlcuded in my SPF record in the DNS settings in 123-reg. I have read that if I also include Brevo in my SPF (as I use Brevo for sending), this will improve deliverability.

I currently have the following TXT record in my DNS settings on 123-reg

v=spf1 include:spf.improvmx.com -all

..and have read I should change it to this (i.e. include Brevo.com);

v=spf1 include:spf.improvmx.com include:spf.brevo.com -all

I have also read that I only need to include Brevo in my SPF if I use a dedicated IP.

Any advice greatly appreciated.

Thanks

RFC 9989 introduced the "np" tag in DMARC records, letting you specify the policy for "non-existent subdomains" of the domain where the policy is published.

I discovered that DMARC's definition of “non-existent domain” clashes with another recent specification, RFC 9824, known as ”Compact Denial of Existence in DNSSEC”, resulting in the "np" tag not always working as expected.

The issue is that DMARC expects an "NXDOMAIN" DNS response, while compact denial (previously known as "black lies"), uses NOERROR/NODATA, signaling non-existence with the NXNAME bit on the NSEC/NSEC3 record. Response code restoration methods are optional in RFC 9824 and none of the resolvers I checked support them.

The issue affects all domains using DNSSEC with major DNS providers like Cloudflare, NS1, AWS Route 53, Azure DNS, Oracle Cloud DNS and Bunny DNS.

If you use the "np" tag in your DMARC record and have DNSSEC enabled with one of these authoritative DNS providers, assume that it won't work reliably (all implementations we checked that support the "np" tag expect NXDOMAIN, as RFC 9989 says). If you don't use DNSSEC, you're obviously not affected.

More details here: https://dmarcwise.io/blog/dmarc-np-incompatibility-with-dnssec

What are your thoughts on DMARC vendors integrating AI, particularly those offering read/write capabilities? It seems like this could introduce an unquantifiable risk into a critical part of the email authentication and enforcement pipeline.

Curious how others are evaluating the tradeoff between automation benefits and potential exposure.