DMARC is a protocol that makes it very, very simple to shoot yourself in the foot. Setup is tricky and if you don’t get it exactly right you risk creating deliverability problems. The vast majority of companies SHOULD NOT publish a DMARC policy with p=reject or p=quarantine for their existing domains.
DMARC policy statements are, essentially, a way for a company to assert the following things are true:
- They know exactly where every legitimate piece of email they send comes from.
- They have authenticated every legitimate piece of email in a very specific set of ways.
- They are sure that any email not authenticated in those very specific ways is not legitimate and should be thrown away.
Typically, these things are hard to get right. And even when you get #1 and #2 perfectly correct there will be other mail servers handling the mail that can break authentication in ways that cause DMARC to fail. Thus, all DMARC policy statements other than p=none will result in delivery failures for legitimate email.
There are some cases where, with a little time and energy, it’s possible to get everything right. The obvious one is when you’re spinning up a brand new domain used for just one type of email. With a little bit of time, understanding, and care it’s possible to correctly authenticate every piece of email sent regarding that domain. Sure, there will still be a few delivery failures due to forwarding or other modifications after the mail leaves your server, but overall all mail sent is correctly authenticated.
In most cases, though, companies don’t start with a brand new domain. They try and shoehorn DMARC authentication into an existing company. This is where things get really tricky.
For instance, here at WttW we have a company where everyone is an expert in the field of email. We know where all our mail comes from, right? It all comes out the SMTP server we maintain. Well, except for the stuff that goes out of Mailchimp. Oh, and the mail that goes out of Hubspot. Don’t forget the Google calendar invites. Wait, we send some reminders from Asana. And the system update emails that come out of our various monitoring boxes. What about the various email discussion lists we participate on. And the invoices we send out through various services. Also the receipts from credit card processing.
Are all those emails authenticated? Yup. They absolutely are. Are all of the emails authenticated in the special ways that would allow us to publish a DMARC policy statement? No. Can they be? Absolutely not.
DMARC breaks the way many people and companies use email. Some of this breakage can be worked around, although in ways that make some things harder. Some simply cannot be worked around and publishing any policy other than p=none means that some mail will be put in the spam folder or rejected.
This doesn’t mean no one should use DMARC. There are some use cases where it makes a lot of sense. In those cases the cost of fraudulent emails is high enough that losing a few legitimate emails is an acceptable cost. DMARC policy statements aren’t for every domain. And if you’re starting a mail program on a new domain from scratch, you can make engineering and provider choices that make DMARC authentication possible.
To me the real value of DMARC is actually the reporting piece. This allows companies to see what mainstreams they actually have and how they’re being authenticated. There is also some value for heavily phished domains. But, as I’ve said in the past, most phishing is using cousin domains and DMARC doesn’t address cousin domain phishing at all.
All of this is a long way of saying that DMARC policy statements of p=reject and p=quarantine will hurt your deliverability and result in lost email. For a small fraction of companies the benefit outweighs the problems of lost mail. For most companies, however, p=none is sufficient to get the benefits with few of the downsides.
Still not convinced and want to go forward with DMARC? My best bit of advice is don’t do it yourself. Use one of the DMARC consulting companies so they can help you through the process.
This morning I woke up to a job offer. I hear a number of other email deliverability folks received the same job offer.
I am writing to you from [Company]. We are one of the oldest and best reputed partners for Salesforce. We have succeeded because we only hire the best, most experienced developers. We have a need for an excellent expert in deliverability. We have been watching you for years via social media and we feel that you are proven and match this profile. If you are satisfied where you are, then we apologize for bothering you, however if you welcome the challenge of being stretched by working with the best and brightest in the world, we want to talk to you.
Most of our developers work remotely from their home. We have complete centralized support for you, you will be expected to concentrate on helping customers solve their deliverability problems and you will be working with the largest corporations and with growing small and medium size businesses. This is a fulltime position with full benefits.
We are interested in you, and we would like to discuss the position with you so that we may proceed. Please just reply to this email and let me know your preferred method of communication. We have multiple open positions, so please share this invite with others you feel are qualified.
I know a lot more about this particular position than is conveyed in the email. See, last week I spoke to Company. They were looking for some help with deliverability. Not, of course, the kind of deliverability I do they have all the expertise they need in high level strategy. Instead, they wanted someone to run Salesforce reports and … something? It was never that clear what they were expecting to do with the Salesforce reports as they didn’t need advice or assistance.
The email itself links to a website and a blog site. If I click on the blog site gives me a default CPanel “this website is horribly misconfigured” error page. If I go to their website and click “blog” it shows me a blog that’s not been updated since Dreamforce 2017.
I share this so that my deliverability colleagues are aware that this company is scraping and sending out mail without even checking basics like “did we contact this person already?”
I’m also a little concerned about the offer of full time remote work. Given how this position was pitched to me last week and how it’s being pitched in the email, I’m really unsure this is a legitimate offer. It also looks like it is, potentially, a bad cut and paste of a job offering a different position. Of all the things I’ve heard deliverability folks called “developer” is not on the list.
Just be careful out there.
A question came up on the email geeks slack channel about empty from addresses. I asked if they meant the 5321 or 5322 from address which prompted a question about if you could even have a null 5321 from.
Yes, you can and it’s commonly used for some types of email.
5321.from is the bounce address, and the domain used in SPF authentication. Null addresses, literally <>, are used for email where it’s not important to know if it wasn’t delivered. If the mail fails to deliver it usually is just dropped on the floor and no one ever knows anything.
If the 5321.from is the SPF domain and there is an entire class of email that doesn’t have a 5321.from, what do we do about SPF? Never fear, the SPF spec addresses that. When the message has a null from address, the domain in the HELO is checked for a SPF record.
I’ve seen a bunch of folks in different places looking for advice on what to do when they can’t get a response from a postmaster team, or a filtering company. I was all set to write yet another post about how silence is an answer. Digging through the archives, though, I see I’ve written about this twice already in the last 18 months.
Well. OK then. Instead of retreading, I’ll write about the 4 things you can do when you can’t get a response about a delivery problem. (It’s been the kind of day where I want to sprinkle joke advice in through this list, but the responsible, adult side of me says that if I want to make jokes I need to do it elsewhere. Thus, you get real suggestions. I’m sure I’ll forget to change X to whatever number I end up writing. Have I mentioned it’s been a day?)
You can’t figure out why your mail is being blocked and no one will answer your mail. Where do you start?
- Figure out what you’ve been sending and TO WHOM. Not just your bulk mail, but also the “cold outreach” mail your sales team has decided to send. Also, pay attention to third parties you’ve hired to send mail on your behalf. Finally, make sure that you don’t have any rogue sales folks inside your organization who decided that they didn’t need to pay attention to permission.
- Figure out where your addresses are from. Email marketing has been a thing for 2 decades now. But that doesn’t mean you should be sending mail to all those addresses. Yes, even if they opted in with a cherry on top. People don’t opt-in and expect to hear from you for ever and ever and ever again. What’s the perfect time to let a subscriber grow? You know your audience better than I do, and you are the ones who can best answer the question about when to let folks go. But, you do need to remove dead and unengaged addresses from your list. They just pollute it and contribute to delivery problems longer term.
- Clean your list. No, you don’t need to pay some hack company who, tells you they can remove spamtraps for the low, low price of 9999.99 and sending all your addresses to them so they can harvest the data and sell it on to other people. Look at your data, look at your subscriber interactions and think about what addresses it makes sense to say good bye to. You can even have a ceremony. Tip one out at the pub after work. Write a few on a piece of paper and burn it. Whatever. Just make the data better.
- Commit to improving the quality of your mail. Embrace the idea that email is a relationship rather than a broadcast channel. (As an aside, I find it hysterically funny how many email marketers clutch their pearls when someone calls it an “email blast” but always have an excuse about why they don’t have the time or resources or management backing to do anything to segment their lists.
- Actually improve the quality of your mail. Really. Send the mail people have opted into receive. Let them do the work to tell the ISPs that this is mail they want. It’s a little harder when your mail is hard blocked, but even then GIVE IT A REST. Just stop sending mail to that domain for a while. Most places of any size have some sort of automated block management in place. Let the block expire and then try again. Slowly. Carefully. And with email addresses you are 100% sure actually asked for the mail (hint: these aren’t addresses you collected off a web form or at a checkout counter).
One of the most important pieces of advice I can give, though, is pay attention. Don’t let things get to a block. Many of the mailbox providers have told me directly that mail going to the bulk folder is a negative reputation hit. Even if they made the decision to put it in there, it hurts your reputation to continue sending mail to bulk.
That gradual decrease in inboxing over time is a sign that something is going wrong. It is so, so SO much easier to fix problems when they’re little then trying to deal with delivery problems that has been building up over the last 18 months.
At the same time, though, you don’t need to jump on every slight decrease in opens or inboxing. If it’s one or two days of bad data, just keep an eye on things. Don’t start changing everything, sometimes the mailbox providers just have a bad day. Like Hotmail. Last week. See:
A bunch of marketers saw the dip, spent a lot of time trying to troubleshoot it, only to discover it was something inside Microsoft that resolved itself the next day.
Today’s advice in a nutshell: you don’t need someone to tell you how to troubleshoot things, the power was inside you the whole time. You just had to learn it for yourself.
Back in July the Tulsi Gabbard campaign sued Google for deactivating their “advertising account” on the night of the first Democratic debate. I’ve been waiting for the Google response, which was due to be filed today.
I checked today and found a new filing. Apparently counsel for both sides got together recently and decided that Tulsi’s campaign was going to submit an amended complaint and so Google could hold off any answer until that had happened.
We can expect a first amended complaint consisting of a single claim for violation of the first amendment by September 27, at the latest and then Google has until October 18 to respond.
If you’re interested in seeing the court document, most of the interesting ones are available through the Court Listener website: https://www.courtlistener.com/docket/15967487/tulsi-now-inc-v-google-llc/. I’m adding any docs I purchase there (as are other folks, I’ve not bought all of them) so you should be able to follow along, at least until any email related counts are dropped.
Speaking of email related court cases, I spent more than a few hours yesterday going down the rabbit hole of United States v. Bychak. This was brought to my attention by Brian Krebs and some friends on Facebook. Brian’s article is well worth a read as it details some of the things that spammers do in order to get around IP based blocking.
I’ll write a little more about what they did and how this kind of IP based hijacking was funded by many large international companies.
Yahoo seems to be having some massive system issues the last 24 hours or so. DNS has been down, mail was down. I’m seeing reports things are coming back now, but there’s a lot of backed up mail traffic and the congestion may take a few hours to resolve.
If you have the ability to do traffic shaping on the sending end, now would be a good time to be extra conservative in your sending to Yahoo. After 7 hours, there’s a lot of volume that will be trying to hit their servers all at once. Ratcheting down connections to single digits will free up resources for the other emailers that are trying to get in. Globally, backups are likely to clear faster if folks send slower for the first couple hours.
According to CNN the problem started in Europe. There’s probably a Brexit joke in here somewhere…. but I don’t think I can compete with the real pundits.
One of the ongoing arguments in deliverability is whether or not to use no-reply in the From address of email marketing. There are very strong opinions on both sides. I’ve even had people ask me to comment or ask me to back up their particular point of view.
My point of view is pretty simple. This is a customer relationship issue not a delivery issue. The presence of a no-reply@ address in the From: address has no effect on deliverability. There are too many giant brands getting great delivery using no-reply to think that it’s a problem.
Thus it amuses me when folks try and get me to agree with them that no-reply is the Worst. Practice. Ever. and will terminally break your email delivery. It doesn’t and it won’t.
There is one piece that I will relentlessly mock companies for. Putting in a reply-to: address that is no-reply@company. Reply-To is not a required header and if you don’t want replies, then don’t add it. Putting in a no-reply@ address as a reply-to address is a sign a company doesn’t understand email and is just cargo culting their way to the inbox.
Over the last few weeks I’ve had a lot of discussions with folks about DMARC and the very slow adoption. A big upsurge and multiple Facebook discussions were triggered by the ZDNet article DMARCs abysmal adoption explains why email spoofing is still a thing.
There are a lot of reasons DMARC’s adoption has been slow, and I’m working on a more comprehensive discussion. But one of the absolute biggest reasons is that it doesn’t actually fix phishing.
One of the first adopters of DMARC is PayPal. But being an early adopter and publishing a p=reject for years and years has not actually stopped the bad guys from sending PayPal phishes. Here’s an example of one I received recently.
The message clearly shows it’s from PayPal. The sending domain is authenticated with SPF. The SPF domain and the 5322.from domain align. The message is DMARC authenticated.
No, the domain in the From: address isn’t @paypal.com, but that doesn’t matter because a huge number of mail clients, including Gmail, Hotmail, Apple Mail, and Outlook hide the actual email address from the user. All it displays is the so-called friendly from.
The people who think DMARC should be a requirement for email will tell you that this is not the problem space DMARC is supposed to fix. That DMARC is solely intended to fix direct domain spoofing. This is true, DMARC is not intended to fix this type of phishing.
I actually put a lot of blame at the feet of mail client developers. I don’t know who thought it was a good idea to hide the 5322.from address from the user, but they were wrong. To my mind it’s a bad user experience and makes recipients more vulnerable to falling for phishing schemes.
I understand that DMARC isn’t intended to fix this type of phishing. But the fact that it doesn’t fix this type of phishing makes it a whole lot less useful as an anti-phishing product. The tiny scope of DMARC and the expense of implementing it is one of the primary reasons it’s not more widely deployed.
The interesting bit, though, is even without widespread deployment, phishers have changed their attacks. We can declare DMARC a success at stopping direct domain phishing, even though there’s a less than 25% adoption rate. The phishers have moved on. Now, maybe we should look at other ways to address the phishing problem, one that encompasses the majority of attack vectors, rather than a very narrow one.
A few days ago Cox disabled email address account creation for their domain.
In recent years, fewer customers have taken advantage of a Cox Email account, so we decided to modify our email service to better serve our customers. As of August 15, 2019, Cox no longer offers the ability for new and existing Cox Internet customers to create new Cox Email accounts.
Customers with Cox Email accounts created prior to August 15, 2019, will continue to receive support for those email accounts. Cox Email Creation Policy
This doesn’t surprise me. In the work I do for clients I’m seeing fewer and fewer @cox.net email addresses in their lists.
Let’s face it, consumer email is hard and expensive to do well. Filters are tough to get right and the incoming threats are always changing. The free mailbox providers spend a lot of resources developing and maintaining services.
On the consumer end, there’s not a lot to like about an email address tied to your broadband provider. Move out of the providers’ area, and you lose access to that email address. Having an email address that is independent of your internet access means you can move across the country or across the world and still have the same address.
For senders, this shouldn’t change much about how you’re managing email address. It does mean that you can expect the number of cox.net addresses to slowly decrease over time, probably eventually falling to zero.
A few ISPs use the d= value in the DKIM signature as a way to provide FBL and reputation data to senders. This has some good bits, in that senders can get FBLs and other information regardless of the IP address they’re using and whether or not they have sole access to it.
There are also some challenges with using the d= as a data identifier. One of them is that ESPs may not be able to get a full picture of what their overall customer base is doing if their customers are signing with their own d= value.
Some ESPs have solved this by adding two DKIM signatures to the email. The first signature is with their own d= value, one that is shared across all their customers. The second is with the individual d= for that particular customer.
There are a couple questions that regularly come up when I discuss double DKIM signing with folks. One of them is how much weight is given to the shared DKIM signature? There is some, but if the domains are signed in the correct order, the ESP domain seems to fade into the background of reputation.
Another question of the questions related to double DKIM signing is will signing twice reveal information about the sending infrastructure to the receivers or the end users. The answer to this is not in the vast majority of cases. Most ESPs provide IP addresses for their customers to use. These IPs are identified as belonging to the ESP and ownership can be determined using standard tools. While many end users probably may not be able to easily figure out who the ESP is experts and ISPs can.
But what happens for ESPs that use one of the API based providers? For instance, an ESP that uses Sendgrid or Amazon SES may want to allow customers to sign with their own d= but also monitor all their customers. In this case, they should be able to sign with their own shared d= before handing the message off to the ESP. The ESP can then sign with their own key and then, finally, sign with the customer specific key.
There is theoretically no limit to the number of DKIM signatures you can add to a message. You just need to be careful about which of the headers you sign, to avoid having them altered during future steps. Of course in practice there are unlikely to be cases where quadruple DKIM signing is necessary. But I say that now and someone will point out a case where it makes sense.
In any case, there are no technical reasons to limit DKIM signatures to one or two. This is very helpful for those cases where DKIM is being used in ways unrelated to reputation.