Still only two guesses at the puzzle? Ah well. Here’s the answer...
Let's back into it by looking at the DMARC record first. As @cougrimes picked up in the comments, the record in use is at the parent brainteaser.com because there is no DMARC for the true author domain reply.brainteaser.com. This fallback (or “fall-upward”) logic is built into DMARC and is not an inherent problem.
_dmarc.brainteaser.com. 300 IN TXT "v=DMARC1; p=none; fo=1; pct=100;
rf=afrf; rua=mailto:brainteaser@rua.agari.com,mailto:abuse@brainteaser.com;
ruf=mailto:brainteaser@ruf.agari.com"
In English, this record means (leaving out the notification addresses, which aren't important) that if any of the following is true, the email passes DMARC:
- The domain in the From: exactly matches the SMTP MAIL FROM: domain, and the email has an SPF PASS result.
- The domain in the From: is a subdomain of the SMTP MAIL FROM: domain, and the email has an SPF PASS result.
- The domain in the From: exactly matches one of the domains that signed the email using DKIM, and that DKIM signature is valid.
- The domain in the From: is a subdomain of one of one of the domains that signed the email, and that DKIM signature is valid.
Note 2 and 4. When subdomain matches are allowed, that's called relaxed Identifier Alignment mode (“mode” means “requirement”) as opposed to strict mode.
Why is relaxed the effective policy? Because when either aspf= or adkim= is left off, the default is to treat them as aspf=r or adkim=r. That is, there is no such thing as truly omitting either the SPF or DKIM policy. You either explicitly state r or s, or the default r is used. If you aren't comfortable with that, you aren't supposed to publish DMARC!
So far, so loose. It looks like the relaxed mode gives us more room to play. Let's look at SPF first.
The SPF side
The email does have an SPF PASS result…
… but look at the SMTP (envelope) domain: it's {foo}.{bar}.{baz}.mktomail.com. That's not a parent match nor an exact match on the From: domain of reply.brainteaser.com. (Remember how I always mention that most Marketo customers have no need for mktomail.com in their SPF records.)
So even though the email passes SPF, it doesn't pass SPF in a way that is relevant for DMARC, which is strategically focused on authenticating the domain of the From: address.
The DKIM side
The email also has a DKIM PASS result…
… but again, look at the domain that signed the email: mktdns.com, Marketo's internal fallback DKIM key. That's neither a parent nor an exact match on reply.brainteaser.com.
Not fake, but not real enough for DMARC
This ripped-from-the-headlines example lets you see exactly why DMARC is so powerful as a method of authentication, non-repudiation, and reputation protection.
There's nothing that proves the person using Marketo to send this email was allowed to use the domain reply.brainteaser.com, It could've been sent by any Marketo instance — a competitor trying to sabotage your reputation, or a company-owned instance that isn't supposed to be using reply.brainteaser.com. So Gmail is right to call it a DMARC FAIL. Were the DMARC record actually enforcing p=reject, the email would be totally rejected. Since it's using p=none for testing, the message is accepted right now, but logs a fittingly stern warning.
Questions? Hit me in the comments.