Why SEG DMARC RUA Reports Fail DKIM (And How to Fix It)

Your secure email gateway (SEG) is dutifully sending you DMARC aggregate reports. But when you check your inbox, they are not there. Or they are there, but marked as spam. Or your email logs show them being rejected outright.

When you look at one of these report emails, you notice something odd: the DKIM check is failing. The report was signed by the SEG's domain, not your domain. This is the core of the problem.

This is one of the most common DMARC operational issues that email administrators hit after deploying an SEG. It is also one of the least clearly explained. Here is what is happening and what to do about it.

Why Your SEG's DMARC Reports Fail DKIM

When you configure your SEG to send DMARC RUA (Reporting URI A) aggregate reports, you give it an email address where those reports should be delivered. The SEG then generates the report and sends it to that address on a schedule, typically daily.

The problem is in how the SEG sends the report. Most SEGs generate and send the report from their own infrastructure, using their own domain in the SMTP envelope and their own DKIM key to sign the message. When the report arrives at your mail server, the DKIM check validates the SEG's domain, not yours.

DMARC alignment requires that the DKIM signature cover a domain that matches or is aligned with your domain. If your domain is example.com and the report is DKIM-signed by mimecast.com, the alignment check fails. Your email filter may treat this as a suspicious signal and route the report to spam, quarantine it, or reject it entirely.

RFC 7489 (the DMARC specification) notes that RUA reports are not required to come from an aligned domain. They can come from any address. But this does not mean the reports arrive cleanly. In practice, many email filters do check DKIM on incoming mail, and a failing DKIM check on an automated report email is enough to get the message flagged.

The result: you configured DMARC monitoring correctly, you are paying for a SEG that supports DMARC reporting, and yet you are not reliably receiving your own aggregate reports.

How to Diagnose a DKIM-Failing RUA Report

The fastest way to confirm this is happening is to open one of the report emails you did receive (if any) and look at the headers. You do not need to understand all of them. Focus on two things:

1. The From header

This shows who the report is from. If you see something like From: Mimecast DMARC Reports , the SEG is sending the report from its own domain.

2. The DKIM-Signature header

This shows which domain signed the message. If it says dkim=_domain=mimecast.com, the DKIM signature covers the SEG's domain, not yours.

When these two domains do not match your own domain, you have the DKIM alignment problem. The From header and the DKIM-Signature header are both telling you the same story: this report was sent by a third party on their own behalf, not on behalf of your domain.

If you are not receiving any reports at all, check your spam folder, your quarantine, and your email filtering logs for messages rejected or filtered from your SEG's reporting address.

The Two Ways to Fix SEG RUA DKIM Failures

There are two approaches to solving this problem. Which one works for you depends on what your SEG supports.

Option 1: Allowlist your SEG's reporting address

The most common fix is to add your SEG's report sending address to an allowlist or whitelist in your email filtering system so that messages from it are not flagged for failing DKIM.

This does not fix the underlying technical mismatch. The DKIM check still fails. But your filter stops treating that failure as a reason to block or spam-filter the message. The reports arrive.

To do this, you need to know the exact address your SEG sends from. Common examples:

Mimecast: dmarc@mimecast.com
Proofpoint: dmarc@mail.proofpoint.com
Hornetsecurity: dmarc-reports@spamprotexx.hlbto.net (varies by region)
Cisco IronPort: the address you configured in your DMARC record

Check your SEG's documentation for the specific sending address. Some vendors use a range of IPs or multiple subdomains, which means you may need to allowlist an entire domain rather than a single address.

This approach works with any SEG and does not require configuration changes on the SEG side. The tradeoff is that you are telling your filter to accept DKIM failures from a specific source. If that source address is spoofed, your filter will accept spoofed messages that appear to come from your SEG.

Option 2: Configure your SEG to send reports from your domain

Some SEGs support sending DMARC reports on behalf of your domain. Mimecast calls this managed DMARC reporting. When configured correctly, the SEG generates the report and injects it into your mail stream as if it were sent from your domain, using your DKIM key. The DKIM check passes and alignment succeeds.

Whether your SEG supports this depends on the vendor and your subscription level. If it is available, the SEG documentation will describe it as something like "DMARC reporting on behalf of your domain" or "customer-domain DMARC sending." It typically involves:

