No.

DMARC is an email policy that builds on DKIM and SPF to provide a way for email senders to declare: "All email from this domain comes from this set of servers (SPF), and is signed using these public keys (DKIM)."

It's nice and well that we are finally able to do that, but DMARC comes with 3 modes of operation: p=reject, p=quarantine, and p=none. These modes suggest what a recipient should do if an incoming email doesn't match the sender domain's DMARC criteria, either due to signature failure (DKIM) or incorrect sending server (SPF). The default mode, p=none, boils down to "do whatever, maybe this helps you guess if the email is spam". The mode p=quarantine treats the email as spam, and p=reject is supposed to cause the message to be rejected at the point of ESMTP delivery.

Well, I tried p=reject, and it kinda works. Mostly. Except in the following situations:
  • If you send to any mailing lists from your domain. Your messages may be DKIM signed, but when the mail server forwards them, they will be sent by a mail server that does not have authority to send messages for your domain according to your SPF criteria. Message headers may also be modified so that the DKIM signature does not validate. This will cause your messages to the mailing list to be rejected by many subscribers at the point of ESMTP delivery. This in turn may cause the mailing list to frown on you.
  • If you send to anyone with a multi-layered mail server setup. In this case, your message is received correctly by the front mail server, which is configured to forward it to a back mail server. You cannot control this because it's a setup specific to the recipient and unknown to you in advance. But the back mail server is poorly configured to verify DMARC criteria, and rejects the message because it violates your SPF policy – from the perspective of the back mail server, it is coming from the wrong IP. The message may then be deleted silently, or sorted into trash.
This means you pretty much can't safely run a mail server with DMARC policy set to p=reject. For the same reasons that p=reject is not safe, p=quarantine also makes no sense. There's not much difference between causing your outgoing mail to be bounced and/or deleted, or causing it to land in spam.

DKIM and SPF are good ideas, but it's unfortunate that the policy has to be "none".