Last night we heard from a user that 90%+ of their Marketo emails were flagged as spam. They’d only made a minor DNS change — or rather, what they thought was a minor change!
As a rule, there’s no DNS change so minor that you shouldn’t think through the consequences. (OK, maybe changing a record’s TTL from 60 minutes to 61 minutes is minor. But other than that.)
Background: the user has two Marketo instances. One to be retired soon, one brand new. Both using the same domain for From: addresses. So their IT team added the recommended DKIM TXT record for the new instance alongside the old:
C:\>dig m1._domainkey.example.co.nz txt
;; QUESTION SECTION:
;m1._domainkey.example.co.nz. IN TXT
;; ANSWER SECTION:
m1._domainkey.example.co.nz. 3600 IN TXT "v=DKIM1;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1x/+jJo2UXtQh9cPsrK+yg/QbTnSa/h2w4NIUcDomDPDvYqd5pbUTaN2zNMZvgfJLZbxjlTWBJVCaHzy8rIomjaXrXjhKeJuT0v6zAFyRTYi6TU7Z83pT4imu9Vm0/2eKa+F8iZap2IhNWN/0YhYEljiZ36ewwzS79WkHjRQVEUp4lfpN6gq0hrh4t3gwkvKrhy+UzMvmKeIHGMOl7n1XDdN3xXY1QANiYsx6dmVok2ad/bhZqjprOsJ+HybyvDOR1/Efbi81s0xViSQmimmucZ5UB7966VZdaIFwDTDbf24XLmB35c3SEnLUF05bQG2IcCCXVUVV4Wefqnb8eKqVQIDAQAB"
m1._domainkey.example.co.nz. 900 IN TXT "v=DKIM1;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhpmTL2uWlLHJK8qcSlLsV3wvN/udA00RjbM75oH/zx2jsnaQWbp+0d/gpAJEp1eeff10t9e1OuziBYdmAa8OabNal5fo1IviY2BTEikpxC64rGSd79fNNb8spnblJLdoh7QMvXHuYO/D4w5cB890WwV8qQwnbuWD94x62tv0SvDEs+ge518TAF0f66RmSFx0/CxBUSfsHP6tYkk8egc9bGH4qKDml3CMH7GSIFDsX/VvsvlKq/evVI1mg8d/6QKVXEU+PR6WEFK1lzaP0bRWXe25vJwUz+RTX790QqB/otzcTB3h8RDjjowJP1h9A+74U/aM18p2Va/pT0+3wB3R4QIDAQAB"
;; Query time: 56 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Wed Mar 16 13:02:17 Eastern Daylight Time 2022
;; MSG SIZE rcvd: 304
Now, there’s nothing within the DNS standard that prevents you from having two TXT records at the same level of the DNS hierarchy. These are both at m1._domainkey.example.co.nz, and that itself is fine. You can have unlimited TXT records (up to the max size of a DNS response, but that’s a different matter).
If multiple TXT records weren’t allowed, you couldn’t have an SPF TXT record, which would be at example.co.nz, at the same time as any other TXT record, like those used for domain verification by various providers. Here’s a typical set of TXT RRs for a major domain:
example.com. 874 IN TXT "apple-domain-verification=bLoVnSkpJF5axxBtV2IjO596ZsL28dWkApq9Z96"
example.com. 874 IN TXT "MS=IcGCscmwlQFrGAPmmfvyigR6qay7t2rLnt5zbg"
example.com. 874 IN TXT "facebook-domain-verification=IcGCscmwlQFrGAPmmfvyigR6qay7t2rLnt5zbg"
example.com. 874 IN TXT "google-site-verification=BwyHRs0SSgYNXwLF7Y7N95lqxaBt9"
example.com. 874 IN TXT "v=spf1 include:spf1.example.com -all"Nothing wrong with that setup at all.
But here’s the thing: those TXT records all serve distinct purposes. There’s one Apple domain verifier, one Facebook verifier, one Google verifier, one SPF record. From the standpoint of the app retrieving that RRset, there aren’t any duplicates, because only one is of interest at any time.
Not so with the DKIM records for m1._domainkey.example.co.nz. Those are both designed for DKIM, as you can tell by the v=DKIM1 prefix. And more than one is not allowed. The DKIM standard notes this in Section 3.6.2.2:
TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined.
What does “results are undefined” mean?
It means you might partially get away with this incorrect setup because the standard doesn’t mandate a hard failure when there are duplicates. An app might decide that the DKIM TXT record that appears first in the list (though note the records are returned in random order, so every DNS request can have a different “first”) is the one to use.
So there would still be something to check the signature against. But that doesn’t mean signature verification would succeed! It just means there’s a way to run the verification.
In reality, between apps that immediately hard-fail verification and apps that attempt verification, but fail anyway when they choose the wrong record, your emails will fail DKIM. And that’s a major sign that they’re fraudulent.
Remember, not having a DKIM signature is infinitely better than having a bad DKIM signature. You don’t want to fail DKIM checks.
The solution
You can ask Marketo support to give you a DKIM selector other than the default m1. Then you’d have one DKIM TXT RR at m1._domainkey.example.co.nz and another at m2._domainkey.example.co.nz, not dupes.