Authenticating your domain with the SEG (proving you own it)
Configuring the SEG to use your domain in the SMTP MAIL FROM and DKIM signing
Possibly adjusting your DMARC record to include a rua=mailto address hosted by the SEG

If your SEG supports this, it is the cleaner solution. The reports arrive as normal authenticated email, with no DKIM failures and no need to allowlist a third-party address.

What If Reports Still Go to Spam After Allowlisting

Allowlisting the SEG's address should resolve most delivery problems. If reports are still going to spam after you have added the address to your allowlist, check a few things:

Your filter's handling of the message type. Some email filters apply aggressive spam scoring to automated non-interactive mail, even from allowlisted senders. If your SEG supports SPF-aligned sending, switching to Option 2 may help more than allowlisting alone.

The SEG's sending domain reputation. If your SEG has recently changed IPs, started sending from a new subdomain, or has a poor sending reputation in your mail filter's database, allowlisting the address may not be enough. You may need to explicitly trust the SEG's sending domain in your filter's configuration.

Your DMARC policy. If your DMARC policy is set to reject (p=reject) and your SEG is not DKIM-aligned with your domain, the aggregate reports themselves could be rejected at your border. This is uncommon but possible if your filter strictly enforces your own DMARC policy on inbound mail.

How to Verify Your RUA Reports Are Arriving

Getting reports delivered is only the first step. You also need to know if they stop arriving, because that is how you find out something broke.

Check your email filtering logs regularly. Look for messages from your SEG's reporting address that were delivered, rejected, or quarantined. If the volume of reports drops to zero when you were previously receiving them daily, something changed.

Set up a simple alert. If you stop receiving daily aggregate reports from your SEG for more than one expected reporting cycle, your monitoring is blind. Some teams set a calendar reminder to check manually. A better approach is to use a monitoring tool that tracks RUA report delivery as an operational metric.

This is where monitoring tools like DMARCFlow matter specifically for this problem. DMARCFlow tracks whether aggregate reports from all your RUA sources -- including your SEG -- are arriving on their expected schedule. If your SEG's daily report goes missing for more than one cycle, DMARCFlow alerts you before you realise your DMARC visibility has gone dark. For SEG deployments where the allowlist workaround is the only option available, knowing immediately when reports stop arriving is the difference between catching the problem in an hour and discovering it a week later when someone asks why your DMARC data looks so thin.

FAQ

Does a DKIM-failing RUA report mean my DMARC setup is wrong?

No. Your DMARC record and your sending infrastructure are probably fine. The issue is with how your SEG delivers reports to you, not how senders authenticate against your domain. Your DMARC policy still works for inbound mail. You are just not receiving your own monitoring data.

Can my SEG send RUA reports from my domain automatically?

Some can, some cannot. This depends on the SEG vendor and whether your subscription includes the feature. Mimecast calls it managed DMARC. Proofpoint has a similar capability for enterprise accounts. Check with your SEG's support or documentation to see if customer-domain report sending is available.

My SEG does not support sending from my domain. What else can I do?

Allowlisting the SEG's reporting address is the standard workaround. If allowlisting alone does not work, also check whether your SEG can send reports over a different channel (some support SFTP or HTTPS delivery instead of email), or whether you can route reports through a dedicated monitoring address that has lighter filtering applied.

Is it a standards violation if my SEG sends RUA reports from its own domain?

No. RFC 7489 explicitly notes that RUA report delivery is best-effort and does not require alignment. The SEG is not doing anything wrong by sending from its own domain. But many email filters still apply DKIM checks to these messages, which causes the delivery problems described here.

What to Check When Setting Up a New SEG

If you are deploying a new SEG and want to avoid this problem from the start:

1. Ask the vendor which address their reports come from. Get the exact domain, not just a vague answer.
2. Ask whether they support customer-domain DMARC report sending. If yes, configure it during setup.
3. If they do not, configure the allowlist entry before you enable DMARC reporting. Do not wait until reports start landing in spam to find out.
4. Verify you are receiving reports within the first reporting cycle. If you are not, check your spam folder and your filter logs immediately.

This is a configuration step that gets skipped often because it is not part of the core email flow. But if you rely on DMARC aggregate reports to monitor your domain's email authentication health, you need those reports to actually arrive.