Exchange Online Suddenly Rejecting Emails from PaperCut Due to DMARC

Check the message’s Authentication-Results headers if you can obtain them from an older successful message or from the sender’s bounce details. They should show whether SPF and DKIM passed and whether either one aligned with the From domain. A relay, forwarding service, or other change in the route can also break alignment. Since these messages are never arriving, the PaperCut administrator will probably need to inspect the sending logs and DMARC reports.

The default anti-phishing behavior can honor a sender domain’s published p=reject policy, but this is not a new setting that was suddenly switched on. If a temporary workaround is absolutely necessary, a narrowly scoped trusted relay or allow rule may help, but it should be treated as a short-term measure. The proper fix is for the sender or any intermediate relay to restore valid, aligned SPF or DKIM authentication.

There was also an Exchange Online service incident involving delays receiving mail from external domains, so it is worth checking whether that incident was active when the failures occurred. However, the specific 550 5.7.509 response strongly points to DMARC authentication failure rather than a normal delivery delay. PaperCut should verify that its sending infrastructure is still authorized by SPF and signing with DKIM for a domain aligned with papercut.com.

Exchange Online has supported and honored a sender’s DMARC policy, including p=reject, for a long time. Microsoft probably did not enable a brand-new global enforcement switch overnight. The likely cause is a change on PaperCut’s side or somewhere in the delivery path that caused SPF and DKIM to fail or become misaligned. The sender needs to correct its authentication setup; changing your tenant to bypass DMARC would only hide the problem.