2

I just setup our domain a couple weeks ago to use SPF and DMARC, but no DKIM atm. But every now an then I receive an DMARC Failure report from linkedin:

This is an email abuse report for an email message received from IP 213.160.4.146 on Tue, 16 Jul 2019 12:34:26 +0000.
The message below did not meet the sending domain's dmarc policy.
The message below could have been accepted or rejected depending on policy.
For more information about this format please see http://tools.ietf.org/html/rfc6591 .

Feedback-Type: auth-failure
User-Agent: Lua/1.0
Version: 1.0
Original-Mail-From: 
Original-Rcpt-To: messages-noreply@linkedin.com
Arrival-Date: Tue, 16 Jul 2019 12:34:26 +0000
Message-ID: <5cd…8b2f@SR-EXC.biv.local>
Authentication-Results: dmarc=fail (p=none; dis=none) header.from=biv-ot.org
Source-IP: 213.160.4.146
Delivery-Result: delivered
Auth-Failure: dmarc
Reported-Domain: biv-ot.org

But I can't detect any error - the IP address and domain match our MX record which is included in the SPF entry. Also the referenced RFC 6591 doesn't include the auth faile "dmarc". I get this mail round about once a week and no other server send me ever an DKIM failure report. Any idea whats wrong?

DNS Entries:

biv-ot.org:
MX:    mail.biv-ot.org
A:     148.251.171.224
SPF:   v=spf1 a mx include:ot-live.zms.hosting a:mout.kundenserver.de ~all
DMARC: v=DMARC1; p=none; ruf=mailto:…; fo=s 

mail.biv-ot.org:
A: 213.160.4.146
Verim
  • 1,065
  • 9
  • 17
  • Looking at the `original-mail-from:` and `original-rcpt-to:` fields I suspect this is about an NDR message. Quite often the `smpt.mailfrom` is stripped in an NDR message and the receiving server relies on an HELO check for SPF. Which is the name with which your server responds to connections. If you publish an SPF record for that name in DNS you may have solved your issue. That SPF record should only contain IPs for the servers that use that name. – Reinto Jul 17 '19 at 15:26
  • Actually its an out of office auto reply, but I never the less I'll check what EHLO name is used. – Verim Jul 18 '19 at 06:22
  • 1
    Any update on your situation might help other people. Did you get to the bottom of this, @Verim ? NDRs and DSNs like an out of office are very similar in how they look in terms of headers. Also, setting up a rua tag in your DMARC record might help you gain insight in this particular issue. – Reinto Dec 18 '19 at 18:30

1 Answers1

2

This behavior is often witnessed with automated responses, such as NDRs and Out of Office replies, from mail servers as described in the Simple Mail Transfer Protocol (SMTP) RFC, section 4.5.5

In these cases the smtp.mailfrom field is empty and in most SPF implementations the check falls back to checking the HELO identity (recommended), as described in the SPF RFC, section 2.4.

Even if you create an SPF record for the HELO identity, you may still fail DMARC (on SPF) because of misalignment, if the HELO identity does not share the organizational domain of Header.From address.

In your specific case, the HELO identity would be assumed as postmaster@firewall.biv-ot.org and the reported domain (Header.From) is set to: biv-ot.org. This means that publishing an SPF record for firewall.biv-ot.org would solve your issue.

Also note: You only publish a ruf= address in your DMARC policy. Almost no mailbox providers send forensic/failure reports, so it is not wise to rely on only these reports to judge whether or not your email authentication practices are in a good state. These blogs by Dmarcian and Valimail outline why these forensic / failure reports are so scarce.

Community
  • 1
  • 1
Reinto
  • 885
  • 6
  • 9