Explore How Online Game Studios Send Messages to Players

A few years ago a friend who works at a small game studio called me on the morning of their first big update. Players were logging in, the servers were fine, the patch was fine, and yet support had 600 tickets before lunch. Almost all of them said the same thing: the two factor code never arrived. The game was working. The mail was not.

I have run mail servers since the late 1990s, back when I edited DNS zone files by hand and prayed I had remembered to bump the serial number. Game studios are an interesting case because they send nearly every kind of message an online business can send, often from the same small team, and players notice instantly when one kind breaks.

The channels a studio actually uses

When people say a game "messages" its players, they usually mean several separate systems that happen to share a logo:

• Transactional email. Account verification, password resets, login codes, purchase receipts and refund confirmations. These are triggered by something the player just did.
• Marketing email. Season launches, sale announcements, newsletters with patch highlights. These go to large lists on a schedule.
• In game inboxes and news panels. The message board you see on the main menu of games like Destiny 2 or Genshin Impact, served by the studio's own backend.
• Push notifications on mobile games, sent through Apple and Google push services.
• Community channels such as a Discord server, a subreddit, or an official social account.

Only the first two touch real email infrastructure, but they are the two that cause the most pain, because the studio does not control the last step. Gmail, Outlook and Yahoo decide whether the message lands in the inbox.

Why the login code goes missing

The common failure in my friend's case was boring. The studio sent its password resets, login codes and its big launch newsletter all from the same domain and the same sending service. On update morning, the newsletter went out to roughly 400,000 addresses, a fair number of which were years old. Bounces climbed, a slice of recipients clicked "report spam" on a game they had forgotten about, and the receiving providers started treating everything from that domain with suspicion.

The login codes were caught in the same net. Mailbox providers judge reputation partly by domain and partly by sending IP address, and they do not much care that one message was a newsletter and the other was urgent. If it all comes from the same place, it shares the same reputation.

Your password reset email is only as trusted as the worst newsletter you have sent from the same address.

The fix is separation. Well run studios send transactional mail from one subdomain, something like account.example-game.com, and marketing from another, like news.example-game.com. Each gets its own SPF, DKIM and DMARC setup, and often its own IP pool at the email provider. When a marketing blast goes badly, the account mail keeps flowing.

The records that make it believable

I will not pretend DNS records are thrilling, but they are where most of the trust comes from. Three of them matter:

1. SPF lists which servers are allowed to send mail for the domain.
2. DKIM signs each message with a key, and publishes the public half in DNS so receivers can check the signature was not forged or altered.
3. DMARC tells receivers what to do if SPF or DKIM fails, and asks them to send reports back.

Since early 2024, Google and Yahoo have required bulk senders, roughly those sending more than 5,000 messages a day to their users, to have SPF, DKIM and DMARC in place, keep spam complaint rates low, and offer one click unsubscribe on marketing mail. A mid sized free to play game crosses that threshold in an afternoon. Studios that had ignored their DNS for years suddenly found their newsletters bouncing.

If you want the longer version of how these signals add up, I wrote a separate piece on how email deliverability works and why messages land in spam.

The advice I disagree with: "just put everything in the game"

Every time this topic comes up, someone on the team suggests skipping email entirely. Use the in game inbox, push notifications and Discord, they say, and stop fighting with Gmail.

For news and events, fair enough. The in game news panel reaches people who are already playing, and that is often the audience you want. But for anything account related, email is still the channel of last resort, precisely because it works when the game does not. If a player is locked out, they cannot read the in game inbox. If their phone is lost, push notifications go nowhere. And Discord is a third party community, not an identity system.

I have also watched studios lean on Discord announcements so heavily that a large share of their players never saw a security notice, because they had muted the server months earlier. Email is clumsy and old, but it is the one channel tied to the account itself.

How the good studios do it

From what I have seen across a handful of teams, the ones with fewer support fires share some habits:

The plain message point deserves a sentence. A login code email with a large hero image, three promotional banners and a footer full of social links looks a lot like marketing, and it also looks a lot like phishing. A short message that says who sent it, what the code is and what to do if you did not request it is better on both counts. Obi covers the phishing angle in how online game accounts stay safe from phishing emails.

Where players come in

Players are part of this system whether they like it or not. Every time someone marks a genuine patch newsletter as spam instead of unsubscribing, the studio's reputation dips a little, and the next login code becomes slightly less likely to arrive. Using the unsubscribe link is genuinely kinder to your future self.

If you run or help with a small studio or a community project, here is one task for this week. Look up your sending domain with a free DNS lookup tool and check whether SPF, DKIM and DMARC records exist at all. If DMARC is missing, publish one with a policy of "none" and a reporting address, then read the reports for a month. You will learn exactly who is sending mail in your name, and I would bet at least one of them surprises you.