DeliverabilitySecurityBy Sapere Digital

Why your emails go to spam: the DMARC record most brands never set

A quiet failure mode is eating your pipeline. One DNS record most brands never set decides whether your invoices, proposals, and cold emails land in an inbox or a spam folder. Here is what it does, why it matters, and how to fix it before your next quote goes missing.

Deliverability
Silent failure is the worst kind.

Somewhere last week, a proposal you sent for a five-figure engagement never arrived in the client's inbox. You do not know it happened. You will not know until the follow-up call gets awkward and the client says, apologetically, that they never received the email. You will apologise, resend, and never find out why.

The odds are strong that the email did not fail. It was delivered. It just landed in a spam folder because your domain is missing one DNS record.

This piece is about that record.

The invisible failure mode

Email deliverability does not fail in one loud, obvious event. It erodes.

A receiving mail server does not owe you an explanation. When it decides your message is suspicious, it does not bounce it back with a reason. It scores it against dozens of signals, subtracts a few points from your sender reputation, and drops the message into a filter folder the recipient may never open. If enough messages score the same way, your reputation drops, and the next message is more likely to be filtered too. The tighter the receiver's spam heuristics (Google Workspace and Microsoft 365 are among the strictest), the faster the erosion.

Your open rates drift down. Your reply rates drift down. Nobody calls to tell you. You assume the market is soft, or the copy is weak, or the outreach list is stale. Sometimes all of those are true. Often the real answer is a two-line DNS record you never set.

What we found scanning peer studios

We spent the last stretch of the year studying the studios we admire, from Focus Lab to Instrument to Work & Co. Part of that study was visual. Another part was infrastructure. We wrote a small internal scanner that checks the same DNS and security signals we would want a prospect to know about before we send them a first email.

The pattern we saw across the sample was the same pattern we saw when we scanned our own domain a year ago: SPF was almost always present, DKIM was hit-or-miss, DMARC was mostly missing or set to a monitor-only policy with no reporting address. These are agencies with real design reputations, real client lists, and real work to protect. None of that changes the DNS.

That is the important thing to understand. This is not a small-business problem or a technical-team problem. It is a category-wide gap, in agencies and out. Nobody is checking, and the receivers that matter have quietly been raising the bar.

Broader data backs the pattern. A February 2026 scan of 5.5 million internet domains by DmarcGuard found only 30.4% had adopted DMARC at all, and just 12.8% were enforcing a policy strict enough to actually block spoofed mail. EasyDMARC's April 2026 report on a more targeted business-domain index put valid DMARC adoption at 52.1%, up from 47.7% a year earlier. Enterprise adoption is stronger (research on the Fortune 500 puts the record-published figure north of 90%), but even there, only about six in ten enforce the strictest policy. The rest are publishing DMARC and doing nothing with it.

SPF, DKIM, and DMARC in plain English

The three records that decide most of the outcome are older than most SaaS. None of them require code. All of them live in your DNS.

SPF (Sender Policy Framework) is a public list of servers that are allowed to send email on behalf of your domain. It sits on your DNS as a TXT record that starts with v=spf1. When a receiver gets a message claiming to come from you, it checks the sending server's IP against the list. If the server is not on the list, the check fails.

The catch: most brands add every platform they have ever used to their SPF record and never remove the old ones. The spec allows a maximum of ten DNS lookups per SPF evaluation. Overshoot and the record silently breaks.

DKIM (DomainKeys Identified Mail) is a cryptographic signature. Your sending platform holds a private key. The matching public key sits in your DNS. Every outbound message gets signed with the private key, and receivers use the public key to verify that the message was not altered in transit and did come from a server holding your key.

The catch: DKIM keys are per-platform. If you send from a marketing platform, a CRM, and a transactional service, you have three DKIM records to keep alive.

DMARC is the policy that binds the other two together. It tells receivers what to do when a message fails SPF or DKIM: nothing (monitor), send to spam (quarantine), or reject outright. It also gives you an email address to receive aggregate reports about who is sending messages that claim to be you. Those reports are how you find out that a hosting platform you cancelled two years ago is still trying to send email from your domain, or that a spammer is spoofing your address to your own customers.

A minimal DMARC record looks like this, published as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

That says: enforce nothing yet, and send me the aggregate reports so I can see what is happening. It is the correct place to start. It is not the place to stop.

What actually happens when DMARC fails or rejects

Two kinds of DMARC events start showing up the moment you publish the record. Neither is loud, which is what makes DMARC hard to reason about at first.

