Summary
LetsDMARC shows failures coming from email security services and forwarding servers that belong to your recipients. The messages behind those failures are copies of messages you sent correctly, delivered a second time by somebody else. The failure is not caused by your systems and it is not an error of LetsDMARC, and it is not a reason to postpone a reject policy.
Before you start
- Access to the LetsDMARC dashboard for the domain you are looking at.
- The list of the sources that really send mail on behalf of your domain, such as your mail gateway, your tenant, your marketing platform and your ticketing system.
- The current DKIM status of each of those sources.
How it works
Your message leaves your gateway and passes SPF, DKIM and DMARC at the first delivery. The receiving server accepts it, and this is the delivery that matters to you and to your recipient.
Many recipients then move the message a second time. Their mail server hands it to an external security service through a connector, a transport rule or an API, or a mailbox rule forwards it to another address. In both cases the message is delivered again, and this second delivery starts from an IP address that belongs to that service or to the forwarding server.
That address is not in your SPF record, so SPF fails, and it is correct that it fails, because you never authorised that host to send mail for your domain. If the service also modifies the message, for example by adding a warning banner, rewriting links or changing the subject, the DKIM signature breaks as well. With neither SPF nor DKIM aligned, DMARC fails.
The system that receives this second copy sends an aggregate report to your domain, because your domain is still the one in the header From. LetsDMARC reads that report and shows the failure with the name of the service as the source.
Symptoms
In the DMARC reports by sources page you see failures from hostnames that you do not recognise and that you never configured. They also appear in the Top 5 failure sources panel, which is usually where the question starts. The full list is in the large Details table at the bottom of the page, one row for every source that sent mail with your domain in the header From.
The source names observed so far include cloud-sec-av.com, inkyphishfence.com, perception-point.io, shield.security, ppe-hosted.com, mimecast.com, sonicwall.com and oraclecloud.com. The list keeps growing, because it depends on which product each of your recipients bought.
These sources show a compliance close to zero, with both SPF and DKIM at zero, while your own sending platforms stay at ninety-nine or one hundred per cent. Their volume is a small share of your total traffic.
Four signs together tell you that you are looking at this case.
| What to look at | What you see in this case |
|---|---|
| Source | A known email security service, or a server that forwards mail for a recipient |
| Header From | The same domain used by your legitimate sources, because the message is a copy of yours |
| Forwarded | Often a value above zero. LetsDMARC works it out on its own, and the value is not always one hundred per cent: sometimes it is lower, sometimes it stays at zero even for a service that clearly forwards. Read it as a hint, not as proof |
| Volume | In line with your normal traffic towards that recipient, with no sudden peak |
Cause
The failure is generated by whoever performs the second delivery. It is not generated by your servers, which did their job correctly at the first delivery, and it is not an error of LetsDMARC, which only shows the reports it receives from the systems that got that second copy.
Nothing is broken on your side. There is no setting in your DNS, in your gateway or in LetsDMARC that turns these failures into passes, because the delivery that fails is made by a host you do not own and cannot control.
Solution
- Open the large Details table at the bottom of the page and look at the failing source. If it is an email security service or a forwarding server of one of your recipients, there is nothing to do.
- Do not try to make those failures pass. Trying to fix them is the one thing that leads to a dangerous change, and the only sound approach is to leave them out of the count when you judge the health of your domain.
- Never add the IP addresses or the SPF include of these services to your own SPF record.
- Make sure every legitimate source of yours signs with an aligned DKIM key. An intact signature survives a plain forward, so part of these second deliveries can still pass DMARC through DKIM alone.
- Move your policy to reject when your legitimate sources are compliant. These failures on their own are not a reason to wait.
Adding a recipient security service to your SPF record is the one change that makes things worse, because from that moment anyone using that platform can send mail with your domain and pass SPF.
Check the result
Filter the Details table on your own sending sources and confirm that each of them is compliant, with SPF or DKIM aligned. That is the number that decides whether you are ready for reject.
Then look at the failing sources again. If every one of them is a security service or a forwarder, and the volume stays in line with your normal traffic, your domain is in good shape even while the failure counter keeps moving.
Known limitations
- Your first delivery is never affected. The message you send passes DMARC, so a reject policy does not touch it, it is not blocked and it does not count as a failure. The failures you see belong to the second delivery only.
- What happens to the second copy cannot be predicted from your side. It depends on how the recipient set up the service, on what the service does to the message and on which system takes the final decision, and a badly configured service may have that copy rejected.
- SPF cannot survive the second delivery, because the message leaves from a host you did not authorise. This is how SPF is designed to work.
- DKIM survives a plain forward, but it breaks whenever the service modifies the message.
- These reports keep arriving as long as your recipients use those services. You cannot stop them from your side.