Authentication vs deliverability.

Your DMARC looks bad, so you assume mail isn't getting through. Or it looks perfect, so you assume every message landed. Both can be wrong, because DMARC answers a different question than "did this email arrive?" Here's the line between the two, so you read your reports for what they actually say.

Short answer: DMARC reports measure authentication (did the From: prove it's really you), not delivery (did the message reach the mailbox). A message can pass DMARC and still bounce, and it can fail DMARC and be completely harmless. They're separate systems that happen to involve the same email.

Two different questions

Every email is judged twice, by two different mechanisms that don't talk to each other:

Authentication (what DMARC reports cover): did SPF or DKIM line up with your From: domain? This is about identity: proving the sender is allowed to use your domain. Pass or fail.
Deliverability (what DMARC reports can't see): did the receiving mail server actually accept the message and drop it in the inbox? This is about logistics: mailbox quota, spam filters, greylisting, content rules, reputation. Delivered, bounced, or filtered.

A message has to clear both to reach a human. DMARC only tells you about the first.

Why the reports can't see delivery

A DMARC aggregate report is a summary one receiver sends back about the mail it saw claiming your From: domain. It records how each message authenticated and what disposition the receiver applied under your policy: delivered, quarantined, or rejected.

That disposition is a DMARC decision, not a delivery receipt. "Delivered" here means "DMARC didn't block it", not "it reached the mailbox". After DMARC passes a message on, the receiver still runs spam filtering, checks the mailbox quota, and applies its own rules. None of that ever appears in a DMARC report. So the source drawer's Delivered / Quarantined / Rejected counts answer "did it authenticate?", never "did it land?"

Passed DMARC, still bounced

This is the one that surprises people. A message authenticates cleanly, DMARC is a green pass, and it still never reaches the person. Common reasons, all invisible to DMARC:

The mailbox is full. The server returns a 552/5.2.2 "quota exceeded" and bounces the message back to the sender. Authentication was never the problem.
A spam or content filter caught it. The message proved its identity, then lost on reputation, a keyword, or an attachment rule.
The address doesn't exist (a typo, a closed account), or the receiver is greylisting and asking the sender to retry.

In every case DMARC did its job perfectly. The breakdown is downstream, in delivery, where DMARC has no visibility.

Failed DMARC, perfectly fine

The mirror image, and the one that triggers needless panic. A source shows DMARC fail, but no real mail of yours is affected. The usual cause is forwarding: an inbound security gateway or a "forward to" rule relays a copy of your message from its own server. That breaks alignment by design (the relay isn't in your SPF, and scanning can break your DKIM signature), so the forwarded copy fails DMARC, while your original was delivered to its first recipient untouched.

dmarcula flags these for you: a forwarder is shown as forwarded rather than a red failure, it's excluded from your "direct mail" rate, and the drawer says "Nothing to authorize". There's nothing to fix, and it's no reason to weaken your policy.

How to actually check delivery

Because delivery lives on the receiving side, that's where you confirm it, not in DMARC data:

Check for a bounce (NDR). If a message didn't deliver, the sending server almost always gets a non-delivery report explaining why. Start in the sender's inbox.
Run a message trace on the receiving mail system (Microsoft 365 and Google Workspace both have one). It shows the per-message path and the real outcome: delivered, bounced, quarantined, and the reason.
Read the SMTP status code. A 5.x.x is a permanent failure with the cause spelled out (full mailbox, no such user); a 4.x.x is a temporary defer that will retry.

Keep reading

SPF fails but DMARC passes: the most common "looks broken, isn't" case, explained in full.
Investigating sources: tell a forwarder apart from a real sender in the source drawer.
Reading your dashboard: what the authentication rate and verdict are actually telling you.

Seeing a failure you can't place, or mail that authenticates but won't arrive? Email support@dmarcula.com and we'll work through it with you.