DMARC monitoring, end to end
I built and ran the platform behind 2,000+ client domains over its life: architecture, the DNS engine, deployments, monitoring and the enterprise escalations when something broke in production.

Sumit Raj · Email deliverability architect
For three years I built and ran a DMARC monitoring platform across 2,000+ client domains, and the pipeline behind it that analyses around 2 million outbound email records a day from aggregate reports. Those clients were banks, insurers and SaaS companies, and the domains involved were the ones their invoices and password resets go out from.
When a client's mail stopped arriving, the ticket came to me. It was never a dashboard reading amber. It was a finance team whose invoices were being answered by somebody else, a payroll run bouncing at 2am, a marketing domain that had quietly been on the wrong side of Gmail's filters for a month. Every one of those turned out to be four or five characters of DNS.
That is the job. It means records that say what you mean, authentication that survives a forward, and a policy strict enough to stop somebody impersonating you without taking your own mail down with it. Most people can publish an SPF record. Knowing which change breaks payroll on Monday is a different thing, and it comes from having broken it, fixed it and watched the reports afterwards.
I built and ran the platform behind 2,000+ client domains over its life: architecture, the DNS engine, deployments, monitoring and the enterprise escalations when something broke in production.
Around 2 million outbound email records analysed every day from RUA aggregate reports. Batched parsing and queue tuning took 40% off processing time and cleared a bottleneck that had been there for years.
SPF, DKIM, DMARC, MX, CNAME, MTA-STS and TLS-RPT, checked the way a receiving mail server checks them. Plus SPF flattening that brought client records from 15 and 20 lookups back under the limit of 10, published live and re-checked on a schedule.
Record changes surfaced within 60 minutes of publication, on hosted authentication records running at 99% uptime. Most authentication breaks because somebody edited DNS on a Friday and nobody noticed until Monday.
Software Engineer 2 at an email security company.