You don't have to, this is the key reason to have a DMARC monitoring service. It will tell you when there's a deliverability issue with some particular receiver.

DMARC applies not on your mail server, inbound or outbound, but on the server that is receiving your mail (which may in fact be your mail server).

That server will look at how the mail authenticates and decide if it should allow the mail to proceed, it (for the most part) will then tell you whether or not it allowed the mail. This is how you will know you might have a deliverability problem before your customers do.

If you're wanting to know about deliverability (particularly for this Microsoft case), my company (Alesian Security) has a free check at https://alesiansecurity.com/try?tab=deliverability

▲

toast0 5 hours ago | parent [-]

> You don't have to, this is the key reason to have a DMARC monitoring service. It will tell you when there's a deliverability issue with some particular receiver.

It's been a while, but monitoring DMARC seemed pointless once you got things started. If my outbound mail fails to validate, I've asked the receivers to bounce it, and I should be able to see that on my own system.

Otherwise, I'm just getting reports about spoofed spam or people who need to adjust their mail forwarding, but I can't do anything about either.

	▲	jared_stewart 4 hours ago \| parent [-]
		right, if you're at a reject status DMARC monitoring is (and should be) boring. But it provides a safe guard against accidentally broken mail flows as your email stack evolves over time which is where it pays dividends. I would love to say that it would have alerted you ahead of time to this particular event, but given that it's the fix here you would never have seen it.