Say Your Name

Deliverability Case Study: "Say Your Name"

One pronoun does all the work here. Destiny's Child demanded "say my name" of a partner they suspected of hiding something; flipped to "say your name," it becomes the demand a receiving mail server makes of every connection it accepts. The narrator is not a marketer — it is the receiver, reading the Authentication-Results header and finding the story doesn't add up. Every accusation in the original ("you actin' kinda shady", "prove yourself to me") maps cleanly onto what a mailbox provider does at SMTP time: demand cryptographic proof that the domain in the From header belongs to whoever is sending. Late 90s R&B production carries a lyric about DMARC alignment">DMARC alignment.

Here is the technical breakdown of the deliverability concepts detailed in the song:

Chorus: Alignment Is the Whole Question

"Say your name, say your name / If no one is a spoofer, say, 'DMARC is aligned' / ... / You actin' kinda shady, your DKIM is failing / Watch me junk your mail"

• The Deliverability Context: DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) adds no new cryptographic check — it adds an alignment check on top of SPF and DKIM. SPF validates the envelope sender (the Return-Path / MAIL FROM domain); DKIM validates the signing domain in the d= tag. DMARC asks the further question: does either of those authenticated domains match the domain the human actually sees in the From header? A message can pass SPF perfectly and still fail DMARC, because the pass belonged to the sending platform's bounce domain rather than to your brand. "Say DMARC is aligned" is the right demand — not "did you authenticate", but "did you authenticate as yourself".
• The Consequence: "Watch me junk your mail" is the p=quarantine outcome; under p=reject the message is refused during the SMTP transaction and never lands. A DMARC policy is a request, though, not a command — the receiver applies local policy, and mail from a p=reject domain can still be quarantined or accepted if its reputation model disagrees.
• Where the Chorus Overstates Its Case: "Your DKIM is failing" is not on its own grounds for junking. If SPF passes and aligns, DMARC passes regardless of what DKIM did. The narrator can be suspicious anyway: a broken signature (dkim=fail) is a worse signal than no signature (dkim=none), because something modified the message or the key does not resolve — a reputation negative independent of DMARC. The verdict is defensible, just not for the reason the chorus gives.

Verse 1: p=none Is a Policy That Protects Nobody

"Every other log line is 'Fail, soft, delay' / Could it be your DMARC is still sitting at p equals none?"

• The Deliverability Context: p=none is monitoring mode: take no action on failures, just report them back. It is the correct place to start a rollout — you need weeks of aggregate reports to find every legitimate mail stream (transactional platform, CRM, invoicing system, the one tool a regional team signed up for) before enforcing. Parked there indefinitely, it gives an attacker free rein to spoof your exact From address. Since February 2024, Gmail and Yahoo require bulk senders — 5,000+ messages a day to Gmail accounts — to configure both SPF and DKIM, publish a DMARC record (p=none accepted), and align the From domain with at least one of the two. Microsoft applied equivalent requirements to Outlook, Hotmail, and Live in May 2025. A bare DMARC record is not enough on its own, and neither is authenticating without alignment.
• A Note on "Fail, soft, delay": Two of those are real SPF results — fail (hardfail, the -all qualifier) and softfail (~all: probably not authorized, accept and mark). "Delay" is not an authentication result at all; it is what the receiver does next, a 4xx temporary deferral parking the message in your queue while it decides whether to trust you. Read as one continuous log line, that is exactly how a mail log looks.
• The Fix: "Why don't you sign the mail like you did for me yesterday?" — a DKIM signature that worked yesterday and fails today usually points at a rotated or removed selector, a 2048-bit key published as a single TXT string longer than the 255-character limit and silently truncated, or a middlebox rewriting the body after signing.

Pre-Chorus: Aggregate Reports Are the Evidence

"Where you pass authentication tests times two / Why can't you align DMARC? / Check the RUA I sent to you"

• The Deliverability Context: The rua= tag is the address where receivers send daily aggregate XML reports — the one place in email where the receiving side actively tells you what it saw: which IPs sent mail claiming your domain, whether SPF and DKIM passed, and crucially whether they aligned. The narrator is not being cryptic; it genuinely mailed the evidence to the address the sender published.
• One Technical Correction: "pass authentication tests times two" implies DMARC needs both SPF and DKIM. It does not — DMARC passes when either passes with alignment. Doing both is still the resilient setup, for a more precise reason than "SPF is fragile": on forwarding, the relaying server's IP was never in your record, so SPF fails outright. If that forwarder implements SRS (Sender Rewriting Scheme) it rewrites the envelope sender into its own domain and SPF then passes — for the forwarder. Either way, alignment against your From domain fails. DKIM survives the trip, provided nothing altered the signed headers or body.

