Thanks Todd and Catalin, Based on what I’m seeing, this does not appear to be a DNS propagation issue. We’ve implemented several other DNS records since then, and those changes have propagated normally. External resolvers can also see the CNAME record we added with the correct target value so the record itself is in place and resolving.
However, for some reason the underlying TXT record behind CNAME is not being evaluated. I may need to try publishing a direct DMARC TXT record instead. That wasn’t the original plan since we don’t have direct DNS access, but it might be the only reliable way to ensure proper DMARC evaluation. Domain name: elevatere.agency Best, Alex On Fri, Nov 21, 2025 at 4:54 PM <[email protected]> wrote: > Send mailop mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://list.mailop.org/listinfo/mailop > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mailop digest..." > > > Today's Topics: > > 1. Re: Automatic replies and away message with empty SMTP FROM? > (Microsoft 365) (Viktor Dukhovni) > 2. Re: Anyone else seeing weird connections from Edgwave's > GoSecure, that simply drop off? (Sidsel Jensen) > 3. DMARC p=reject issue for .agency gTLD > (Alex Shakhov | SH Consulting) > 4. Re: DMARC p=reject issue for .agency gTLD (Todd Herr) > 5. Re: DMARC p=reject issue for .agency gTLD (Catalin Cucu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Nov 2025 22:27:04 +1100 > From: Viktor Dukhovni <[email protected]> > To: [email protected] > Subject: Re: [mailop] Automatic replies and away message with empty > SMTP FROM? (Microsoft 365) > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > On Fri, Nov 21, 2025 at 09:23:48AM +0100, Paul Menzel via mailop wrote: > > > While looking more into into unsolicited emails from > > outbound.protection.outlook.com (Microsoft 365(?)), we noticed often > away > > messages are sent with an empty SMTP FROM. Are such messages really > delivery > > status notifications (DSN)? > > https://datatracker.ietf.org/doc/html/rfc3834#section-3.3 > > -- > Viktor. 🇺🇦 Слава Україні! > > > ------------------------------ > > Message: 2 > Date: Fri, 21 Nov 2025 14:11:08 +0100 (CET) > From: Sidsel Jensen <[email protected]> > To: Michael Peddemors via mailop <[email protected]> > Subject: Re: [mailop] Anyone else seeing weird connections from > Edgwave's GoSecure, that simply drop off? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > Hi Michael > > You could test if you are hitting the post-quantum issues of > https://tldr.fail/ > - it looks similar to what you are describing. > > Best, > Sidsel > > > On 11/19/2025 6:50 PM CET Michael Peddemors via mailop < > [email protected]> wrote: > > > > > > Before the boys start digging too deep in this.. they are seeing: > > > > Connection -> port 25 > > EHLO smtp.email-protect.gosecure.net > > StartTLS > > EHLO smtp.email-protect.gosecure.net > > > > .. and then nothing.. simple timeouts... > > > > Thought I would check if this is a known issue.. > > > > Logs show it is always one IP: 208.80.204.62 > > > > -- > > "Catch the Magic of Linux..." > > ------------------------------------------------------------------------ > > Michael Peddemors, President/CEO LinuxMagic Inc. > > Visit us at http://www.linuxmagic.com @linuxmagic > > A Wizard IT Company - For More Info http://www.wizard.ca > > "LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd. > > ------------------------------------------------------------------------ > > 604-682-0300 Beautiful British Columbia, Canada > > _______________________________________________ > > mailop mailing list > > [email protected] > > https://list.mailop.org/listinfo/mailop > > > > ------------------------------ > > Message: 3 > Date: Fri, 21 Nov 2025 14:35:32 +0100 > From: "Alex Shakhov | SH Consulting" <[email protected]> > To: [email protected] > Subject: [mailop] DMARC p=reject issue for .agency gTLD > Message-ID: > <CAABNX-V58+H7NC7QSsJx5F2SQ= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > We are having an issue enforcing DMARC for a domain operating under the > .agency TLD. Our DMARC configuration is centralized through our internal > DNS. We manually assigned an identical CNAME value across multiple domains, > all pointing to the same TXT record. Every domain applied the policy > successfully except the one on .agency. > > At first, we considered DNS propagation delays. However, policies added to > .agency afterward propagated normally with no delays. > > My assumption is that .agency TLD may have restrictions that interfere with > DMARC enforcement at the domain level. > > We don't have data to compare, as this is our first time working with a > .agency domain. > > We submitted a request to Identity Digital (the registry for .agency) a few > days ago but have not yet received a response. > > Has anyone had issues before with .agency TLD from a DMARC enforcement > standpoint? > > Thanks, > Alex > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://list.mailop.org/private/mailop/attachments/20251121/0488ecd1/attachment-0001.htm > > > > ------------------------------ > > Message: 4 > Date: Fri, 21 Nov 2025 10:10:22 -0500 > From: Todd Herr <[email protected]> > To: [email protected] > Subject: Re: [mailop] DMARC p=reject issue for .agency gTLD > Message-ID: > <CAK2M3FBpH1sxi2cG5j+CsyAGX7kQ5-azW=GNYk8WGj= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > On Fri, Nov 21, 2025 at 8:40 AM Alex Shakhov | SH Consulting via mailop < > [email protected]> wrote: > > > We are having an issue enforcing DMARC for a domain operating under the > > .agency TLD. Our DMARC configuration is centralized through our internal > > DNS. We manually assigned an identical CNAME value across multiple > domains, > > all pointing to the same TXT record. Every domain applied the policy > > successfully except the one on .agency. > > > > At first, we considered DNS propagation delays. However, policies added > to > > .agency afterward propagated normally with no delays. > > > > My assumption is that .agency TLD may have restrictions that interfere > > with DMARC enforcement at the domain level. > > > > We don't have data to compare, as this is our first time working with a > > .agency domain. > > > > We submitted a request to Identity Digital (the registry for .agency) a > > few days ago but have not yet received a response. > > > > Has anyone had issues before with .agency TLD from a DMARC enforcement > > standpoint? > > > > > Are you able to share the exact domain name at issue? > > I went looking for oddness in general and thought I'd stumbled across a > wildcard DNS situation: > > $ host -tTXT _dmarc.foo.agency > > _dmarc.foo.agency descriptive text "v=spf1 -all" > > > $ host -tTXT _dmarc.alex.agency > _dmarc.alex.agency descriptive text "v=spf1 -all" > > But it seems that it's not quite a wildcard: > > $ host -tTXT _dmarc.todd.agency > > Host _dmarc.todd.agency not found: 3(NXDOMAIN) > > -- > Todd > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://list.mailop.org/private/mailop/attachments/20251121/01f8990c/attachment-0001.htm > > > > ------------------------------ > > Message: 5 > Date: Fri, 21 Nov 2025 17:46:20 +0200 > From: Catalin Cucu <[email protected]> > To: Todd Herr <[email protected]> > Cc: [email protected] > Subject: Re: [mailop] DMARC p=reject issue for .agency gTLD > Message-ID: > <CAF_ZO9POGV3zsKDE8Viqe2xZDa5jVoxf6W9nN-b6oFJ6Vi= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > We have several customers with .agency domains that have their own DMARC > record, but their DNS is hosted in different places (Route53, Cloudflare, > Godaddy). > > You need to troubleshoot with your DNS host to see why the CNAME record for > _dmarc did not propagate; it shouldn't be a problem with the TLD. > > The wildcard that Todd discovered is affecting all the domains that host > their DNS in Afternic, not just the .agency ones. > > > Catalin > > On Fri, 21 Nov 2025 at 17:15, Todd Herr via mailop <[email protected]> > wrote: > > > On Fri, Nov 21, 2025 at 8:40 AM Alex Shakhov | SH Consulting via mailop < > > [email protected]> wrote: > > > >> We are having an issue enforcing DMARC for a domain operating under the > >> .agency TLD. Our DMARC configuration is centralized through our internal > >> DNS. We manually assigned an identical CNAME value across multiple > domains, > >> all pointing to the same TXT record. Every domain applied the policy > >> successfully except the one on .agency. > >> > >> At first, we considered DNS propagation delays. However, policies added > >> to .agency afterward propagated normally with no delays. > >> > >> My assumption is that .agency TLD may have restrictions that interfere > >> with DMARC enforcement at the domain level. > >> > >> We don't have data to compare, as this is our first time working with a > >> .agency domain. > >> > >> We submitted a request to Identity Digital (the registry for .agency) a > >> few days ago but have not yet received a response. > >> > >> Has anyone had issues before with .agency TLD from a DMARC enforcement > >> standpoint? > >> > >> > > Are you able to share the exact domain name at issue? > > > > I went looking for oddness in general and thought I'd stumbled across a > > wildcard DNS situation: > > > > $ host -tTXT _dmarc.foo.agency > > > > _dmarc.foo.agency descriptive text "v=spf1 -all" > > > > > > $ host -tTXT _dmarc.alex.agency > > _dmarc.alex.agency descriptive text "v=spf1 -all" > > > > But it seems that it's not quite a wildcard: > > > > $ host -tTXT _dmarc.todd.agency > > > > Host _dmarc.todd.agency not found: 3(NXDOMAIN) > > > > -- > > Todd > > > > _______________________________________________ > > mailop mailing list > > [email protected] > > https://list.mailop.org/listinfo/mailop > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://list.mailop.org/private/mailop/attachments/20251121/995493b7/attachment.htm > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mailop mailing list > [email protected] > https://list.mailop.org/listinfo/mailop > > > ------------------------------ > > End of mailop Digest, Vol 64, Issue 33 > ************************************** >
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
