2

I understand that by publishing an initial p=none policy, you basically instruct recipients that participate in DMARC to NOT treat incoming mail any different than how they did before a DMARC policy was published.

Regardless of the DMARC alignment result, "do not drop mail" (at least not on the basis of DMARC non-alignment).

For recipients not taking part in DMARC, this is irrelevant since they will not lookup your policy in DNS and hence will not action their mail based on DMARC alignment resp. non-alignment.

Obviously mail might still be bounced or non-delivered on the recipient side due to whatever additional security mechanisms or local policy the receiving mail server chooses to apply.

Receiving mail servers might also decide to NOT follow your DMARC policy, but drop every inbound mail that has failed SPF and/or DKIM, regardless of the final DMARC alignement test result.

In short, I can tell them that I want them to apply my DMARC policy, but I cannot force them to. And I have no visibility on whether they apply the policy or not.

So say I publish my DMARC policy in DNS. Senders complain that mail is bounced. I have no way to check k's of receiving mail server logs for DMARC checks and subsequent actions. These are not my servers!

My question - is there a reliable way I can prove that mail sent from my mail servers was NOT caused by the newly deployed DMARC policy, but any other cause?

How can I have more visibility on the application of my DMARC policy on the receiving side, apart from hypothetical aggregate/forensic reports?

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
pescator
  • 51
  • 3

1 Answers1

2

I run quite busy domains for a year on DMARC p=reject and, after initial pains, things run now more or less unattended.

DMARC aggregate reports (RUA) are not hypothetical, surprisingly many domains does send them, and I don't mean only Google/Microsoft/Yahoo.

I haven't seen any forensic report RUF sent to me yet when there was an error (and RUA indicated the cause was DMARC).

Don't worry too much about rejections where the recipient only checked SPF or only checked DKIM, I don't see this in practice.

You absolutely need DKIM, because many people forward their mail and this immediately fails SPF check (for example they publish x@example.com, but the mail lands at name.surname@gmail.com).

Also, DKIM header has its own diagnostics flag (something like RUF/forensics) and linux opendkim installations often do send useful diagnostic messages.

kubanczyk
  • 1,182
  • 6
  • 11
  • Both, Many thanks for your answers, any additional suggestions for processing incoming reports? Has this been a time-consuming task? Did you outsource the analysis or write a small script to digest the reports? – pescator Oct 03 '16 at 13:23
  • @pescator Please consider upvoting and marking the best answer, this is important for others. I don't process the aggregate reports, I found it is sufficient to check them randomly once in a while - I will see immediately if many emails would bounce or users will notify me. But no problems yet. – kubanczyk Oct 03 '16 at 13:39