DMARC

DMARC is the record that decides what happens to spoofed mail. SPF and DKIM each answer a narrower question — was this sent from an authorised server, was this message signed with a valid key — but neither one tells a receiving mail server what to actually do when a message fails those checks. DMARC is the missing instruction. It sits on top of SPF and DKIM, and it does three things: it tells receivers whether to reject, quarantine, or deliver mail that fails alignment; it tells them where to send reports about what they saw; and it lets you require that a passing SPF or DKIM result actually matches the domain in the visible From: address, not just some unrelated domain buried in the message.

A domain with no DMARC record gives receivers no instruction at all. Mail that fails SPF and DKIM is delivered exactly like mail that passes — nothing distinguishes a phishing email claiming to be you from a message you actually sent. This is the single most exploitable gap Surface checks for, and it is also the most common: most domains that have never sent a marketing email or set up a mail platform have no DMARC record simply because nobody had a reason to add one.

The record

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com — not at the domain apex. It's a single line of semicolon-separated tags:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100; adkim=s; aspf=s

• •v — always DMARC1. Required, and must be the first tag.
• •p — the policy: none (do nothing, just report), quarantine (send to spam), or reject (refuse delivery outright). This is the tag that actually protects you.
• •rua — a mailto: address that receives daily aggregate reports: who is sending mail claiming to be your domain, and whether it passed. This is how you find out about legitimate senders before you turn on enforcement.
• •ruf — a mailto: address for forensic reports on individual failures. Most large receivers (Gmail, Microsoft) don't send these any more for privacy reasons, so it's optional in practice.
• •pct — the percentage of failing mail the policy applies to, for a gradual rollout. Defaults to 100. Leaving this below 100 indefinitely is a common mistake — see below.
• •sp — a separate policy for subdomains, if you want it weaker or stronger than the main one. Without it, subdomains inherit p.
• •adkim / aspf — alignment mode, r (relaxed, default) or s (strict). Relaxed allows a subdomain match; strict requires the exact same domain.

Alignment: the part that actually trips people up

DMARC doesn't just check whether SPF or DKIM passed — it checks whether the domain that passed is the same domain in the visible From: header. This is called alignment, and it's the part most explanations skip. A message can pass SPF because it came from your email marketing platform's servers, and pass DKIM because that platform signed it with their own key — but if the SPF-authenticated domain and the DKIM d= domain are both the marketing platform's domain rather than yours, and your From: header says yourdomain.com, DMARC fails on both counts even though SPF and DKIM each individually "passed". This is exactly why third-party senders (Mailchimp, SendGrid, Salesforce, your ATS, your invoicing tool) are the most common cause of DMARC breaking mail that was never actually spoofed — they need to be either sending through your own SPF-authorised infrastructure or signing with a DKIM key whose d= matches your domain, and most of the time neither is true out of the box.

Common failure modes

• •No record at all — the default state, and the one Surface flags as a fail. Anyone can spoof the domain with zero pushback from receivers.
• •p=none forever — a monitoring-only policy that was meant to be a first step but never got tightened. It gives you visibility with zero actual protection.
• •No rua address — you have no way to see who's sending mail as your domain, which means you can't safely move to enforcement without risking breaking something you don't know about.
• •pct stuck below 100 — often left at a conservative value during rollout and forgotten, meaning some fraction of spoofed mail is never actually rejected.
• •sp weaker than p — the main domain is locked down but an unused or forgotten subdomain (staging, an old marketing subdomain) has no protection and is just as spoofable as the domain having no DMARC at all.
• •Two DMARC records — publishing a second one instead of editing the first. Multiple records at the same name make DMARC invalid, and most receivers then treat the domain as unprotected.

Rolling it out safely

Start at p=none with a real rua address and let reports accumulate for two to four weeks. Read them — most DNS providers and email security vendors offer free DMARC report viewers that turn the raw XML into a readable table, since reading the reports by hand is impractical. Once you've identified and fixed every legitimate sender that isn't yet aligned, move to p=quarantine, then to p=reject once quarantine has run clean for a few weeks. Jumping straight to reject without the monitoring period is how DMARC rollouts break real, wanted mail.

Surface checks all of this — the policy strength, alignment mode, whether rua is set, whether sp matches, and whether the record is even syntactically valid — as part of every scan.