A request email is the one that says somebody wants to get tattooed by you. It's the one email from Cake you most need to see.

What we checked first

First, whether our mail can prove it came from us. Mail providers look for three DNS records on a sending domain, and we read every one of ours back:

• SPF on send.cake.ink, send.updates.cake.ink and send.reply.cake.ink, each naming Amazon SES, which carries our mail for Resend, our email provider.
• A DKIM key, resend._domainkey, on the same three.
• DMARC on cake.ink and updates.cake.ink, set to p=none: receivers report what fails and block nothing.

Every record was where it should be.

Who sends what

Each kind of mail leaves from its own address, so a Gmail filter can pick out exactly one of them:

• New request alerts come from no-reply@cake.ink, named "Cake" in your inbox.
• Sign-in codes come from login@cake.ink.
• News for the waitlist comes from hello@updates.cake.ink, on a domain of its own.

A request alert's subject starts with "New tattoo request", then the project, then the person who sent it.

What a test showed, and what it can't

Micah sent a request through a test artist account nobody had used before. The confirmation the client gets landed in Updates, the tab Gmail says it uses for automated confirmations and notifications.¹

That test followed the client's confirmation, which leaves from reply.cake.ink. Your request alert leaves from no-reply@cake.ink and goes to you, so the test says nothing about why it went to Promotions.

Why nobody can name the cause

Gmail doesn't say why it files an email under a tab, and the headers on a delivered email don't say either. Google's Postmaster Tools reports on a sender's reputation and authentication, and it has no view of Primary against Promotions.² Resend can tell us an email was delivered. It can't tell us which tab it landed in.³

The advice about a magic ratio of text to images has no source we could find. So we're not promising Primary, and we'd be wary of anyone who does.

Where each piece stands

• LiveSPF and DKIM on all three sending domains, and DMARC on cake.ink and updates.cake.ink.
• LiveSeparate addresses for request alerts, sign-in codes and waitlist news.
• In sourceOur email templates include a plain-text version and only a few links. We haven't checked a delivered copy yet.
• PlannedReplies about one request stay in one conversation in your client's inbox. That's for your clients' mail. It doesn't touch your request alerts.
• Not decidedTest inboxes that show where alerts land before and after a change, and a stricter DMARC setting. We haven't decided on either, and we have no measurements to share.

The part Gmail leaves to you

Gmail learns how each inbox likes its mail sorted. Two settings work today, and a third might help:¹⁴

1. Move one Cake request email from Promotions to Primary.
2. Make a filter for mail from no-reply@cake.ink and set Categorize as Primary.
3. Add no-reply@cake.ink to your contacts too. It might help, and Google makes no promise that it will.

If a request alert lands in Promotions after that, email support@cake.ink and tell us when it arrived. We still haven't seen the full source of an affected email, and that's the piece we're missing.

Sources

1. Organize your inbox, Gmail Help
2. Postmaster Tools dashboards, Gmail Help
3. What if an email says delivered but the recipient has not received it?, Resend
4. Create rules to filter your emails, Gmail Help