2

Domain: franzoni.eu

Such domain leverages G Suite (grandfathered free version) for receiving mail, but for various reasons (I prefer not to create users for M2M SMTP on G Suite, and I cannot use SMTP to send with aliased source addresses) I setup Amazon SES for sending e-mails; the domain is verified in Amazon SES, I added all the records for DKIM and SPF.

The strange issue is: I get DMARC aggregate reports whenever I send mail through Amazon SES. I have tried via Postfix from my servers and via Gmail (I setup a custom SMTP server on my personal gmail.com account, using a verified identity @franzoni.eu as an alias).

But such reports show no failure, and my DMARC fo is set to 1, which should mean to send a report iff an error in either SPF or DKIM was found. If I send an e-mail to gmail or other providers, I can find no failures in headers, either; dkim and spf are "pass" everywhere.

Sample aggregate report:

<?xml version="1.0"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>17723215002606464836</report_id>
    <date_range>
      <begin>1636675200</begin>
      <end>1636761599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>franzoni.eu</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>69.169.224.12 (Amazon SES)</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mercedes.franzoni.eu</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>franzoni.eu</domain>
        <result>pass</result>
        <selector>t3mfs7y2mai3am32z7ordoghte2ff3lv</selector>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <result>pass</result>
        <selector>54ecsf3zk7z4mwxwwox7z7bg6e5gwjsz</selector>
      </dkim>
      <spf>
        <domain>mailde.franzoni.eu</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

This is _dmarc.franzoni.eu DNS record:

_dmarc.franzoni.eu. 1800    IN  TXT "v=DMARC1; p=none; rua=mailto:franzonieu-d@dmarc.report-uri.com; ruf=mailto:dmarcforensics@franzoni.eu; fo=1;"

I tested sending an e-mail to some DMARC analyzer tools (e.g. https://www.mail-tester.com/ ) and they all say my DMARC is all right, and I never get a forensic report even though I configured the ruf part. This makes debugging harder.

Any idea about why such thing is happening would be appreciated.

  • 1
    BTW, it is very common today to comply with senders wishes for aggregate reports, yet not ever send forensics to untrusted destinations. – anx Nov 15 '21 at 03:53

1 Answers1

1

The aggregate report is generated based on a time period and not whether there was a failure.

From RFC 7489 7.2:

Visibility comes in the form of daily (or more frequent) Mail Receiver-originated feedback reports that contain aggregate data on message streams relevant to the Domain Owner. This information includes data about messages that passed DMARC authentication as well as those that did not.

A failure report is only generated when there is a failure.

From RFC 7489 7.3

Failure reports are normally generated and sent almost immediately after the Mail Receiver detects a DMARC failure. Rather than waiting for an aggregate report, these reports are useful for quickly notifying the Domain Owners when there is an authentication failure. Whether the failure is due to an infrastructure problem or the message is inauthentic, failure reports also provide more information about the failed message than is available in an aggregate report.

Paul
  • 2,755
  • 6
  • 24
  • 35
  • 2
    Thanks, Paul. So I never got a DMARC failure, that's the real reason for not getting forensics (=failure) reports. I had never looked directly at the RFC, only to other resources, including record generators, and the "forensics" vs "aggregate" distinction was quite blurred. I thought that ALL reports were failure reports, with the "aggregate" vs "forensics" being a way to discriminate. Lesson learned: always look at the original spec! – Alan Franzoni Nov 14 '21 at 07:01