Gmail introduces a pilot feedback loop offering
Back in February, Gmail announced their Feedback Loop (FBL) pilot offering to ESPs to help them with identifying bad actors and spammers on their network. For anyone who is interested in learning more, the enrollment form can be found here.
For those of you who are unfamiliar with the process, here’s a brief recap. Feedback loops are essentially reports that ISPs provide to large volume senders about the number of recipients who mark their mails as spam. It’s a really important service that allows businesses to monitor their sender reputation with the ISPs and quickly take action for damage control if large numbers of recipients are marking their emails as spam. As you can already tell, this is pretty crucial for businesses that are dependent on email marketing as a main revenue stream.
Gmail’s feedback loop, however, differs from other ISPs
Gmail’s FBL is not in ARF format. In order to protect user privacy, their FBL is offered in the form of aggregated spam statistics per customer or per campaign, which cannot be traced back to the email address of the recipient who marked the mail as spam. This daily report provides a percentage of user spam complaint rate per customer and/or campaign of an ESP, and will be sent to the designated email address provided to Gmail by the ESP (eg: GmailFBL@example.com). The service is not designed for list management or delivery evaluation, and if there is a sizable percentage of spam in your traffic, you will receive the aggregated report the next day.
ESPs are highly encouraged to comply with Gmail Bulk Senders guidelines. Gmail requires all senders to use a consistent IP address to send mail, valid RDNS record for all sending IP addresses, and the same address in the ‘From:’ header on every bulk mail. As far as authentication, they highly recommend signing with DKIM, publishing an SPF record and adhering to the DMARC policy.
How does Gmail’s feedback loop work?
ESPs will first need to insert a feedback identifier header “Feedback-ID”. This header will identify the customer and or campaigns, mailings, and mail types. FBL reports will be generated based on these identifiers.
The “Feedback-ID” header will have a maximum of 4 fields, 3 are optional.
“Feedback-ID: a:b:c:ESPid”
“Feedback-ID” is the name of the header
“a:b:c” are the optional 3 fields which can be anything the ESP chooses (ie: campaign, mailing, traffic type)
“ESPid” is the only required field. This ID corresponds to an ESP customer and must be unique and persistent to that customer.
Gmail will aggregate data for the last 4 fields starting from the right side and ignore any extra fields. The data returned in the feedback report will be aggregated by the tag seen in the Feedback-ID header. Every tag will be included in the report and there are no limits on the number of total tags specified. However, Gmail will ignore tags with too few messages to prevent abuse.
FBL data will be aggregated by way of each identifier independently and not grouped across identifiers. Spam percentages will be reported across all the mails containing a given identifier, irrespective of the position in the identifier header. The FBL report will be sent in the form of a CSV attachment and contains data received by Gmail on the previous day by the ESP. This report is intended for gmail.com users and doesn’t support Google-Apps or Google hosted domains.
What are the DKIM requirements?
To prevent spoofing of the “Feedback-ID” header the ESP must strip any instances of this header first before inserting it and then DKIM sign it with the ESP’s domain key. This is in addition to any existing signature and is a practice commonly known as “double signing”.
There may only be up to 10 unique DKIM “d=” signing domains used to sign these headers but subdomains may be used as an alternative.
As far as DKIM key length is concerned, Gmail requires a minimum 1024-bit long key. According to the Gmail postmaster site, Gmail has been treating all emails signed with less than 1024-bit keys as unsigned since January 2013. They recommend affected senders with short keys to switch to RSA keys that are at least 1024-bits long.
How can we correctly implement Gmail’s FBL requirements in Momentum?
Multiple signatures are supported in the Momentum platform using Lua policy. OpenDKIM is now the preferred signing module in Momentum versions 3.6.0 and newer. More information about the Lua libraries for signing can be found in our documentation.
We’ve also created a simple OpenDKIM signing Lua policy that easily configures a second signing domain. You can find more info about that here.
Which Other ISPs Provide Feedback Loops?
If you’re looking for more information on how feedback loops operate, do refer to the “Complaint Feedback Loop Operational Recommendations” RFC 6449 document. And while we’re talking feedback loops, it would make sense to share links to the other trusted FBL providers out there, in case you didn’t have them already.
Earthlink (email only): fblrequest@abuse.earthlink.net
Gmail (beta, for select ESPs only, sends aggregate reports for privacy reasons (not ARF)
IBM Smart Cloud (email only) postmaster@lotuslive.com
Rackspace (formerly Mailtrust)
Yahoo! (requires DomainKeys or DKIM and its is the only Domain-Based FBL provider)
Now, to sum up: it’s great news that Google now provides an FBL. It has some quirks and senders will need to do some configuration to get it to work for them. But for Momentum users, that will be a straightforward process. If any readers would like to share their experience with the new Google FBL, we’d love to hear your story. Feel free to leave feedback in the comments.