Publishing a DMARC record takes minutes, but reaching p=reject without blocking your own mail depends on knowing every service that sends as your domain. Aggregate reports arrive as compressed XML from hundreds of receivers, third-party senders appear and disappear, and DKIM keys sit with marketing platforms nobody in security manages. DMARC reporting and enforcement services parse that data, identify senders and guide the move to enforcement. This vendor-neutral guide helps email, security and procurement teams define requirements, compare services and run a proof of concept. It reflects the May 2026 publication of DMARCbis as RFC 9989 and the bulk sender rules at Gmail, Yahoo and Outlook.com. Record syntax and set-up are covered in the DMARC, SPF and DKIM Guide.
Key takeaways
- The standard changed in 2026. RFC 9989 (Standards Track, May 2026) obsoletes RFC 7489 and RFC 9091, removes the pct tag, adds np, t and psd, and replaces Public Suffix List reliance with a DNS tree walk. Reporting moved to RFC 9990 and RFC 9991. Ask every vendor how they support it.
- Mailbox providers now require DMARC from bulk senders. Gmail and Yahoo from February 2024 and Outlook.com from 5 May 2025 expect SPF, DKIM and an aligned DMARC policy of at least p=none above 5,000 messages a day.
- The real work is sender management. A good service turns source IPs into named senders, tracks alignment per sender and shows exactly what will break at quarantine or reject.
- Every third-party sender is a non-human identity. Each holds a DKIM private key or SPF authorisation to speak for your domain, so it needs an owner, a review date and key rotation.
- BIMI is a by-product, not the goal. It needs enforcement first; buy for enforcement and visibility, then add brand indicators.
Define requirements
- Domain estate: count sending, parked and non-sending domains and subdomains. Non-sending domains need p=reject and, under RFC 9989, an np policy for non-existent subdomains.
- Volume: monthly message volume seen in reports drives most pricing. Estimate it from your mail gateway and senders before quoting.
- Bulk sender exposure: any domain that sends more than 5,000 messages a day to Gmail or Outlook.com must meet their requirements. Yahoo also requires one-click unsubscribe (RFC 8058) honoured within two days and a spam rate below 0.3% for bulk senders.
- Target policy and timeline: NCSC advises starting at p=none while SPF and DKIM are built for all senders. Set a date for quarantine and reject per domain.
- Data handling: aggregate reports contain domain-level data, but failure reports (ruf) can contain message headers or content. Decide whether you will receive them and where the data may be stored.
- Operating model: self-service platform, managed service with analysts, or reporting fed into your existing SIEM. See the Email Security Buyer's Guide for gateway and inbound protection.
Capability areas
| Area | What to look for |
|---|---|
| Report ingestion | Receives RFC 9990 aggregate reports (XML, GZIP compressed, email transport) for all domains; publishes the external destination verification record (<domain>._report._dmarc.<vendor-domain> TXT "v=DMARC1") so receivers will send to it |
| Sender identification | Maps source IPs, DKIM d= domains and selectors to named services; flags unknown and spoofing sources separately from misconfigured legitimate ones |
| Alignment analysis | Per-sender SPF and DKIM pass and alignment, relaxed versus strict (aspf, adkim), forwarding and mailing list effects, ARC results (RFC 8617, Experimental) |
| Enforcement guidance | Simulates the impact of quarantine or reject on real traffic; uses the RFC 9989 t=y test flag in place of the removed pct |
| DNS management | Hosted SPF (to stay under the 10 DNS lookup limit), hosted DMARC and DKIM via CNAME delegation, change history and approvals |
| DKIM key lifecycle | Inventory of selectors and key lengths, alerts on keys under 2048 bits or rsa-sha1 (banned by RFC 8301), rotation tracking |
| Failure reports | Optional ruf processing with redaction and retention controls |
| BIMI support | Checks enforcement, SVG Tiny PS logo validity and VMC or CMC certificate status |
| Integrations | API, SIEM export, alerting, ticketing and single sign-on with role-based access |
Third-party senders and DKIM keys
Each marketing platform, ticketing system, payroll provider or CRM that sends as your domain holds a credential to impersonate you. M3AAWG recommends rotating DKIM keys at least every six months, never reusing selector names, keeping the old public key published for 7 to 30 days and then revoking it with an empty p= value. Its preferred pattern for third parties is CNAME delegation of rotating selectors so the sender can rotate without DNS changes each time, and it warns that delegated subdomains let a third party publish a DMARC record that overrides yours. A service should show each sender's selectors, key age and last rotation, and alert when a decommissioned sender is still authorised. See the Third-Party Access Guide and the Email Authentication for Developers Guide.
Evaluation criteria
Weights are illustrative; adjust them to your domain estate and team.
| Criterion | Weight | What good evidence looks like |
|---|---|---|
| Sender identification accuracy | 20% | Correctly names at least the senders you already know, and separates spoofing from misconfiguration |
| Path to enforcement | 20% | Per-domain readiness view and impact simulation before each policy step |
| Standards currency | 15% | Parses RFC 9990 reports, supports np, t and psd, DNS tree walk, and still handles legacy RFC 7489 reports |
| Key and DNS management | 15% | DKIM inventory and rotation tracking, hosted records with audit trail and approvals |
| Data protection | 10% | Data residency, retention, ruf redaction, subprocessors listed |
| Integration and access | 10% | API, SIEM export, SSO, MFA and scoped roles for agencies and business units |
| Commercials | 10% | Pricing by volume or domain with no penalty for adding parked domains |
In framework terms DMARC supports NIST SP 800-53 SI-8 Spam Protection and SC-20 Secure Name/Address Resolution Service for the DNS records, and counters MITRE ATT&CK T1566 Phishing and attacker preparation such as T1584.001 Compromise Infrastructure: Domains.
Questions to ask vendors
- When did you start parsing RFC 9990 reports and the dmarc-2.0 XML namespace, and how do you treat records that still contain pct?
- Show an unknown sender in our data and how you decide whether it is spoofing or a legitimate service we have not configured.
- How do you show which mail will fail if we move to p=reject tomorrow, per sender and per receiver?
- How do you handle forwarding and mailing lists that break SPF and DKIM, including ARC results?
- If you host our SPF, DKIM or DMARC records, what happens to our mail if your DNS is unavailable or we leave? How do we export our records?
- How do you inventory DKIM selectors and alert on stale, short or unrotated keys at third-party senders?
- Where are reports and failure samples stored, for how long, and who in your company can read them?
- How are your portal accounts and API keys protected, and can we restrict who changes DNS-affecting settings?
Red flags
- Dashboards that show pass rates but cannot list senders by name or owner.
- Advice to move to reject without an impact simulation, or to stay at p=none indefinitely.
- Hosted records with no export path, which turns the service into a lock-in point for your mail flow.
- No mention of RFC 9989, or reliance on pct for gradual roll-out in 2026.
- Default ruf collection of message content with no redaction or retention controls.
- BIMI promised before enforcement, or certificates sold as a requirement for DMARC.
Proof of concept
- Choose two sending domains (one with many third-party senders), one parked domain and one subdomain. Add the vendor's rua address alongside any existing one.
- Give the vendor your known sender list and compare it with what the service finds after two weeks of reports.
- Fix one misaligned sender using the vendor's guidance and confirm the change appears in the next daily reports.
- Run an enforcement simulation for quarantine and reject, then apply t=y or p=quarantine on the test subdomain and confirm the predicted impact matches reality.
- Set the parked domain to p=reject with np=reject and confirm spoofed tests are rejected.
- Rotate one third-party DKIM key using CNAME delegation and confirm the audit of d= and s= values the week after.
- Agree go-live metrics: percentage of domains at p=reject, percentage of volume passing aligned DMARC, number of unidentified senders, DKIM keys older than six months, and time to onboard a new sender.
For BIMI after enforcement, the BIMI Group states that p=quarantine or p=reject is needed, that Gmail and Apple require a VMC, and that certificates have a maximum validity of 398 days. Primary sources used here: IETF RFC 9989 DMARC, IETF RFC 9990 DMARC Aggregate Reporting, IETF RFC 8301 DKIM algorithm and key update, M3AAWG DKIM Key Rotation Best Common Practices, Yahoo Sender Best Practices, Google: New Gmail protections for a safer, less spammy inbox, Microsoft Outlook.com postmaster policies, BIMI Group FAQs for senders and NCSC email anti-spoofing guidance.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide · Email Security Buyer's Guide · Email Identity and BEC Guide · Email Security Guide