2

I have a daily report sent through AWS SES to an Outlook mailbox on workdays. For some reason outlook marked yesterday's and Friday's emails as 'Unverified sender'. Today's email wasn't marked as 'Unverified sender'. Any previous emails before Friday also weren't marked as 'Unverified sender'. Close inspection of the email headers shows only the following relevant difference:

Authentication-Results: spf=pass (sender IP is 54.240.48.132) smtp.mailfrom=amazonses.com; dkim=pass (signature was verified) header.d=amazonses.com;dmarc=fail action=none header.from=xxxxxx.com;compauth=fail reason=001 Received-SPF: Pass (protection.outlook.com: domain of amazonses.com designates 54.240.48.132 as permitted sender) receiver=protection.outlook.com; client-ip=54.240.48.132; helo=a48-132.smtp-out.amazonses.com; pr=C

Full headers for failing message

Authentication-Results: spf=pass (sender IP is 54.240.48.130) smtp.mailfrom=amazonses.com; dkim=pass (signature was verified) header.d=xxxxxx.com;dmarc=pass action=none header.from=xxxxxx.com;compauth=pass reason=100 Received-SPF: Pass (protection.outlook.com: domain of amazonses.com designates 54.240.48.130 as permitted sender) receiver=protection.outlook.com; client-ip=54.240.48.130; helo=a48-130.smtp-out.amazonses.com; pr=C

Full headers for normal message

The same messages are sent to a Gmail account, where they always pass DMARC checks. For example, there are full headers for yesterday's message received in the Gmail account with the same Message-Id as the failing message in the Outlook account.

There were no changes to DNS, SES settings or the Lambda function used to send the messages in the last two weeks. All these things are managed by Terraform and there are no changes in the source code and no drift in the terraform plan.

The DMARC reports from [email protected] seem to be messed up - the last one I received on Sep 2 was for the period between 2024-08-27 00:00:00 UTC to 2024-08-28 00:00:00 and the previous one on Aug 31 was for period 2024-08-29 00:00:00 UTC to 2024-08-30 00:00:00 UTC and no reports for the period of the failures yet.

I wonder if I'm missing something in the mail headers that caused this DMARC failure.

Improve this question
8
  • 1
    have you verified Custom MAIL FROM domain in ses for your sender identity?? Commented Sep 3, 2024 at 13:24
  • @0xn0b174 yes, I have Custom MAIL FROM configured for the source domain and it shows as Successful in the SES control panel but for some reason, I don't see it in the headers. I suspect it uses a different identity, the source email instead of the domain, and it doesn't have Custom MAIL FROM. Commented Sep 3, 2024 at 13:51
  • If you remove the specific identity for the Sender Address it should default to the domain AFAIK. The headers in the failing Microsoft email indicate that both DKIM signatures (for Amazon and your own domain) are present, but for some reason the one for your domain is failing the check (due to whatever reason not presented in the headers). Hopefully the DMARC report will shed light on the failure. Commented Sep 3, 2024 at 14:19
  • @Reinto , could you point which header indicates DKIM failure? Could you explain why today's message isn't failing DMARC checks without any changes? Commented Sep 3, 2024 at 14:36
  • Both the MS and Gmail headers show double DKIM signatures, one for your domain and one for the platform it was sent from. In the Authentication-Results header the Gmail email headers indicate success for the signature on behalf of your domain. The MS headers only indicate success for the signature on behalf of the platform (SES), while the results for the signature for your domain would be most relevant. It's not absolute proof, but an indication MS failed to successfully verify the signature for your domain. Could be anything from bad signature to DNS query failure or whatever. Commented Sep 3, 2024 at 14:43

1 Answer 1

Reset to default
0

The DMARC report for the period 2024-09-02 00:00:00 UTC to 2024-09-03 00:00:00 UTC finally arrived and it indicates the status fail for the DKIM signature with selector pxtkcinvoxwfizjlokrxde4qiumn7key. There are no DMARC reports for Friday's failed message.

I don't believe that the DKIM failure is caused by anything in the message itself or the sending infrastructure, as the same message was delivered to the Gmail account at exactly the same time with DKIM fully verified and this happened twice with the interval of 3 days.

According to a comment on /r/Office365

Essentially when exchange 365 tries to resolve any dns record (mx,spf,dkim,dmarc) and it takes longer than 500ms they treat the record as nonexistent.

According to RFC 6376 Section 6.1.2

  1. If the query for the public key fails to respond, the Verifier MAY seek a later verification attempt by returning TEMPFAIL (key unavailable).
  2. If the query for the public key fails because the corresponding key record does not exist, the Verifier MUST immediately return PERMFAIL (no key for signature)

Afterthought: actually, two DNS timeouts in a row with a few days interval doesn't sound plausible.

Improve this answer
1
  • Good that the DMARC report finally came in. Microsoft has a sub optimal record when it comes to DNS queries for email authentication records. SPF records often time out when a lot of other TXT records exist (at the root) like verifications records and the answer becomes too large for an UDP packet. Similarly, this happens for DKIM selectors with large key lengths, i.e. 4096 bit and larger. This is possibly out of DoS protection considerations. I'd still say DNS time out is the most likely culprit. Making the Custom Mail From domain work may solve this issue in most occasions. Commented Sep 6, 2024 at 14:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.