Verse 2: Return-Path, Shared IPs, and the Forwarding Alibi

"Who owns that IP list? / ... / Don't try to change it now, blamin' your forward route / When two seconds ago your DKIM sig just flunked out / ... / When the Return-Path shows, Return-Path shows someone else"

• The Deliverability Context: The sharpest writing in the song. A Return-Path showing "someone else" is the most common cause of SPF misalignment: by default most sending platforms put their own bounce domain in MAIL FROM, so SPF authenticates them, not you. The fix is a custom return path — a CNAME on a subdomain you control — so the envelope sender aligns with your From domain.
• "Who Owns That IP List?" Is the Real Security Question: An include: for a shared sending platform authorizes that platform's entire outbound pool, every other tenant included. An SPF pass therefore proves only that someone on that infrastructure sent the message — never that it was you. Only a DKIM signature, made with a key nobody else holds, proves authorship, which is why SPF-only alignment is the weaker of the two DMARC paths. Second trap: RFC 7208 caps evaluation at 10 DNS lookups, and stacked include: chains blow past it into permerror — which no receiver converts into a pass, leaving DMARC nothing to align against.
• Why the Alibi Fails (Mostly): Forwarding is a legitimate excuse for SPF failure, and exactly why ARC (Authenticated Received Chain, RFC 8617) exists — it lets an intermediary record the result it saw and vouch for it downstream. But the narrator is right to be unimpressed: plain alias forwarding relays the message byte-for-byte and leaves a correct DKIM signature intact. The excuse only holds for mailing lists, which rewrite subjects and append footers, legitimately breaking the body hash. A DKIM failure with no list headers in the message is not a forwarding problem.
• The 550 Threat: "How would you like a five-five-oh bounce code from my script?" — 550 is the permanent rejection class. DMARC refusals surface as 550 5.7.1 or 550 5.7.26 ("unauthenticated email from your domain is not accepted"). A permanent rejection is a hard bounce: suppress it, and watch the rate, because it compounds the reputation damage already underway.

Bridge: BIMI Is the Reward, Not the Shortcut

"Show that VMC / Show your BIMI / Show your logo"

• The Deliverability Context: BIMI (Brand Indicators for Message Identification) shows your verified logo beside your message in supporting inboxes, and the gates are stricter than most summaries admit. DMARC must be at enforcement — p=reject, or p=quarantine only at pct=100 — and an sp= subdomain policy cannot weaken it back to none. You publish a TXT record at default._bimi.yourdomain.com pointing at an SVG Tiny P/S logo, and Gmail and Yahoo additionally require a certificate: a VMC (Verified Mark Certificate), backed by a registered trademark, or a CMC (Common Mark Certificate), for logos with documented prior use. Apple Mail accepts VMCs only; a few providers render a self-asserted logo with no certificate at all.
• Why the Taunt Lands: The narrator is mocking a sender who wants the logo while still sitting at p=none — a configuration BIMI rejects by definition. The order is not negotiable: alignment, enforcement, then the badge.

Outro: The Claim the Song Cannot Quite Back Up

"Thou shalt know you can't spoof me"

• The Deliverability Context: A great closing line and an overstatement. DMARC at p=reject stops exact-domain spoofing — nobody else can put yourbrand.com in the From header and reach an enforcing inbox. That is the entire scope of the guarantee.
• What Still Gets Through: A cousin domain (yourbrand-support.com, yourbránd.com) is a different domain with its own valid DMARC record; your policy has no say over it. Display-name spoofing puts "Your Brand" in the friendly-from while the real address is a throwaway mailbox that authenticates flawlessly — and mobile clients often show only the display name. A compromised account on your own tenant sends genuinely signed, genuinely aligned mail. DKIM replay re-injects one legitimately signed message at volume to new recipients, riding your valid signature.
• The Honest Version: Authentication proves a domain, not an intention. It is the floor of email security, not the ceiling — pair it with lookalike-domain monitoring, external-sender warning banners, and multi-factor authentication on every mailbox that can send.