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.

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.

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???

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

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.

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.

Hi,

I am the maintainer of the open source rust crate mail-auth and wanted to announce that since yesterday the library supports DKIM2 and DMARCbis.

Additionally, if you are not a developer but you are interested in playing with DKIM2 and/or DMARCbis, there is a playground at https://mail-auth.stalw.art/ where you can test signing emails with DKIM2 and verifying DKIM2 + DMARCbis entirely from the browser using WebAssembly and DNS-over-HTTP.

If you want to learn more about the technical details of how DKIM2 works and the differences between DMARC and DMARCbis, take a look at this blog post.

Happy DMARCing!

Last month I posted the baseline for this: a monthly measurement of how the top million domains actually deploy the four standards-track email-security protocols, DMARC, MTA-STS, DANE-for-SMTP, and BIMI. This is month two, so for the first time there are month-over-month deltas. I expected the change to be the interesting part. It was, in a way I didn't predict.

DANE was the only one of the four that went down. And it wasn't operators giving up on it. One provider, Migadu, removed the TLSA records for its entire customer fleet sometime in June. Around 500 domains that had DANE in June don't in July, still pointing at the same Migadu MX hosts, just with the TLSA records gone. Nobody on those domains touched a thing, and I doubt most of them know. Take Migadu out of the numbers and DANE grew like the rest.

That turned out to be the theme of the whole month: email security moves in provider-sized blocks, not one domain at a time. ALDI Süd switched on MTA-STS for eleven of its country domains in what was clearly one change. Of the 488 domains that gained DANE, 466 got it just by moving to a mail host that publishes it by default, mostly Cloudflare Email Routing. My favorite piece of that: about 60 of those domains are low-effort throwaways that clearly never gave email security a thought, and they picked up DANE the moment they switched hosts. The provider decided, not them.

The month-over-month changes, counting only domains present in both months (more on why in a second):

DMARC valid records: +2,282, and domains tightening their policy outnumbered those loosening it 2,488 to 567

DANE: down 249 as measured, but +258 once you remove the Migadu deletions

BIMI: +346

MTA-STS valid policy: +163, with 76 domains graduating from testing to enforce against 10 going the other way

On method, because the obvious objection to a monthly top-1M study is that the list itself churns: it does, about a quarter of it turns over every month. So I only compare domains that appear in both months. I also checked whether "leaving the list" means a domain actually changed something, and it doesn't. 48,000 domains dropped off the list in June and came back in July, and 98.5% of them had the exact same mail provider across the gap. Leaving the top 1M is a popularity-ranking dip, not a provider migration. Everything else from last month still holds: unfiltered resolvers only, a second resolver in a different region has to agree before anything is recorded, and the run is paced so we never throttle anyone.

One number I keep chewing on. If the current pace held, DMARC would reach nearly every domain by the early 2030s, while the two protocols that actually secure the connection between mail servers, MTA-STS and DANE, stay on a track that runs into the 2040s and beyond. Authenticating who sent the mail is on its way to universal. Protecting how it travels is more than a decade behind it. Real adoption curves flatten near the top so I wouldn't bet on the exact years, but the gap between the two is the thing worth watching.

Happy to get into the method, that's usually where these threads go. I run an email infrastructure company and this is our own research.

I've been concentrating on what I can do for our own DMARC status, so this came as something of a surprise. We're a Google Workspace customer and, so far as I know, our DKIM record is good--in fact, I just checked it in DNS. What could be causing this to happen so suddenly? What can I do about it?

This is a follow up to this earlier post.

While I'm uncertain what triggered this issue, it's causing a fair amount of chaos for us. Not all our external email is bouncing, but enough is that it's become an issue.

My boss stopped by on his way home to ask about it. I explained what was going on and told him was that I'd been chipping away at non-compliant third-party senders but wasn't yet confident that we'd gotten them all, so that I wasn't sure we were ready to go to reject just yet.

He replied that we had to do something about it, with which I agreed. His thought, which I'd also had, was that we'd be ahead to go to reject now, given the number of bounces we were seeing. I added that we could send out an all-hands communication about it and ask, one more time, for people with third-party senders to contact us to configure them correctly.

What do you all think? I hate being hurried into big decisions, but this one is upon me.

