DMARC/SPF/DKIM - forward quarantine emails to a separate email address

Question

Is there a way with DMARC/SPF/DKIM to forward all emails that fail DMARC to an email address I specify?

Ie, if someone tries to spoof an email saying it's from me, and it fails, I'd like that email to be sent to an email address I specify rather than who they intended it for.

Is that something that can be done?

I've been running RUF/RUA for a month now, with different settings to get reports on what 3rd party services to update. However, I'm still getting some spoofing attempts from the Middle East/Asia. I'm looking to get all emails that fail DMARC to be sent to a specific email address I specify, rather than be sent to the end user(spam) or blocked.

• We use Google Apps for our Email Sever.
• All Domain information (TXT records) are stored on Route 53 on AWS.

From our RUF report I'll see an entry like this:

  <record>
    <row>
      <source_ip>45.123.219.46</source_ip>
      <count>14</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>****.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>***.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>

In this case, it would be interesting to know what was being sent out.

Answer 1

A quick search turns up DMARC Failure Reports.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.

_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"

Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.

_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"

Note the warning at the top of the section though regarding whether you actually want to do this:

Not until you have read this answer and made sure you are ready to receive a LOT of messages...

Edit: I misread the wiki slightly, it looks like RUF reports can include the entire email, but they won't necessarily.

It's obviously up to the server validating DKIM and SPF to decide what to do in the case of failure, DMARC is essentially asking servers "could you please treat validation failures a certain way", and RUF is asking "if an email fails validation, could you please tell me why?", but it's quite possible some servers just aren't bothering to give you a report, or that the report doesn't include everything you want it to. If they want to ignore your request there's not much you can do.

Answer 2

Are you seeing DMARC records with malicious reporting addresses? (These are the rua= and ruf= for aggregate and full reports.) If so, I'd be very interested in seeing them. I'm not terribly concerned with this as an attack vector since these reports are trivial to block and the messages designed to trigger a DDoS volume of full reports to such a victim would eventually get the attacker in trouble.

The whole point of DMARC reporting addresses is to allow the (legitimate) owner of the (purported) sending domain to see who is forging their mail, which helps identify improperly configured legit servers (e.g. a marketing affiliate) as well as spoofing attempts. No sane (enterprise) DMARC implementation uses p=reject until the reports suggest it is safe.

Google doesn't appear to include DMARC results in its Authentication-Results headers, otherwise you'd be able to harvest that out and create your own report copy. However, you've already eluded to having your own mail infrastructure.

A filter like procmail would be able to write a recipe like this:

:0c
^Authentication-Results: mx\.google\.com;[^A-Z]*dkim=[^p]
! my-reports@example.com

This looks for the Authentication-Results header added by mx.google.com and sees if it tested DKIM yet didn't see a valid signature (which would be dkim=pass). If so, it forwards a copy to my-reports@example.com. (Make that first line :0 to prevent delivery instead of copying the message.)

Note that this matches a DKIM failure and not a DMARC failure. I believe DMARC p=reject failures would never have been delivered to you by Google, so you probably can't intercept the reports.