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?

  1. Make sure that every bit of mail you send is sent with both valid SPF and a valid DKIM signature for the domain you use in the From address, so both are DMARC-aligned
  2. Use “relaxed/relaxed” canonicalization (not “relaxed” canonicalization, as that’s quite different).
  3. Don’t do anything “clever” with your SPF or DKIM configuration. Use simple configuration that’s likely to be well understood by recipients. Very simple.
  4. DKIM sign a minimal subset of headers – e.g. “h=From:Subject:Date”. Definitely don’t sign Reply-To:, To: or Message-ID: headers, as they’re the most likely to be modified during forwarding. (From: is also likely to be modified – but if it is, it’s no longer going to trigger your DMARC policy so you don’t care).
  5. If you’re generating bulk email, make sure that it’s not only entirely valid but that there’s nothing in the structure of the email that might trigger an intermediate server to rewrite it. Make sure that the headers aren’t excessively long, and are wrapped in a normal manner. Make sure that the mail doesn’t have any long lines in it (quoted-printable encoding is a good way to ensure that). Make sure there aren’t any non-ascii characters in the headers or body; that everything is encoded appropriately.
  6. If possible, consider separating your mailstreams. Put all your supposedly “security critical” email on a DMARC p=reject domain, and offload your mail that’s not likely to be impersonated onto it’s own domain, one that isn’t covered by the DMARC p=reject diktat. Do everything right on that new domain, make sure it’s all sent cleanly and with DMARC-aligned authentication … just don’t publish a DMARC p=reject record for it.
  7. Monitor how DMARC is affecting your mail. Make sure you’re receiving all the aggregate and forensic reports you can, and also that your postmaster and customer support teams notify you of any issue that looks at all like mail going missing (or being rejected, or going to a spam folder – as some mailbox providers won’t follow recommended practice for DMARC failures and will route the mail to a spam folder instead).
  8. Monitor things for as long as you can with your DMARC set to p=none, and fix as much as you can identify via DMARC forensic reports before switching it to p=reject.
  9. Track where mail that’s being impacted is being delivered to. If there’s low hanging fruit, maybe reach out to the forwarder and work with them to fix things so that their forwarding doesn’t break your DKIM signature. As a last resort, adding the forwarders IP address to your SPF record will allow DMARC to pass (at the cost of removing any pretense of DMARC protection for those recipients).


Have a relaxing picture of a forest. You’re going to need it.

Related Posts

The philosophy of DMARC

We know that legitimate email sent with valid SPF and a DKIM signature often breaks in transit.
SPF will fail any time mail is forwarded – via a mailing list, a forwarding service used by the recipient, or just ad-hoc forwarding.
DKIM will fail any time the message is modified in transit. That can be obviously visible changes, such as a mailing list tagging a subject header or adding a footer to the body. It can also be less obvious changes, such as intermediate MTAs wrapping lines that are too long, reencoding content or repackaging the message altogether – perhaps when delivering from a mailserver that is 8BITMIME compliant to one that isn’t.

