SPF and DMARC across 21 SaaS domains

Most writing about SPF and DMARC tells you what the records should say. We wanted to know what large, security-conscious companies actually publish in production, so we looked. On 19 June 2026 we queried the public DNS records of 21 well-known SaaS domains and recorded three things for each: whether they publish an SPF record and how strict it is, whether they publish a DMARC record, and whether that DMARC policy is set to monitor-only, quarantine, or full enforcement.

Everything below comes from public TXT records anyone can read. There is nothing private here, and the whole thing is reproducible in a few minutes with the DNS lookup tool — query a domain's TXT records for SPF, and _dmarc.<domain> for DMARC.

Method, and what this sample is and is not

The 21 domains: stripe.com, slack.com, notion.so, figma.com, github.com, gitlab.com, atlassian.com, zoom.us, dropbox.com, shopify.com, twilio.com, sendgrid.com, mailchimp.com, hubspot.com, salesforce.com, zendesk.com, intercom.com, datadoghq.com, cloudflare.com, digitalocean.com, and vercel.com.

This is a convenience sample of recognizable developer-facing SaaS companies, not a random draw from the whole web. These are organizations with security teams and a strong incentive to protect their domains, so the numbers here are close to a best case. Real adoption across the long tail of the internet is far lower. Read the figures as "even among companies that should get this right, here is where the gaps are," not as "this is the state of the average domain."

Finding 1: SPF and DMARC are universal at this tier

All 21 domains publish both an SPF record and a DMARC record. Not one was missing either. At the top of the market, publishing something is table stakes. The interesting variation is entirely in how strict that something is, which is where the next two findings live.

Finding 2: a quarter have not reached enforcement

DMARC has three policy levels. p=none monitors and does nothing. p=quarantine sends failing mail to spam. p=reject refuses it outright. Only p=reject actually stops a spoofed message from landing in an inbox; the other two are stops on the way there.

Of the 21 domains:

16 (76%) publish p=reject — full enforcement.
5 (24%) publish p=quarantine — notion.so, figma.com, github.com, intercom.com, and vercel.com.
0 sit at p=none.

That a quarter of this group, all of them sophisticated technology companies, still sit at quarantine is the most useful result in the study. Reaching p=reject is the hard last step: it means you are confident every legitimate source of mail for your domain is aligned, because anything you missed now bounces. Stopping at quarantine is the honest signal of a team that has deployed DMARC but has not finished proving out every sending source. If companies at this level find the final step hard, the lesson for everyone else is that the work is in the audit, not the record.

One subtlety worth calling out: github.com publishes p=quarantine for the organizational domain but sp=reject for its subdomains. That is a deliberate, mature configuration — stricter on the subdomains it controls tightly than on the main domain where more sending sources exist.

Finding 3: two enforce DMARC with no reporting at all

DMARC's rua tag tells receivers where to send aggregate reports. Those reports are how you discover which sources are failing alignment before you tighten the policy, and how you keep watching afterward. A DMARC record with no rua still enforces, but the operator is flying blind: they receive zero feedback about what is being rejected in their name.

Two of the 21 publish an enforcing DMARC policy with no reporting address: figma.com (p=quarantine;) and zendesk.com (p=reject). Both are enforcing, which is good, but neither is collecting aggregate data, so neither can easily see a newly broken legitimate sender or an ongoing spoofing campaign. Enforcement without reporting is a real blind spot, and you can read the reports you do collect with the DMARC report viewer.

Finding 4: softfail still beats hardfail almost 2 to 1

The end of an SPF record sets what happens to mail from an unlisted source: -all (hardfail, reject it) or ~all (softfail, accept but mark it). Among the 21:

14 use ~all (softfail).
6 use -all (hardfail) — slack.com, figma.com, gitlab.com, intercom.com, cloudflare.com, and digitalocean.com.
1 (hubspot.com) delegates its SPF with a redirect to a managed record.

Even among companies enforcing DMARC at p=reject, most keep SPF on softfail. That is not a contradiction. With DMARC in front, SPF softfail plus a passing, aligned DKIM signature is enough, and softfail is more forgiving of forwarding paths that would otherwise break a strict -all. The pattern across this group is clear: lean on DMARC and DKIM for enforcement, and leave SPF at ~all to avoid collateral damage. Several of these SPF records also sit close to the 10-lookup limit, which is its own reason not to keep piling on includes.

What to take from this

If 100% of leading SaaS companies publish SPF and DMARC but only 76% reach enforcement, the bottleneck is not awareness. It is the audit work between publishing a policy and trusting it enough to reject. The practical path is the same one this sample walked: publish DMARC at p=none with a rua address, read the aggregate reports until every legitimate sender is aligned, move to p=quarantine, then to p=reject, and keep reading the reports the whole time.

You can check your own domain against the same three questions in minutes. Build or validate your policy with the DMARC generator and your SPF record with the SPF generator, then read your aggregate reports in the DMARC report viewer to see where you land.

Data collected 19 June 2026 from public DNS TXT records. Records change over time; re-run the lookups to see the current state.