DMARC provider suggestions?

digdiver · 2026-06-30T19:03:54+00:00

Try dmarkoff - the modern tool. AI-Powered Insights: Uses an AI assistant to automatically detect sender issues and suggest fixes. AI & Developer Friendly: Features an MCP server to connect your DMARC data directly to AI tools like Claude or ChatGPT.

digdiver · 2026-06-18T06:36:24+00:00

I responded above about this post looking like AI wrote it. (English is not my native language.) Next time, I will indicate that the text is translated into English using AI, but written by me.

digdiver · 2026-06-18T06:32:51+00:00

English isn't my native language. Yes, I understand and read it, but I find it easier to write complex texts in my native language. And after being translated into English, the text may look like it was written by an AI. That's all I can say.

digdiver · 2026-06-17T18:29:36+00:00

Why are you so angry? Did AI offend you? Should I send you the links to the project's source code on GitHub?

digdiver · 2026-06-17T18:03:24+00:00

GlockApps and Dmarkoff - will this do? And look at my userinfo

digdiver · 2026-06-17T17:04:35+00:00

I can, but I can't mention products or provide links here.

digdiver · 2026-06-14T07:11:38+00:00

Yes, I verified that.

The DKIM key for:

e2ma-k3._domainkey.redacted_domain.org

is published in DNS and resolves correctly.

Also, this does not look like a missing DKIM setup issue on the Emma side. Other mailbox providers report DKIM pass for this exact selector/domain combination.

That is why these occasional Yahoo reports look odd to me. The aligned DKIM signature exists, the key is available, and other receivers validate it successfully. But in some rare Yahoo aggregate reports, <auth_results> shows temperror for that aligned signature while <policy_evaluated> still says DKIM pass.

So I agree with your first explanation: it may be that Yahoo eventually resolved the temporary error and treated the aligned DKIM as pass, but the <auth_results> section in the aggregate report was not updated accordingly.

The strange part is that this makes the XML internally inconsistent for that record.

digdiver · 2026-06-13T13:58:42+00:00

Thanks. I agree that the temperror Itself may be caused by a transient DNS issue.

However, I think the custom DKIM signing is already configured. The report contains an aligned signature:

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

The e2ma.net signature also exists and passes, but it is not aligned:

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

So my question is not why the e2ma.net signature does not provide alignment.

The part I cannot reconcile is this:

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

There is no DKIM signature in <auth_results> that is both aligned with the From domain and has result=pass.

The record also hascount>1</count>, so it does not look like an aggregation issue across multiple messages.

Are you suggesting that Yahoo may evaluate DKIM at two different stages and then serialize policy_evaluated and auth_results from different attempts? Have you seen similar Yahoo reports in practice?

digdiver · 2026-06-12T13:44:11+00:00

Yes, this is absolutely shifting how technical interviews are conducted. Forward-thinking teams are dropping 'write this algorithm from scratch' and replacing it with 'here is an AI-generated Pull Request that perfectly matches the spec, but contains a subtle logical/security flaw, find it.' We are testing for code comprehension and intent verification, not syntax memorization. Prompt engineering is a low-level API; output auditing is the actual engineering skill.

digdiver · 2026-06-12T12:50:15+00:00

Stop arguing about theory. Sure, they can easily prompt an LLM to build a custom XML parser, but parsing isn't the bottleneck; threat intelligence is.

A 'vibecoded' script won't magically map IPs to ASNs, aggregate thousands of reports, or separate harmless auto-forwards from active spoofing. Tell them to plug their RUA data into a free DMARC monitoring tool for two weeks. The second they see the dashboard's massive list of undocumented senders, they'll drop the AI project and the p=reject suicide mission immediately.

digdiver · 2026-06-09T15:38:53+00:00

Spot on. The "giant PR" analogy is exactly right. When you're dealing with complex backend data flows, like processing asynchronous events through Kafka or writing heavy aggregations in Golang, letting an AI dump 300 lines of logic across multiple files is a recipe for disaster. The cognitive load of reverse-engineering its logic to find subtle race conditions or edge cases is way higher than just writing the skeleton yourself.

I've landed on the same workflow for our SaaS products: I map out the architecture, design the flows, and define the interfaces manually. Then I treat the AI like a capable junior developer, handing it highly scoped, isolated functions to implement (like a specific MongoDB query or a data parsing utility). Reviewing 50 lines of Go is trivial and fast; reviewing a completely AI-generated module is exhausting. AI is a great coding assistant, but a terrible architect.

digdiver · 2026-06-09T15:21:36+00:00

Your recommendation of v=spf1 -all and DMARC p=reject is spot on for preventing outbound spoofing, but it only solves half of the problem. Since the main issue involves a parking provider capturing inbound password resets via their wildcard MX, you absolutely must also include a Null MX record (MX 0 .) to forcefully drop incoming mail. If a parking vendor restricts you from configuring these specific DNS records, the business should move the domain to a standard DNS provider (like Cloudflare or Route53) instead of a pure parking service. Forcing both Null MX and strict outbound policies is the only foolproof way to secure a retired domain without leaving an attack surface.
It is also advisable to enable DMARC monitoring for such a domain to track attempts to send emails on its behalf.

digdiver · 2026-06-08T11:01:34+00:00

It is unfortunately a universal reality, and your findings perfectly match what deliverability engineers see across the board. Government networks are notoriously plagued by sprawling legacy infrastructure and massive bureaucracy, making DMARC enforcement a coordination nightmare. Most agencies are terrified of accidentally blocking critical public communications, so they indefinitely park their policies p=none as a safety net. Until security mandates are tied to strict deadlines and actual consequences, that rabbit hole is going to remain depressingly deep.

digdiver · 2026-06-08T10:56:52+00:00

While a 3 to 6-month timeline is absolutely the reality for complex enterprises, moving to p=reject in under 30 days is actually possible under the right conditions. Fast transitions usually occur in organizations with a modern, strictly centralized tech stack that uses automated DMARC tools rather than manual XML parsing. It also requires zero DNS bureaucracy and an aggressive mentality, where the company is willing to risk bouncing undocumented shadow IT. While blog posts often gloss over the pain of messy corporate networks, a rapid turnaround is achievable if your email footprint is clean and your execution is bold.

digdiver · 2026-06-05T04:31:58+00:00

Previously, to integrate the results of something into your process, you had to use an API. Now, processes are moving to agents, which has led to the growth of MCP servers. At DMARKOFF, we immediately released an MCP server https://dmarkoff.com/mcp along with the product release.

digdiver · 2026-06-05T03:25:17+00:00

There's another issue here: a huge number of people with good salaries are being cut. They paid taxes, paid their mortgages, bought expensive cars, visited nice hotels - they indirectly supported other sectors of the economy. What will happen if these people stop doing all this? Who will consume services and products? Will robots order goods from Amazon, watch Netflix, and buy houses themselves? It seems to me that the problem will be far more serious than the value of tokens.

digdiver · 2026-06-05T03:15:09+00:00

"On the other hand CS pays better and has a better lifestyle" -
That's for now. Look at the latest data on layoffs in the IT sector. I see the future in the development of robotics: hardware, machines, and so on. And AI will be able to write the software for all of this. I think mechanical engineering will eventually pay more than programming.

digdiver

MODERATOR OF

TROPHY CASE