(This image has absolutely nothing to do with email authentication, but searching for stock photography about email or authentication or chains or, well, pretty much anything like that leads to horribly depressing corporate imagery. So, no. Have something colourful and optimistic instead.)
As SPF and DKIM are typically used, none of this is much of a problem. A message being authenticated provides a little extra information to the receiving mailserver, and the domain attached to the authentication can be used to look up a senders reputation, giving a potential boost to the chances of the mail being sent to the inbox. If the authentication is broken, though, the mail will still be judged on it’s merits – is it coming from an IP address that’s a source of good mail, does the content look legitimate, and all the other things a spam filter looks at.
That authentication is a (potentially big) positive signal, but lack of authentication isn’t really any signal at all is why SPF and DKIM being fragile wasn’t an issue. SPF and DKIM are positive assertions – “IF this mail IS authenticated THEN IT IS from me”.
That changed when DMARC became popular, though.
DMARC allows the owner of a domain to say “We send no mail that is not authenticated, and we promise that none of that authentication will be broken in transit”. DMARC is a negative assertion – “IF this mail IS NOT authenticated THEN it IS NOT from me”. It converts the absence of a positive assertion into a negative assertion.
This isn’t the first attempt to layer a “we authenticate everything” negative assertion on top of fragile email authentication. SPF did it, with the -all flag (which is universally ignored, leaving SPF purely as a positive assertion). DomainKeys did it, with DomainKeys policy records (which you occasionally still see published, but were never really used to reject mail). DKIM did it with ADSP – which didn’t see much use either.
The reason none of them were used much is because even when senders were telling the truth about “we send no email that is not authenticated” they were always lying, to varying degrees, about “none of the authentication will be broken in transit”.
If your domain that is solely used for bulk email. If it’s never for used mail sent by human beings, not even customer support employees. If it’s a newly created domain with no legacy usage that only sends email from a very tightly controlled infrastructure. If you only send email that’s been created via a well implemented message composition pipeline that ensures the content of the is not just RFC compliant but also “well formed”, with short lines, simple widely implemented encoding, vanilla mime structure and so on. And it’s sent out via conservatively configured smarthosts that deliver directly to the end recipients MX. And if you know that the demographics of your recipients are such that the minority that are forwarding that mail elsewhere (e.g. from their Yahoo account to their Google account or via an alumni mail alias) is a small enough group that you don’t care about them…
If all of those things are true, then your domain is going to be able to deploy DMARC pretty easily and safely. If not, though, how can you tell?
That’s the place where DMARC improves over it’s predecessors. It allows you not only to publish a DMARC policy record in test mode, so it’s not actually used to filter your mail (well, mostly, but that’s a longer story) but also to ask recipients to notify you of mail that seems to be from you but which isn’t authenticated.
You can publish a “p=none” DMARC record with notification addresses in it and wait and see what happens. You’ll get notification of mail that has your domain in the From: field but which isn’t authenticated.
As a first round of action that lets you see where you’re sending email from that you didn’t know about. Sysadmin notification email. That marketing splinter group in Sasketchwan. The outsourced survey company.
Once you’ve cleaned all that up, and made sure everyone is authenticating their mail then you can look at what’s left. The next step is likely to be mistakes you’re making in authentication or message composition that’s causing some of your mail – typically depending on content, and source and recipient domain – to become unauthenticated. Clean that up, make sure all your message composition is squeaky clean, make sure employees aren’t sending mail using that domain in ways you don’t authorize (interacting with mailing list, for example).
By that point you’ll have reduced the torrent of reports you’re getting to two types. One is mail that you send that has it’s authentication broken in transit through some process you have no control over. The other type is mail that has your domain in the “From” field but which you didn’t send. Some of that may be legitimate use of your domain by your employees, such as forward-to-a-friend services, signing up for document delivery via email, third-party notification services. By deploying DMARC you are declaring all that sort of usage to be illegitimate, and you’ll need to get all your employees to stop doing it (or, at least, know that it’s going to stop working). The rest of it is likely a mix of spam and phishing mail. The spam, that’s just using your domain in random from addresses, you probably don’t care about. The phishing you do.
You’ve finally cleaned up your mail infrastructure and policies enough to gather the data you need. How much of my legitimate email will have it’s authentication broken (and hence be silently thrown away by DMARC)? And how much hostile phishing mail is targeting my users (and using the exact domain you are)?
Then you have the information you need to make an informed decision as to how badly deploying DMARC will break your legitimate use of email (after you’ve done everything you can to minimize that) and some idea of whether it will provide you any benefit, at least in the shorter term.
That testing phase, where senders can use other peoples mail infrastructure to investigate their sending practices, gradually fix any problems and finally gather some metrics is what made gave the developers of the DMARC spec confidence that it wouldn’t break things, and made it much more deployable than previous approaches to negative assertion.
On Monday, how all that optimistic reasoning went to hell, what it broke and how we’re trying to fix it.

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

Brand indicators in email

A number of companies in the email industry have been working on a way to better identify authenticated emails to users. One proposal is Brand Indicators for Message Identification (BIMI). A couple weeks ago, Agari announced a pilot program with some brands and a number of major consumer mail providers. These logos should be available in the Yahoo interface now and will be rolling out at other providers.

Read More