This release improves the admin tools used to check sender-domain authentication and understand Cloudflare Email Routing delivery logs. It makes DMARC status more explicit, recognises valid inherited DMARC policy records, and ensures any DMARC record NGX creates or repairs includes Brevo aggregate reporting.
Related issue: #238 - Email Routing Log admin UI improvements + publish DMARC record for sender domains
Open Admin > Mail Settings > Senders (/admin/mail-settings?tab=senders) to view the sender-domain authentication panel. This is where SPF and DMARC records are checked and, where safe, repaired.
Open Admin > Committee Settings (/admin/committee-settings), choose a committee member with Cloudflare Email Routing enabled, and expand Email Routing Log to see the delivery-log display changes.
The Senders tab now gives a clearer DMARC result for the configured sender domain:
rua= aggregate-report destination.v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com;.The Create/Update Email Authentication Records action now treats a DMARC record as incomplete if aggregate reporting is missing. When it updates an existing record, it preserves the current policy and other tags, so a record such as p=quarantine; pct=25 is not downgraded to monitoring-only. It simply appends Brevo reporting: rua=mailto:rua@dmarc.brevo.com.
If Cloudflare has multiple SPF records, the repair button remains blocked and the screen still asks an administrator to consolidate SPF manually first. This avoids making an unsafe DNS edit.
The committee member Email Routing Log now labels date columns as Date/Time (UK) and displays values in UK local time with the applicable timezone, for example GMT or GMT+1. This makes log entries easier to compare with admin activity and received-message times.
The log table spacing has also been adjusted so Status, SPF, DKIM and DMARC badges line up more consistently and error details have more room.
When every displayed message has the same authentication summary, Delivered - SPF and DKIM passed but no DMARC policy on sender domain, NGX now shows that once as a warning above the table instead of repeating it on every row. Mixed logs still show per-row authentication summaries where they differ.
A follow-up database migration reruns the existing email-authentication reconciliation for each environment. On deploy, environments with Cloudflare Email Routing configured will be checked again so existing sender domains can pick up the new Brevo aggregate-reporting requirement.
The migration is idempotent. If SPF is already complete and DMARC already includes aggregate reporting, it logs that no action is needed. If DMARC is inherited from the managed zone and complete, NGX accepts that inherited record. If DMARC exists without aggregate reporting, NGX updates that DMARC record rather than creating a duplicate.
The original issue asked for DMARC publication and a less noisy Email Routing Log. The requirement has been updated to match current DMARC behaviour: a sender subdomain can be covered by an inherited parent-domain policy, and Brevo's current guidance expects aggregate reporting via rua=mailto:rua@dmarc.brevo.com.
/admin/mail-settings?tab=senders.rua=mailto:rua@dmarc.brevo.com./admin/committee-settings, choose a routed committee member, and open Email Routing Log.Administrators can now see exactly whether sender-domain DMARC is absent, incomplete, inherited, or fully configured. NGX repairs missing Brevo aggregate reporting without weakening existing DMARC policy, and the Email Routing Log is easier to read because timestamps are localised and repeated authentication warnings are collapsed.