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.

enter image description here

  • 2
    it all depends on the email server you are using - DMARC and SPF policies tell the receiving server what to do, but it's up to the server to handle one way or another - what's your server? Once you add that detail, I'll migrate to the ServerFault site – schroeder Aug 22 '17 at 16:57
  • then you are stuck for options: you would need to contact Gmail support – schroeder Aug 22 '17 at 20:32

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.

  • I've ran with RUA and RUF for awhile with my pct=0 to verify the stats on our domain. After 1 month I changed our DMARC settings to quarantine, and I've noticed that we're still getting a few failures from IP's in the middle east trying to spoof us. I'm trying to figure out how to get the emails that failed sent to us so I can inspect them. – Ryan Ternier Aug 22 '17 at 16:32
  • This does not answer the question about custom handling of individual messages that fail authentication – schroeder Aug 22 '17 at 16:58
  • @schroeder That's what I thought initially, but he says I'd like that email to be sent to an email address I specify rather than who they intended it for, which sounds to me like he just wants to direct it to an address. It's obviously up to the server validating the email to decide what to do, but the DMARC wiki says A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF), looks like I falsely equated that can with will. – AndrolGenhald Aug 22 '17 at 18:05

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.