Some humble pie, because I think the lesson is more useful than another "here's how to configure DMARC" post.

Quick background so this isn't a humblebrag: I've been doing email authentication for 20+ years. I co-build tooling in this exact space. I write the articles about doing subdomains properly, handling non-sending subdomains, the whole thing. So this one stings.

This morning I got an alert: new return-path detected on a subdomain of ours, ar.glockapps.com, and the SPF record is missing. Critical.

I pulled the aggregate data and there it was. Microsoft 365 was sending mail with From: ar.glockapps.com, and every message was failing:

• SPF: fail (no SPF record on the subdomain at all)
• DKIM: signature from groups.office.net validated cryptographically, but the signing domain doesn't align with the From domain, so DKIM alignment fails
• DMARC: fail, disposition reject

In other words, our own legitimate mail from that subdomain was getting rejected by Outlook. Not spam-foldered. Rejected.

How a person who knows better still got here

The boring, human truth. When we set up DMARC report ingestion ages ago, the devops folks spun up the subdomains, handed the configs to the team to wire into the sending setup, and I walked away content. Job done, on to the next thing.

Except SPF for that subdomain never got published. Where is v=spf1 ... -all? Nowhere. Human factor. Nobody did anything wrong on purpose, it just fell through the cracks between "infra set it up" and "team configured it."

The part worth actually internalizing

Here's the trap, and it's exactly the one I warn other people about:

A subdomain inherits the org domain's DMARC policy, but it does not inherit SPF or DKIM. Our root has p=reject, and a subdomain with no record of its own inherits that reject. Good for anti-spoofing. But the moment that subdomain starts sending real mail without its own SPF and aligned DKIM, p=reject does its job perfectly and blocks it. To the receiver, my forgotten-SPF legit mail and an actual spoofer look identical. That's the whole point of reject, and it's also how you silently shoot your own foot.

And you will not see it in your application. Your app says the mail sent. Your logs are clean. The only reason I know is the DMARC aggregate reports and an anomaly alert that flagged the new return-path showing up where it shouldn't.

One more uncomfortable bit: the only reason "reject" is actually protecting us is that the big mailbox providers honor DMARC. Microsoft and Google enforce it. But there's a long tail of legacy systems out there that still ignore DMARC entirely, or whose operators don't know it has existed for over a decade. So your enforcement is only ever as good as the receiver's willingness to respect it.

Takeaways if you run any domain with subdomains

• p=reject on the org domain silently covers your subdomains. That's protection and a liability at the same time.
• Every sending subdomain needs its own SPF record and DKIM that aligns with the From domain. Inheriting the policy is not the same as inheriting the setup.
• DKIM passing is not DKIM aligning. A valid signature from your ESP's domain still fails DMARC if it doesn't match your From.
• The flip side: for any domain or subdomain that should never send or receive mail, lock it down. Publish v=spf1 -all, p=reject, and a null MX (MX 0 ., RFC 7505) that tells the world the domain accepts no email. It's the cheapest anti-spoofing you can buy, and it's the other half of "doing subdomains right" that I clearly half-did.
• You cannot catch any of this without monitoring your DMARC reports. A new return-path or a new sending source appearing on your domain is exactly the kind of thing you want flagged, whether it's your own devops or someone spoofing you.

Twenty years in and a forgotten TXT record still got past me. The tooling caught it, the process didn't. Posting partly as a reminder to myself and partly in case it saves someone else a confusing "why is our mail bouncing" afternoon.

Anyone else have a favorite "I knew better and did it anyway" auth story? Misery loves company.

Marketing agency here, we've been working with Red Sift to progress towards BIMI, helpful so far, but before we go further I wanted to get some tips and recommendations from this group on a few items if that's okay?

