SPF, DKIM and DMARC: email authentication that holds
The large mailbox providers demand authenticated mail, yet your own DMARC has been sitting at p=none for years, and nobody knows which systems send under the company domain. I bring domains to an enforceable policy in a controlled way: first the complete inventory, then tightening in stages, without losing legitimate mail.
- SPF
- DKIM
- DMARC
- p=reject
- DMARC Reports
- Spoofing Protection
- Deliverability
Why this is more than three DNS records
Publishing the records is the quick part. The real work sits in the question of who legitimately sends under the domain: the ERP, the newsletter service, the ticket system, multifunction devices, the external payroll provider. Every forgotten source means lost mail after enforcement. That is why every DMARC project of mine starts with an inventory of the actual sending sources from DMARC reports and mail logs, not with editing the DNS zone.
Services
- Sending source inventoryIdentifying every system that sends under your domains, the forgotten ones included; from reports, logs and tenant evaluations.
- Record designSPF within the lookup limit, DKIM signing per sending source, DMARC with a sensible alignment strategy, subdomains and parked domains included.
- Staged plan to p=rejectTightening via none, quarantine and pct stages, with report evaluation before each step and defined abort criteria.
- The hard casesForwarding, mailing lists, gateways in front of Microsoft 365, ARC sealing: the cases DMARC projects usually fail on.
Real-world examples
- Guide for DNS administrators: MX, SPF, DKIM, DMARC: the common mistakes when publishing the records.
- Mail DNS check: checking SPF, DKIM, DMARC, MTA-STS and DANE for a domain, right in the browser.
- Mail header analyzer: tracing the authentication results and DMARC alignment of a specific message.