Rejected messages. When your policy is p=reject and a message claiming to be from you fails both SPF and DKIM, the receiving mail server drops it before delivery. The recipient sees nothing. The sender may or may not get a bounce, depending on the receiver's configuration. This is the intended behavior for spoofing attempts and the reason DMARC exists at all. It is also the reason a rushed rollout is dangerous: a misconfigured legitimate sender (a marketing platform whose SPF include-line went stale, an ops tool the founder set up two years ago and forgot) gets treated the same as a spammer, and its mail silently disappears.

Aggregate reports. If you set up DMARC and are suddenly getting daily XML emails from Gmail, Yahoo, and Microsoft, those are the reports you asked for. Each one is a summary from a specific receiver, listing every source that tried to send messages using your domain over the last 24 hours: source IP, count, whether SPF and DKIM passed, whether they aligned with your From-domain, and whether the message was delivered or filtered. Raw XML is unreadable on purpose. Postmark's free DMARC monitor and Valimail's free tier both parse them into a dashboard that shows the same data in a way a human can act on.

Together these two feedback loops are how you actually maintain email authentication over time. Publish, wait for reports, fix what breaks, tighten policy.

The right rollout, not the fast one

The reason most brands either skip DMARC or leave it stuck on p=none forever is the same. Moving from monitor to enforce, without an audit, breaks legitimate email. Every service you use that sends on your behalf has to pass either SPF or DKIM (ideally both). Miss one, and the day you flip your policy to quarantine or reject, the marketing team's newsletter starts landing in spam, your invoicing platform stops delivering receipts, and the founder's personal address suddenly can't cc a client.

The safe rollout is boring on purpose.

  1. Publish DMARC in monitor mode (p=none) with a rua reporting address.
  2. Collect two to four weeks of aggregate reports. Parsers like Postmark's free DMARC monitor or Valimail's free tier will turn the XML into a readable dashboard.
  3. Audit the senders that show up. Every legitimate sender needs SPF alignment, DKIM alignment, or both. Every unknown sender is either an old service still connected or an attempted spoof.
  4. Move to p=quarantine once every legitimate sender is passing. Keep monitoring.
  5. Move to p=reject once you are confident. This is the strict policy Google and Microsoft prefer to see from serious senders.

That whole process is a couple of hours of focused work spread across a month of monitoring. It is not glamorous. It is the difference between a pipeline that lands and a pipeline that drifts.

Why this matters more in 2026 than it did in 2022

The receivers moved the goalposts. In early 2024, Google and Yahoo both started requiring proper authentication (SPF and DKIM aligned, plus a valid DMARC record) for any sender pushing more than 5,000 messages per day to their users. That was the loud change. The quiet change since then is that both receivers have been tightening the same signals for smaller senders too. Microsoft 365 has been on the same trajectory, driven by enterprise IT teams demanding stronger anti-spoofing defaults.

The result is that the deliverability floor has risen for everyone. A brand that shipped fine in 2022 with only SPF configured is now sitting at a lower inbox rate than it was two years ago, and nobody in the building has noticed. There is no dashboard for the emails that never arrived.

How to check yours today

Five minutes, three lookups, one honest answer.

dig TXT yourdomain.com | grep spf
dig TXT _dmarc.yourdomain.com
dig TXT default._domainkey.yourdomain.com

The first returns your SPF record if one is published. The second returns your DMARC record. The third probes the most common DKIM selector; if your sending platform uses a different name, you will need the selector from that platform's dashboard.

If any of the three come back empty, you have a real gap. If your DMARC returns p=none with no rua address, you have a stub, not a policy. If SPF ends in ~all (soft fail) or ?all (neutral), you are asking receivers to guess.

Prefer a click over a command line? MXToolbox and DNSChecker both offer free lookup tools that return the same answers in a readable page.

Where we sit on this at Sapere Digital

We treat email authentication as part of the launch checklist, not an afterthought. Every site we ship for a client goes live with SPF, DKIM, and DMARC configured against their real sending stack, aggregate reports pointed at a real address, and a rollout plan documented for the client's IT lead or ops team to follow. It costs no more than an hour of work at launch and it protects the pipeline the site was built to feed.

For our own outbound, we built ourselves a small scanner that runs the same set of checks (DNS, TLS, security headers, and a set of other public signals) on any domain we are about to reach out to. If we cannot deliver a proposal to a prospect reliably, nothing else about the pitch matters. If they cannot deliver a proposal to their own clients reliably, that is a conversation worth having.

Silent failure is the worst kind. This one is fixable in an afternoon.

Sources

Answers

Frequently asked questions

