Join Log in
Score:1
Leo Galleguillos avatar Server

Why does spf fail in DMARC report from Google?

jp flag
Leo Galleguillos

I recently received a DMARC report from Google alerting me of a few SPF failures with mail originating from IP addresses belonging to Amazon SES. A sample record is as follows (I have replaced our domain with example.com.):

  <record>
    <row>
      <source_ip>54.240.27.187</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>mail.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

Is SPF failing because the header_from value is example.com while the SPF domain value is mail.example.com?

We use Amazon WorkMail and Amazon SES to send both manual and automated email. The From address is usually [email protected], and we have set our MAIL FROM domain to mail.example.com. Therefore I am a little puzzled as to why Google would report the header_from domain as example.com rather than mail.example.com. We have set an appropriate SPF record for both example.com and mail.example.com.

Also, I tried sending test emails to a Gmail address using both Amazon WorkMail and Amazon SES. In both cases, SPF passed, as did DKIM and DMARC.

451
0 + 0
spf
Paul avatar
cn flag
Paul
It appears the DMARC test failed on SPF, which is not the same as failing an SPF test. You didn't post your DMARC records - do you configure adkim or aspf as strict?
2
Reply
Leo Galleguillos avatar
jp flag
Leo Galleguillos
Yes, both adkim and aspf are set to strict. Our DMARC record is as follows: `v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100`
1
Reply
Score:2
Paul avatar Server
cn flag
Paul

DMARC compares the RFC5322.From domain with the SPF-authenticated domain. In your report, we can see that the RFC5322.From domain is example.com and the SPF-authenticated domain is mail.example.com.

The aspf tag is used to indicate whether the DMARC SPF alignment test should be strict (s) or relaxed (r), with relaxed being the default.

A DMARC record set with aspf=r value or no aspf tag will verify the RFC5322.From organizational domain matches the SPF-authenticated organizational domain. Your record would pass with this alignment because the organizational domains example.com for both.

A DMARC record with aspf=s value will verify an exact DNS domain match for the RFC5322.From domain and the SPF-authenticated domain.

The DMARC test has failed because aspf=s is configured in your DMARC record and the RFC5322.From domain of example.com and the SPF-authenticated domain of mail.example.com are not the same.

0 + 0
Leo Galleguillos avatar
jp flag
Leo Galleguillos
Thank you. Btw, https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-authentication-dmarc.html says to "Ensure that your sending domain uses a relaxed policy for SPF." So, although we wanted a strict policy for security, I guess we will need to make this relaxed for now.
1
Reply
Paul avatar
cn flag
Paul
You could set a strict DMARC policy on the subdomain and use that as the From so the domains align and use for mail deemed critical even though it looks, well, how it looks. Assuming that option is compatible with their service.
0
Reply
Leo Galleguillos avatar
jp flag
Leo Galleguillos
Thank you. However, we need to send mail from `[email protected]` and not from `[email protected]`, and the `MAIL FROM` domain must be `mail.example.com`, so I don't think is possible in our case.
0
Reply
Score:0
ziegel avatar Server
bh flag
ziegel

For me, it seems Google fails on DKIM when it auto forwards emails from one Gmail account to a second Gmail account.

I guess they at Google should know that in such a case DOMAIN should be original Domain, however they check there own gmail.com Domain. Other option for them would be to recreate New Dkim signatures, removing original ones.

Currently, some of the emails in the Gmail report appear as failed DMARC, due to SPF domain reported for an SPF check (passing on its own) being gmail.com which is different than example.com or the MAIL_FROM set according to AWS SES guide, via DNS record, to be mail.example.com.

Below is a full daily report, where the IP '209.85.220.41' fails DMARC due to using 'gmail.com' domain on the SPF check:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>999999999999999999</report_id>
    <date_range>
      <begin>1686441600</begin>
      <end>1686527999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>s</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>quarantine</sp>
    <pct>100</pct>
    <np>quarantine</np>
  </policy_published>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>6</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>AWS_CNAME_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <result>pass</result>
        <selector>AWS_OWN_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <spf>
        <domain>gmail.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>54.240.8.60</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>AWS_CNAME_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <result>pass</result>
        <selector>AWS_OWN_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <spf>
        <domain>mail.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>54.240.8.176</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>AWS_CNAME_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <result>pass</result>
        <selector>AWS_OWN_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <spf>
        <domain>mail.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>54.240.8.237</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>AWS_CNAME_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <result>pass</result>
        <selector>AWS_OWN_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <spf>
        <domain>mail.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>54.240.8.13</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>AWS_CNAME_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <result>pass</result>
        <selector>AWS_OWN_AUTHENTICATION_SELECTOR</selector>
      </dkim>
      <spf>
        <domain>mail.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>
+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.