Skip to main content

Invalid DKIM Signature for Some Mail

As of 2023-07-26 FeedMail messages sent via AWS SES have an invalid DKIM signature. This may result in messages ending up in your spam folder. This is an ongoing issue and updates will be posted here as they are available.

Who is affected?

This is unlikely to affect most of our users for the following reasons:

  • 97% of our mail is sent by us directly, not via AWS.
  • This mail still has a SPF-verified sending IP.

However this may still affect users because spam filters may consider these messages less "good" than they would have been with a valid DKIM signature.

The most notable Inbox Providers affected by this are Apple and Microsoft. FeedMail uses AWS SES for these providers as they reject all messages from our network provider. However other smaller providers may also have a portion of their messages sent via AWS SES. 

What to do if you are affected?

If you are affected the best option is to add a rule to ensure that messages from are not set to spam. The process for doing this depends on your email provider.

If you have other concerns please contact FeedMail Support.

Technical Description


FeedMail uses DKIM to apply a digital signature to outgoing email. This allows users who receive the email to know that the message is from FeedMail (not an impersonator) and hasn't been altered.

FeedMail uses a multi-pronged approach to delivering email. We have a "direct send" approach that we use for inbox providers that we have built a good reputation with. These providers trust and accept our email reliably. So FeedMail directly connects and delivers email to these providers. This provides maximum privacy, performance, control and lowest cost. However some email providers are much pickier. Most commonly they have blacklisted our IP range and reject every email even though it is coming from In order to resolve this issue we proxy these messages via AWS SES. This allows us to use an IP address with a higher reputation for a small fee. The problem exists with these proxied emails.

Header Munging

The problem appears to be around a single header. FeedMail sends the following header in our outgoing messages:

Reply-To: "FeedMail Support" <>

AWS SES has recently started changing this to:

Reply-To: FeedMail Support <>

While this change is semantically unimportant it is enough to break our DKIM signature. Since the message has been altered it does not validate and can't be confirmed as coming from us.

Who is at fault?

We believe that AWS SES is behaving wrongly here. Their documentation clearly states which headers may be altered by SES and therefore can't be signed. Reply-To is not on their list so altering it is breaking their contract of preserving the DKIM signature.

Possible Solutions

The simplest workaround would be to skip signing the Reply-To header. However since this header may be used by users to contact support it could be a valuable phishing vector. So it would be best not to skip signing this header. However if SES remains broken we may need to stop signing it.

Another possible workaround is to try to match SES's format in hopes that they don't alter it if it is already in that format. this is possible but would require altering the libraries that we use to generate the email messages and would open up a game of chasing SES's header encoding format.

One last option is moving off of SES. This is a difficult option because SES is very inexpensive and pay-as-you-go. This is important to FeedMail as we only send a small volume of mail via SES and minimum monthly feeds would blow our budget. We aim to be low cost so keeping our mail sending cheap is important. Furthermore SES is one of the few providers that allow us to sign our messages before submission. This improves security by not allowing them to impersonate us with our DKIM key. Other than this bug they have been a very good provider and we would prefer not to have to move off. However we have experimented with various providers in the past and it is very easy for us to switch. So if necessary we will find an alternate provider.

What we are doing to resolve this issue?

Unfortunately AWS has no unpaid support, even for bugs in their services. We have tried to make them aware of this issue but lack any official channels to do so.

If there is no movement on their side we will explore some solutions that can be done from our side as described in the above section.


Popular posts from this blog

Delivery Delays to Gmail

In the past 48 hours Google has started delaying the delivery of some FeedMail notifications. This is currently affecting about 10% of messages to Gmail users. These notifications will be resent with a delay. We also speculate that some notifications will be marked as spam.   Update : As of 2023-05-09 this appears to be resolved. If You Are Affected If you use Gmail you may be affected by this. Notifications may be delayed or marked as spam. If your notifications are marked as spam you can create a filter to avoid this. Use "from:*" as the rule and select " Never send it to Spam". If your notifications are delayed we are unaware of any action that you can take. However marking notifications that ended up in your spam folder as "Not Spam" may help avoid future delays.  It does appear that these emails are eventually being accepted but we are unsure if that means that they are actually ending up in users' mailboxes (or even their spam folder

No body notification option.

Previously FeedMail provided two options for notification bodies: Content from the feed. Attempt to scrape content from the linked website. A third option is now available which includes no content in notifications. This can be useful to reduce email size or if you prefer reading articles in your browser anyways. This option is especially useful for digests. By setting subscriptions in a digest to "No Content" you can get a headlines-only digest. Or you can keep content for some short content like micro blogging but just get headlines for news sources with longer articles. Simply go to your subscription management page to change this setting. You can find a link at the bottom of each email notification.

Digests Leave Beta

Thanks everyone who has helped evaluate digests over the past weeks. All of the blocking issues are now resolved and we will be releasing them soon. Once digests are officially released there will be links to them from the FeedMail site and pricing information added to our homepage. Price Increase Part of the purpose of the beta was to evaluate the cost of providing digests and see how they would be used. We have decided upon final pricing which we hope will be sustainable for years to come. Digests issues will cost 1 credit per 5 feeds. Note that this is feeds included in an issue , not total feeds that target a particular digest. It also does not matter how many new items a feed has. So if you have a digest with 200 feeds configured but this morning's issue only has new items from 2 of them it will cost 1 credit. If 14 feeds update the next day that issue will cost 3 credits. If the day after has no updates it will cost nothing. This new pricing takes effect no earlier than 202