MXToolBox deliverability report query

[evfrson]

Just ran a report from MXToolBox (by sending email to ping@tools.mxtoolbox.com) for my fastmail.com email address (fastmail.com domain) and one of the DKIM signatures is highlighted in red but I can't see any reason why it should be in the report (all other records are green as they should be).

The record is:

dkim:messagingengine.com:fm1

Maybe someone with more knowledge that I could run a report and explain please ?

thanks,

Robin

Update: something to do with DKIM Signature alignment I think but means nothing to me. Is this something Fastmail needs to look at or can it be ignored ?

[n5bb]

You can ignore that warning. It’s working correctly. Here is why you see the potential issue flagged by MXToolBox. Sorry, but this takes a while to fully explain.

When you look at the Full Deliverability Report link in the automated response email, you will see a More info link in the details under the red Dkim signature area which fails alignment. That link takes you to an explanatory page which includes this text. Please note the last sentence, which I have marked in bold:

DKIM Alignment hinges the domain in your "FROM" header matching the domain used in the DKIM signature (d=domain.com). This uses a relaxed format by default which means that a sub-domain would align as well. If this value is changed to strict in your DMARC record then the domain must match exactly.

If there are multiple DKIM signatures, only one of them must align for DKIM alignment to be valid.

Because Fastmail has many domains they support for email (including a customer’s own domain), they can’t practically purchase and maintain cryptographic security certificates for each of those domains. So they use servers at the messagingengine.com domain (and subdomains of that domain) for sending and receiving email. When someone sends you an email with a Fastmail domain address (or a personal domain hosted by Fastmail), the sending server looks up the DNS records that domain (such as fastmail.com, sent.com, etc.) and it will tell the server to direct the email to a subdomain of messagingengine.com, where Fastmail receives email. The Fastmail receiving server then looks at the envelope TO address to see which user receives that message.

When you send an email, DKIM is used to cryptographically sign the email so the receiving server can verify that someone (no proof it’s YOU) at Fastmail actually sent the headers and message body (including attachments) which is covered by the signing. The “h=…” section in the DKIM Signature shows which headers are signed. The sending domain (in this case, both fastmail.com and messagingengine.com) creates a DNS record which can be found by anyone which contains a public cryptographic key. This is used to decode the encrypted signature in the “b=…” section. I’m leaving out some details, but this process allows the receiving server to verify that the sending domain server actually sent the exact text contained in those signed headers, the message body, and the attachments.

But there are two domains involved in sending a message from Fastmail: The FROM domain (fastmail.com in this example) and the subdomain of messagingengine.com used by the sending SMTP server. This allows the receiving server to verify that not only was the message truly created by a user at the fastmail.com domain, but the email was actually transmitted from a SMTP server at a subdomain of messagingengine.com, since that domain was also signed when the message was transmitted. This is similar to snail mail where you sign your name on a mailed letter and the post office stamps it with a postmark showing that a certain post office location actually processed that letter. But the email DKIM version is much much better since both signatures can be cryptographically verified rather easily with an extremely high degree of confidence, as long as Fastmail maintains control over their public DNS records.

Since there are two DKIM signatures in messages sent by Fastmail, both appear in the MXToolBox test. The “d=…” portion of the DKIM signature shows which domain is signing that particular signature. So one signature (the one which passes fully) shows “d=fastmail.com” and the other signature (the one with the warning in red) shows “d= messagingengine.com”. So you are wondering why one passed and the other gets that warning, and this requires a little additional discussion..

DMARC is a system which is used to authenticate received messages using both the DKIM technique of signing the content of certain headers and the message body and SPF, which verifies that the message was sent by a sending SMTP server IP address specified in the DNS public records for the envelope-from domain. DMARC typically is set up so that a message is authenticated as good if either DKIM or SPF passes. The reason for this is that forwarding a message usually breaks the SPF test, since the message forwarding server usually has an IP address which doesn’t match the DNS SPF IP list. In addition, some email servers have been known to sometimes mangle the email headers or message body, which causes DKIM to fail. So allowing either DKIM or SPF to authenticate a message is thought to be a safer strategy.

DMARC specifies that the envelope-from address used by the SMTP sending server be “aligned” with the domain addresses used by SPF and DKIM, as well as the From header. This prevents a sender from spoofing a domain in the From header (which the recipient usually can see) when they are actually sending from a different domain. So you can’t send a message purporting to be from a Gmail address through a Fastmail server without breaking DMARC alignment, typically causing the message to be classified as spam.

Now back to the original question! Fastmail adds two DKIM signatures. The one for the From header domain (fastmail.com in this example) will pass alignment, but the one for messagingengine,com will fail alignment, since that domain is not used in the From header. But as noted in the highlighted MXToolBox explanation I listed earlier, only one of the DKIM signatures needs to align (match the From header domain) for DKIM and therefore DMARC to pass.

Sorry for the long explanation. The bottom line is that Fastmail is very careful about doing everything possible to prevent your outgoing message to be rejected.

Bill

[evfrson]

Thanks Bill for your amazingly detailed answer that even I could understand!
It all makes perfect sense now and it was stupid of me to question if the records were somehow wrong.
Obviously Fastmail know what they are doing (I hope).
It was also good to see that Fastmail were not on any blacklists whereas gmail and outlook were.