Email inception: analysing dev.to's own domain

Francisco Magalhães — Fri, 03 Jul 2026 18:00:19 +0000

Running my Gmail inbox through Email Detective, I noticed something was off with DEV Community: emails were failing authentication. I immediately confirmed it by opening a DEV Community email and clicking Show Original.

The report shows DMARC: FAIL on a message where SPF and DKIM both pass.

I then triggered a "Forgot password?" email in DEV Community. Here's what Gmail showed me:

So what's going on? Let's break down what SPF, DKIM, and DMARC each actually do.

Why email needs authentication

Email works like postal mail: nothing in the protocol stops you from writing someone else's name on the envelope.

As phishing and spoofing became rampant, recipient mailbox providers (Gmail, Yahoo) needed a way to tell "real mail from this domain" apart from "someone pretending to be this domain." That's where SPF, DKIM, and DMARC come in.

One thing they all have in common: each is published as a DNS record on your domain. That's how a receiving server can look up your rules and verify a message.

SPF (who's allowed to send)

Think of a letter arriving at your door. Before trusting it, you phone the company printed on the envelope and ask, "is this courier actually authorized to deliver for you?" SPF is that phone call.

An SPF record is a line in your DNS that names the servers permitted to send mail for your domain. When a message arrives, the mailbox provider looks up that list and checks whether the sending server's IP is on it.

But SPF doesn't check the From: address you see in your inbox — that's the name written inside the letter. It checks the Return-Path/MAIL FROM, the envelope return address used for bounces. In Gmail, that (sub)domain shows up as mailed-by.

Here's the SPF record on dev.to's subdomain:

em4984.dev.to  TXT  "v=spf1 ip4:168.245.25.100 -all"

Only 168.245.25.100 is allowed to send mail as em4984.dev.to; -all tells the receiver to treat anything else as a fail.

DKIM (proof it wasn't tampered with)

Picture a wax seal on that same envelope. If it's intact and matches the sender's known seal, you know nobody rewrote the letter in transit.

DKIM attaches a cryptographic signature to each message using a private/public key pair. The sender signs with a private key; the mailbox provider fetches the matching public key from DNS and verifies it. If it checks out, the message was authorized by that domain and wasn't altered in transit.

dev.to's public key lives under the s1 selector:

s1._domainkey.dev.to  TXT  "k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB...QAB"

DMARC (tying it to the name you actually see)

Here's the catch: neither SPF nor DKIM looks at the From: address your mail client shows you. So far we've only verified the envelope, not the sender written in the letter inside it.

DMARC closes that gap with alignment: it requires that a passing SPF or DKIM result matches the visible From: domain. It also tells mailbox providers what to do on failure via a policy: p=none (just monitor), p=quarantine (spam folder), p=reject (drop it).

A DMARC record is a single TXT entry at _dmarc.yourdomain.com. Here's dev.to's:

_dmarc.dev.to  TXT  "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:fb91c946140a4e15a5cb3d172f97ac81@dmarc-reports.cloudflare.net;"

p = policy, sp = subdomain policy. The reporting tags tell mailbox providers where to send feedback:

rua = aggregate reports: periodic XML summaries showing how many messages passed or failed DMARC, and from which sending sources. This is how you catch misconfigurations early. dev.to points theirs at a mailbox on Cloudflare.
ruf = forensic reports: per-message failure details. Rarely used — most domains don't request them, and most providers won't send them due to privacy concerns.

So what's missing?

dev.to's DMARC used to be fine. At some point, a second record was added, and now the record name returns two TXT entries at once:

_dmarc.dev.to →
  "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:fb91c946140a4e15a5cb3d172f97ac81@dmarc-reports.cloudflare.net;"
  "v=DMARC1; p=none;"

When a mailbox provider finds more than one DMARC record at a name, the spec (RFC 7489) tells it to stop and apply no policy at all. The domain is treated as if it had no DMARC record.

What this means

Spoofing is trivial

With no DMARC policy enforced, direct domain spoofing is back on the table: an attacker can put From: DEV Community <yo@dev.to> on a phishing email and send it from their own server. SPF and DKIM can pass for the attacker's own domain, but the From: header still says dev.to.

The only thing that ties a passing SPF/DKIM result back to the visible From: domain is DMARC alignment — and with DMARC out of action, nothing does. If DMARC were correctly configured with p=reject, the fraudulent message would simply not be delivered. But that is not the case.

To prove the point, I sent myself a spoofed email with From: DEV Community <yo@dev.to> from a server I control. It landed in my inbox — no spam folder, no warning banner, just the small "via" label Gmail shows next to the sender.

Legitimate mail may get flagged

Back to the 'Forgot password?' email from earlier:

Between DMARC not passing and the message content, Gmail flagged the email and asked me whether to trust it. If users click "Report spam", dev.to's reputation takes the hit, making it harder for their legitimate mail to reach inboxes.

Closing remarks

This post is published on dev.to — about a DMARC failure in dev.to's own mail. It's a good example of why "SPF and DKIM both pass" isn't the finish line. I've reported this to the DEV team, so by the time you read this, it may well be fixed.

Either way, the lesson stands: make sure your DMARC is set up correctly. DMARC gives receiving servers strict instructions on what to do with email that fails authentication, and that's a key part of protecting your domain's reputation.

DEV Community: Francisco Magalhães