Is DMARC really necessary?
Yes for any business that sends email from its own domain. In 2024, Google and Yahoo made it a soft requirement for anyone sending more than 5,000 messages a day to their users, and both have been quietly tightening the same signal for smaller senders since. Without DMARC, receiving mail servers cannot cleanly distinguish your real email from someone spoofing your domain, which means legitimate mail is more likely to be filtered and impersonation attempts are more likely to reach your customers. The DNS record itself is free. The rollout is what takes time.
How do I explain DMARC in plain English?
DMARC is a note attached to your domain that tells the internet what to do when someone sends an email pretending to be you. If the email passes proof-of-identity checks (SPF and DKIM), it goes through. If it fails, the receiver follows your instruction: ignore the failure, send the message to spam, or reject it outright. DMARC also asks receivers to send you a daily summary of who is trying to send email using your name, which is how you spot impersonation attempts early.
Does DMARC need both SPF and DKIM?
Technically no. DMARC requires at least one of the two to pass and to align with the From-address the recipient sees. In practice you should have both. SPF alone breaks when messages are forwarded through mailing lists or aliases. DKIM alone can produce false failures if a middlebox rewrites headers. Publishing both gives you two independent proofs, so a single misconfiguration on either side does not silently drop your legitimate mail. Every serious sending platform (marketing, transactional, help desk) supports both out of the box.
Do you need SPF if you use DKIM?
For DMARC to enforce reliably, having both is safer. DKIM signs the message contents cryptographically, which survives forwarding. SPF verifies the sending server's IP, which does not. If you rely on DKIM alone and one of your sending platforms starts sending from a server without a valid DKIM key (a common misconfiguration during platform changes), the message fails DMARC alignment with nothing else to catch it. SPF acts as the second lane. Neither costs more than the DNS record it sits in.
What should my DMARC be set to?
Start at p=none with a rua reporting address, monitor for two to four weeks, then move to p=quarantine, then to p=reject once every legitimate sender is passing authentication. p=none is the safest starting policy because it tells receivers to enforce nothing yet, so you cannot break your own outbound mail while you audit which platforms are sending on your behalf. p=reject is the strict policy Google and Microsoft prefer to see from serious senders. Skipping the monitor stage is how brands break their own newsletters overnight.
Why do I get DMARC emails?
Those are DMARC aggregate reports, sent daily by receiving mail servers to the rua address you published in your DMARC record. Each report lists who tried to send email using your domain, whether SPF and DKIM passed, whether they aligned with your From-address, and what the receiver did with the message. If you set up DMARC recently, you will start seeing these show up automatically. Raw XML is unreadable by design. Free parsers like Postmark's DMARC monitor or Valimail's free tier turn them into a dashboard a human can actually act on.
What does it mean when an email is rejected due to DMARC?
It means the receiving mail server saw a message claiming to come from your domain, ran the SPF and DKIM checks, found neither passed and aligned with your visible From-address, and applied your DMARC policy of p=reject. The message was blocked at the mail server before hitting any inbox. Two common causes: your sending platform is missing a DKIM key or your SPF record does not list its IPs, so a legitimate message fails and looks like spoofing; or someone is actively trying to impersonate your domain and the reject policy is doing exactly what it was set up to do.
How do I configure DMARC for email?
Publish a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. Add it in your DNS provider (Cloudflare, GoDaddy, Route 53, your registrar's control panel) as a new TXT record with host _dmarc and value the DMARC string. Save. It typically propagates within an hour. Then wait two to four weeks while the aggregate reports come in, audit every sender showing up in those reports, and once every legitimate sender is passing SPF or DKIM, tighten the policy to quarantine then reject.
Why do my emails go to spam instead of inbox?
Spam scoring is cumulative. Missing DMARC is one signal. Others include a mismatched SPF record, unsigned DKIM, a sending IP with a poor reputation, high bounce rates from old contact lists, low engagement (recipients not opening or replying), and content signals like URL shorteners, all-caps subject lines, and excessive images. Fixing DMARC alone will not solve the problem if the other signals are also wrong, but leaving DMARC out guarantees the score works against you no matter how clean everything else is.
How do I fix incoming emails going to spam?
This is a different problem from outbound spam. If mail coming into your inbox is being filtered, the receiving side (your Gmail, Outlook, or Microsoft 365 setup) is scoring it as spam. Fixes on the receiving side: mark the sender as not-spam, add them to your contacts, create a filter rule to keep future messages from that sender in the inbox, or ask your IT administrator to allowlist the sending domain. If a specific sender's mail is always being flagged, the problem is likely on their DMARC, SPF, or DKIM setup, not yours.
Tagged
dmarcspfdkimemail-deliverabilitydnsagency-craft
Continue reading

More from the studio