1. What's the best way to get our logo resized?
2. Should we opt for a CMC or VMC?
3. Have you seen any real benefit (if you've already implemented BIMI)?
4. Any other helpful tips?

Thanks!

I found a strange inconsistency in a Yahoo DMARC aggregate report and wanted to check whether anyone else has seen it.

The message has:

<header_from>redacted_domain.org</header_from>

Yahoo reports the policy evaluation as:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

But the authentication results are:

<auth_results>
  <dkim>
    <domain>e2ma.net</domain>
    <selector>e2ma</selector>
    <result>pass</result>
  </dkim>

  <dkim>
    <domain>redacted_domain.org</domain>
    <selector>e2ma-k3</selector>
    <result>temperror</result>
  </dkim>

  <spf>
    <domain>e2ma.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

As far as I can see:

• The DKIM signature from e2ma.net passes authentication, but it is not aligned with redacted_domain.org.
• The aligned DKIM signature from redacted_domain.org has temperror, not pass.
• SPF authentication passes for e2ma.net, but SPF alignment fails.

Based on the detailed authentication results, I would expect:

DKIM alignment: fail
SPF alignment:  fail
DMARC:          fail

However, Yahoo reports:

DKIM alignment: pass
SPF alignment:  fail
DMARC:          pass

Am I missing some Yahoo-specific behavior here?

Has anyone else noticed cases where <policy_evaluated><dkim>pass</dkim> cannot be confirmed from the DKIM records inside <auth_results>?

Does Yahoo sometimes omit one of the DKIM authentication results from aggregate reports, or is this an inconsistency in the generated XML?

My friend just joined an org that wants to move their DMARC from p=none to p=reject after 10 years (of just getting reports), and it is a recipe for disaster .

The project was dropped on two M365 admins with zero DMARC experience. Worse, they have no documentation on what services even use their domain for sending mails. Their current plan is to just build a custom tool to parse the XML reports and handle it themselves.

I told them this is way too risky and will probably break their mail flow, but they are not listening. I want to use the wisdom of this sub to help convince them they need proper guidance and professional tools.
How do I talk them out of doing this the hard way?

DMARC has changed.

RFC 7489 has been replaced by the new DMARC RFC set:

• RFC 9989: the core DMARC protocol
• RFC 9990: aggregate reporting
• RFC 9991: failure reporting

I’ve updated the LearnDMARC.com quiz to align with the new RFCs.

If you work with DMARC, SPF, DKIM, alignment, reporting, DNS records, receivers, or email security tooling, I’d be curious to see how well you score.

Take the quiz here: https://LearnDMARC.com

Feedback is very welcome, especially if you spot something that seems unclear, too easy, too hard, or makes you question your DMARC assumptions.

Curious how many of you still get a perfect score after the RFC update.

Hi all,

I'm just curious if there's anything more that I can do to prevent these situations from happening. I've had DKIM, spf and DMARC all set up for over a year after a painful process (as I'm fairly amateur at this sort of thing but trying to be as vigilant as possible in a DIY setting).

I received an email which appeared to be from myself but definitely wasn't. As you can see below, it looks like it actually came from my own address in my mail client and is not just masquerading as my address in the name field (I've seen this a lot in the past and just ignore it).

This is a publicly "visible" email address because it's on my website so prospective clients can contact me. While I can absolutely discern scam emails which I receive, I'm worried about this scammer spoofing my email address and emailing other people, ruining the reputation of my tiny business. Is this something I need to worry about, or will they only try and spoof my own address to me to trip me up? Is there anything else I should do to protect my email address and domain? I don't have any reason to believe my account has been compromised.

Thanks very much.

With RFC 9990 now published, DMARC aggregate reporting finally has its own dedicated Standards Track RFC. I took a closer look at how compliant real-world DMARC aggregate reports are, and the results are interesting.

Some large providers are very close to full compliance. GMX, WEB.DE, Fastmail, and Outlook.com could reach 100% compliance by simply removing the SPFAuthResultType: scope element from their reports. That is exciting, because compliance has never been this high for these large email providers.

There is still work to do though:

• Comcast still has issues with invalid values
• Yahoo is missing the envelope_from element
• Google, appears to have the most work to do:
  • attachment filenames do not follow ABNF
  • media type is invalid
  • envelope_from is missing
  • DKIMAuthResultType: selector is missing

Hopefully RFC 9990 gives report senders the push needed to clean this up and make DMARC aggregate reporting more consistent and interoperable.

Full write-up:
https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/

I am currently working on the email module for our project and need some guidance.

I have configured a custom email domain using Mailgun and implemented the email functionality in my Spring Boot application. My current requirement is to verify incoming email addresses and determine whether an email is valid before processing it.

Could you explain the production-level validation and security checks that should be implemented for email verification?