Gradual DMARC Rollout

Over on twitter Alwin de Bruin corrected me on an aspect of DMARC soft rollout I’d entirely forgotten about. It’s useful, so I thought I’d write a quick post about it.

If you have a large mail stream and you want to avoid the Scary Red Flag Day when you turn on DMARC p=reject enforcement and wait for people to complain you can use the DMARC policy “pct=” tag to roll our enforcement gradually instead.

“pct=” lets you set a percentage of your mail stream, between 0 and 100, you’d like receiving ISPs to enforce your DMARC policy for. Each time the ISP receives an email claiming to be from you they’ll check to see if the mail is authenticated as coming from you, by having valid SPF or DKIM. If it’s not authenticated then the ISP will send you reports about it, if you asked them to in your DMARC record, and then they’ll randomly decide whether to enforce delivery policy based on the “pct=” value you set. With “pct=10”, they’ll enforce the policy on about 10% of the emails it might apply to. With “pct=50” they’ll enforce it on about half, and so on.

If they roll the dice and it says they shouldn’t enforce the policy on this particular email they’ll instead use the next less severe policy. For a DMARC policy record containing “p=reject; pct=10” they’ll randomly reject one in ten non-authenticated emails claiming to be from you and quarantine the remaining 90%. With “p=quarantine; pct=10” they’ll quarantine one mail in ten, and deliver the rest.

(Or that’s how they’d treat the DMARC part of their delivery decision, anyway. Other delivery policies will apply, and some will override the DMARC request. So, no, publishing a DMARC record that says “p=quarantine; pct=0” won’t get your spam to the inbox.)

So I could start rolling out DMARC like this:

“p=none“: I don’t want any DMARC enforced, but I’d like reports on every mail that isn’t authenticated.

“p=quarantine; pct=5“: I still want reports, and I’d like about 5% of non-authenticated mail to be quarantined. See if anyone complains.

“p=quarantine; pct=25“: OK, I still want reports, and quarantine a quarter of non-authenticated mail. Does anyone notice?

“p=quarantine“: I’m pretty sure everything is set up right, so quarantine anything non-authenticated claiming to be from me. And, yes, still send reports.

“p=reject; pct=5“: Maybe people are just pulling their wanted mail out of quarantine? Please reject about 5% of non-authenticated mail, and quarantine the rest. And more reports, please!

“p=reject; pct=50“: They should notice this. For each non-authenticated email flip a coin. Heads it’s rejected, tails it’s quarantined. And I’m still reading your reports.

“p=reject“: We got here eventually. Please reject any non-authenticated mail claiming to be from me. And I still like your reports.

Related Posts

People are the weakest link

All of the technical security in the world won’t fix the biggest security problem: people. Let’s face it, we are the weakest link. Adding more security doesn’t work, it only causes people to figure out ways to get around the security.

Read More

DMARC doesn't fix Phishing

Not a new thing, but a nice example just popped up in my inbox on my phone.

 
But FedEx solved their entire phishing problem when they published a strict p=reject DMARC record, right?
This didn’t come from fedex.com. It came from another domain that looks vaguely like fedex.com – what that domain is doesn’t matter, as the domain it’s sent from isn’t displayed to the user on my phone mail client. Nor is it displayed to the user by Mail.app on my desktop, unless you turn off Mail → Preferences … → Viewing → Use Smart Addresses.

That lookalike domain could pass SPF, it could be used as d= in DKIM signing, it could even be set up with DMARC p=reject. And the mail is pixel identical to real mail from fedex.com.
On my desktop client I can hover over the link and notice it looks suspicious – but it’s no more suspicious looking than a typical ESP link-tracking URL. And on mobile I don’t even get to do that.
SPF and DKIM and DMARC can temporarily inconvenience phishers to the extent that they have to change the domain they’re sending from, but it’ll have no effect on the vulnerability of most of your audience to being phished using your brand.

Read More

Minimal DMARC

The intent of DMARC is to cause emails to silently vanish.
Ideally deploying DMARC would cause all malicious email that uses your domain in the From address, but which has absolutely nothing to with you to vanish, while still allowing all email you send, including mail that was sent through third parties or forwarded, to be delivered.
For some organizations you can get really close to that ideal. If you control (and know about) all the points from which email is sent, if your recipients are individuals with normal consumer or business mailboxes, their mailbox providers don’t do internal forwarding in a way that breaks DKIM before DMARC is checked and, most importantly, if your recipients are a demographic that doesn’t do anything unusual with their email – no vanity domain forwarding, no automated forwarding to other recipients, no alumni domain forwarding, no forwarding to their “real” mailbox on another provider – then DMARC may work well. As long as you follow all the best practices during the DMARC deployment process it’ll all be fine.
What, though, if you’re not in that situation? What if your recipients have been happily forwarding the mail you send to them to internal mailing lists and alternate accounts and so on for decades? And that forwarding is the sort that’s likely to break DKIM signatures as well as break SPF? And while everyone would advise you not to deploy DMARC p=reject, or at least to roll it out very slowly and carefully with a long monitoring period where you watch what happens with p-none, you have to deploy p=reject real soon now?
What can you do that’s least likely to break things, while still letting you say “We have deployed DMARC with p=reject” with a straight face?

Read More