`p=reject`, ESPECIALLY for your personal email. `p=quarantine` is really only useful if you suspect your marketing department has set up some email blaster somewhere.

Realistically spoofed address (unauthenticated email) will be treated as spam and it’ll be implicitly quarantined or rejected as such by many well-known mail receivers. You can make this an explicit “reject” by publishing DMARC policy for your domain.

For example, gmail.com treats unauthenticated email as spam implicitly, regardless of DMARC policy.

That's what the policy setting tells the recipient. You can tell them to trest it as normal, send it to spam or delete it.

The report that they send you is useful for you to make sure your emails that you expect to go through are going through.

Reject it in the SMTP transaction.

No, it doesn't.

In the following SMTP conversation:

  MAIL FROM: foo@example.net
  RCPT TO: victim@example.com
  DATA
  From: service@paypal.co.uk
  To: victim@example.com
  Subject: We are updating our Terms of Service
  [...]

The recipient sees service@paypal.co.uk (the From address on the inner message), because most ESPs do them the great disservice of not indicating that the sender identities are not aligned.

Adding a DMARC record to a domain requires that e-mail whose inner messages claim to be from that domain must have sender alignment to the envelope sender.

The above message would pass SPF (if the spammer owns example.net and has created SPF records for themselves) but would fail DMARC (paypal.co.uk's DMARC record exists, so alignment is required, and yet example.net != paypal.co.uk, so they are not aligned). In this case their DMARC policy says to reject the message, so (if the recipient is checking DMARC) it would either be rejected outright or it would land in Spam/Quarantine rather than Inbox.

Technically, no.

SPF allows to say “these IPs are authorised to send emails as example.com”, where DMARC allows to say “I as domain owner recommend to quarantine emails that fail SPF and DKIM”, it also allows finer alignment (ie, matching between different “from” parameters) configuration and reporting by the receivers.

Of course, with absence of DNARC policies, receivers default to some internal defaults, or may ignore the policies altogether. But at least, the big ones send DMARC reports.

Not always. An email has a valid SPF when its return path email’s domain permits the sending server’s IP. But that email may have a forged From: header (which causes an SPF mis-alignment), and the receiving server checks the DMARC of *the From header* domain to determine how to handle that mis-alignment.