Who’s your Email Czar?

The gentleman with the excellent hat is Иван IV Васильевич, The Great Sovereign, Tsar and Grand Prince of all Russia, Vladimir, Moscow, Novgorod, Tsar of Kazan, Tsar of Astrakhan, Sovereign of Pskov, Grand Prince of Smolensk, Tver, Yugorsk, Perm, Vyatka, Bolgar and others, Sovereign and Grand Prince of Novgorod of the Lower Land, Chernigov, Ryazan, Polotsk, Rostov, Yaroslavl, Beloozero, Livonia, Udoria, Obdoria, Kondia and Master of all the Siberian Lands and Northern Countries.

That’s not the sort of Czar we’re talking about here, we’re talking about the more recent use of Czar to mean someone appointed with broad powers to manage a specific policy area, and a bully pulpit to advocate for that area.

No email programme is an island

In any organization bigger than the tiniest there are multiple groups sending email, for a variety of different things. Internal business email, external business email to vendors, customer support email, password resets, marketing mail, receipts, tracking notifications, bizdev, system monitoring email, all sorts of things, used and managed by different groups, often in very different parts of the company org chart.

But all those mail streams share resources and can impact each other in many, many ways.

One group trying to add SPF authentication to match their needs breaks SPF for everyone else, either by replacing an existing SPF record and deleting existing usage, or by adding a second SPF record making both of them invalid.

An email marketing group decides they want to deploy BIMI, so push for a domain-wide DMARC p=reject policy. Then a production service goes down, and the notification emails about it that are sent to the sysadmins are lost because they’re not authenticated correctly.

Central IT decides to move towards DMARC compliance, they tell everyone they know to make sure that all the mail being sent is correctly authenticated. After a couple of months they start looking at their DMARC reporting and discover a division in Sasketchewan has their own email marketing programme, and there’s a group in London running customer support email that didn’t get the memo. That shadow IT delays their DMARC launch by a couple more months.

Your B2B email marketing group is seeing significantly reduced opens and clicks, they’re not sure why. They think their email may be going to the spam folder, but they’re doing everything right and haven’t changed their behaviour. It turns out the new director of sales has encouraged their sales team to use a spammy service to send cold email to drum up more leads. That unwanted email has poisoned the reputation of their domain at enterprise spam filters and it’s now a huge and costly job to try and recover from that.

Computer says “no”

To avoid, or at least mitigate, all the different ways that email users can step on each others toes you really need someone or some group who is broadly aware of all the use of email within an organization, and who can be a single point of contact to consult about major changes and new email programmes. And who can advocate for practices that will benefit all users of email.

In a lot of corporations that group defaults to being corporate IT, specifically the person who has access to the DNS system. Mail authentication requires DNS changes, so all changes go through them. But their job is to keep the network as stable as possible, and to avoid any security issues. They’re often resistant to delegating any control of their DNS zone to third parties, whether by delegating DNS directly via CNAME or NS records, or by adding includes to SPF records. They may not have a deep understanding of the modern email ecosystem, and their job performance probably isn’t measured by anything email related beyond business email service uptime.

“IT says no.” can slow down or prevent deployment of new email programmes, discourage experimentation, and make authentication more brittle – without really improving things for existing programmes. It can encourage users to misuse existing infrastructure as that’s easier than setting up new infrastructure – “we’ll just send this mailshot through our google apps account, rather than an ESP that’ll manage bounces and unsubscribes” or “it’s too painful to set up an ESP account for marketing mail, we’ll use our transactional service for it”.

Worse, it can encourage people to run email programmes that aren’t using corporate infrastructure, using cousin domains.

That’s really bad.

You need an Email Czar

The ideal Email Czar would understand the modern email landscape, how outsourcing service to ESPs works and how it can work better. They’d be intimately familiar with how email authentication and reputation work. They would know all the broad email flows within the organization. They’d know the history and politics of those programmes, and the people involved.

They’d focus on the organizations short and longer term goals, and how good and creative use of email could drive those. They’d be able to connect someone wanting to try something new with email to someone else who’s already doing it. But they’d also be aware of how much damage poor use of email could do to an organization, and diplomatically push back or redirect bad ideas – or, if not, at least ensure senior management is aware of the risks and the tradeoffs.

They’d advocate for positive, productive and profitable use of email within the organization, and recognition for those who are making that happen.

Doesn’t that sound like a great job? And aren’t many of those skills those the ones that you’re honing in a senior email deliverability position?

Next time you’re discussing career progression within the email space with your management, see if you can make this happen.