Your Client’s Email Is Being Spoofed Right Now. You Just Don’t Know It Yet.

The email attack surface most agencies overlook

When an agency builds a website for a client, SSL gets set up, DNS gets configured, and the inbox goes live. Then the project closes and the domain health monitoring starts… nowhere. Email security configuration — SPF, DKIM, DMARC — gets created once, tested briefly, and never looked at again.

The problem is that email infrastructure is fragile and changes constantly. A new marketing team switches to HubSpot. The transactional mail provider moves from Mailgun to Postmark. The domain migrates to a new registrar. The nameservers change. Any one of these events can silently break DKIM signatures, invalidate SPF records, or leave a DMARC policy pointing at a report URI that no longer exists.

Meanwhile, attackers are watching. They use tools that continuously scan DMARC policies. The moment they see p=none — or worse, no DMARC record at all — your client’s domain becomes a viable spoofing vector. Phishing emails carrying your client’s branding start landing in inboxes globally. The client finds out when a customer calls asking why they received a suspicious invoice.

SPF — who is authorised to send on your behalf?

Sender Policy Framework (SPF) is a DNS TXT record that lists every mail server authorised to send email for a domain. When a receiving mail server gets a message from noreply@client.com, it checks the SPF record of client.comto see if the sending IP is listed. If it isn’t, the message fails SPF.

But SPF alone is not enough — and this is where most agencies stop. SPF only validates the envelope sender (the technical Return-Path address used during SMTP delivery), not the “From:” address the recipient actually sees. Attackers can pass SPF while displaying a completely different sender name and domain in the visible From header. This is called a header-from spoofing attack, and it’s the most common phishing technique used against brand domains.

DKIM — the cryptographic signature that breaks silently

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing email. The sending server signs the message with a private key, and publishes the corresponding public key in DNS as a TXT record at a selector subdomain like mail._domainkey.client.com. Receiving servers look up that public key and verify the signature, confirming the message came from the legitimate sending server and wasn’t modified in transit.

DKIM is the component of email security that breaks most often in agency-managed environments. Here’s why:

• Key rotation: Email service providers rotate DKIM keys periodically. If the new public key isn’t published in DNS, DKIM fails silently and mail may get marked as spam.
• Provider migrations: Switching from one mail platform to another requires publishing new DKIM selectors. Old selectors left in DNS don’t cause failures but create confusion.
• Wildcard DNS changes: A DNS migration that doesn’t carry over all subdomain records can wipe DKIM selectors without anyone noticing.
• Multiple sending services: A client using Google Workspace for corporate mail, Mailchimp for newsletters, and Stripe for receipts needs a DKIM selector for each. Miss one and that sending path lacks authentication.

DKIM failures don’t generate an error message to the sender. The client doesn’t receive a bounce. Mail continues to be delivered — just with a failing DKIM signature that increasingly causes deliverability problems as inbox providers tighten their filtering.

DMARC — the policy that ties everything together

Domain-based Message Authentication, Reporting & Conformance (DMARC) is the policy layer that sits above SPF and DKIM. It tells receiving mail servers what to do when a message fails authentication: do nothing (p=none), send it to spam (p=quarantine), or reject it (p=reject).

DMARC also enables two types of reporting:

• Aggregate reports (rua): XML summaries sent daily or weekly by every major receiving provider, showing all mail flows for the domain.
• Forensic reports (ruf): Individual samples of messages that failed authentication, sent in near-real-time (less common due to privacy rules in EU).

The critical insight: the majority of domains that have a DMARC record are still on p=none. They have the monitoring infrastructure in place but have never moved to enforcement. For attackers, p=none domains and domains with no DMARC at all are both open targets. The difference is you get reports for the former — but only if those reports are going to an address someone actually reads.

MTA-STS & TLSRPT — encrypting the mail path

SMTP was designed in 1982 — before TLS existed. By default, mail delivery between servers can be downgraded from an encrypted TLS connection to plaintext if a man-in-the-middle interferes with the connection negotiation. This is called a STARTTLS downgrade attack, and it enables interception of mail in transit.

MTA-STS (Mail Transfer Agent Strict Transport Security) solves this by publishing a policy that tells other mail servers: “always use TLS when delivering to this domain, and verify the certificate.” The policy is served as a text file at a specific HTTPS endpoint:

version: STSv1
mode: enforce
mx: mail.client.com
mx: *.google.com
max_age: 86400

TLSRPT (TLS Reporting) is the companion standard — a DNS record that tells sending mail servers where to send reports about TLS connection failures. It’s the same pattern as DMARC aggregate reports, but for the transport layer rather than the authentication layer.

MTA-STS and TLSRPT are the least-deployed email security standards and the ones agencies are most likely to set up once and never revisit. The MTA-STS policy file sits on a web server — if that server goes down, the policy becomes unreachable, and mail delivery begins to fail for any sender that enforces strict TLS.

BIMI — brand logos in the inbox (and why it needs monitoring)

Brand Indicators for Message Identification (BIMI) is a newer standard that allows a verified brand logo to appear next to emails in supporting inboxes (Gmail, Apple Mail, Yahoo, Outlook). It requires a domain to have p=quarantineor p=reject DMARC enforcement, and to publish an SVG logo URL in a DNS TXT record.

For agencies with retail or brand clients, BIMI is increasingly a client expectation — it’s visible proof that email security has been properly implemented. But it also introduces a monitoring dependency: if the SVG file moves, if the CDN serving it goes down, or if the VMC certificate (required by some providers) expires, the logo disappears from inboxes and BIMI silently fails.

What breaks email security silently — and when

The common thread across all email security standards is that failures are invisible to the sender. Unlike a broken website (load it and you know) or an expired SSL certificate (the browser screams at you), email authentication failures generate no customer-visible error. Mail may still be delivered — just with degraded trust scores that accumulate over weeks until deliverability collapses.

The monitoring checklist for agencies

Setting email security records at launch is table stakes. What separates agencies that have client email incidents from agencies that don’t is continuous monitoring. Here’s what needs to be checked regularly for every client domain:

For an agency managing 50 client domains, checking this stack manually even quarterly is not realistic. Changes happen between checks. The only effective approach is automated monitoring that runs continuously and alerts the moment a record changes, disappears, or fails validation — before a client calls asking why their mail is going to spam.