Back to blog
7 min read
Security & Email

SPF and DMARC: the 2 email tests every audit should include

Your client's website looks perfect. But their emails land in spam. SPF and DMARC take 30 seconds to verify and can prevent deliverability disasters — or phishing attacks.

Key Takeaways
  • SPF and DMARC are DNS records that authenticate email senders — without them, anyone can send emails pretending to be your client's domain
  • Since February 2024, Gmail and Outlook require SPF and DMARC for bulk senders — missing these records directly impacts deliverability
  • These checks take 30 seconds and can prevent disasters: lost invoices, missed contacts, phishing attacks on your clients

Picture this: your client calls you. They just launched an email campaign to announce new services. Result? Zero responses. Messages are landing in spam, or worse, scammers are sending fraudulent emails from their domain to their own clients.

Most website audits check SSL, performance, SEO, accessibility. But they ignore two DNS records that take 30 seconds to verify and can literally save a business: SPF and DMARC.

These aren't obscure technical details. They're invisible shields that protect a domain's email credibility. And since February 2024, Gmail and Outlook explicitly require them. If your audit doesn't check them, it's missing something essential.

SPF and DMARC: email audit, deliverability, anti-phishing, DNS

What is SPF? (Sender Policy Framework)

SPF is a DNS TXT record that lists the servers authorized to send emails on behalf of a domain. When a server receives an email claiming to come from your-client.com, it checks that domain's SPF record to verify whether the sending server is on the list of authorized senders.

If the server isn't on the list, the email can be marked as spam or rejected. It's that simple.

How it works, step by step:

  1. An email is sent from server.hosting.com claiming to be from your-client.com
  2. The receiving server queries DNS: what is the SPF record for your-client.com?
  3. It compares the sending server's IP against the SPF list
  4. If the IP is authorized: the email passes. Otherwise: spam or rejection based on policy

Example SPF record (Google Workspace):

# Enregistrement SPF pour Google Workspace
v=spf1 include:_spf.google.com ~all

The `~all` mechanism means "softfail" emails not on the list. The `-all` mechanism is stricter and rejects them completely. Avoid `+all` which allows anyone to send — it's the same as having no SPF at all.

What is DMARC? (Domain-based Message Authentication, Reporting & Conformance)

DMARC goes further than SPF alone. It builds on SPF and DKIM (another authentication method that cryptographically signs emails) to define a clear policy: what to do when an email fails authentication?

Without DMARC, even if SPF says "this email is suspicious," each mail server decides what to do on its own. With DMARC, you provide clear instructions.

The 3 DMARC policies:

  • p=none — Monitoring mode: the email passes but you receive reports. This is the recommended starting point.
  • p=quarantine — Suspicious emails go to spam. This is the intermediate step.
  • p=reject — Unauthenticated emails are rejected completely. This is the maximum protection level.

Example DMARC record:

# Enregistrement DMARC (à placer sur _dmarc.votredomaine.com)
v=DMARC1; p=quarantine; rua=mailto:dmarc@votredomaine.com; pct=100

The `rua` attribute lets you receive aggregate reports by email — they tell you who is trying to send emails impersonating your domain. A valuable tool for detecting spoofing attempts before they cause damage.

Why it's critical for your clients

The question isn't "is this useful?" — it's "what's the cost of not having it?"

Deliverability: Gmail and Outlook changed the rules

In February 2024, Google and Microsoft announced new requirements for bulk email senders. SPF and DMARC are no longer optional for reaching Gmail and Outlook inboxes. A domain without these records sees open rates plummet and emails systematically sent to spam.

Protection against phishing and spoofing

Without SPF or DMARC, anyone can send emails pretending to be your-client.com. Scammers can contact your client's customers, suppliers, banker — using their domain name. The reputational damage can be irreversible.

Long-term domain reputation

Email providers maintain reputation scores for every domain. A domain without SPF/DMARC accumulates less "trust." Over time, even legitimate emails end up in spam. This is a problem that gets worse with time.

A flawless website is useless if the domain's emails land in spam. SPF and DMARC are the invisible foundation of online credibility.

The 3 most common mistakes

Mistake #1: No SPF record at all

The most common case, especially on older or neglected domains. The domain sends emails (via Gmail, Mailchimp, or the CMS) with no SPF record whatsoever. Every unauthenticated email is a deliverability and phishing risk.

Mistake #2: SPF too permissive with +all

An SPF record ending with `+all` literally allows any server to send emails for that domain. This is worse than having no SPF: it gives a false sense of security. Look for `+all` in your clients' SPF records — it's a red flag.

Mistake #3: DMARC stuck at p=none indefinitely

Starting with `p=none` is the right approach (monitoring mode). But many domains stay there forever. Without moving to `p=quarantine` then `p=reject`, DMARC offers no real protection — it watches without ever acting.

How to check SPF and DMARC in 30 seconds

No sophisticated tools needed. Two command-line commands (or web tools) are enough:

Check SPF with dig:

dig TXT votredomaine.com | grep spf

Check DMARC with dig:

dig TXT _dmarc.votredomaine.com

Free online tools:

  • MXToolbox (mxtoolbox.com) — analyzes SPF, DMARC and DKIM with explanations
  • Google Admin Toolbox (toolbox.googleapps.com) — official Google tool
  • DMARC Analyzer (dmarcanalyzer.com) — analysis and record generator

What to look for:

  • SPF present: the TXT record starts with v=spf1
  • SPF not +all: the final mechanism must be ~all or -all
  • DMARC present: the TXT record for _dmarc. starts with v=DMARC1
  • DMARC not stuck at none forever: ideally p=quarantine or p=reject

How Orilyt will test SPF and DMARC

SPF and DMARC checks are part of Batch 1 of Orilyt's new multi-CMS tests, currently under development.

These tests will be entirely external: a simple DNS query, no admin access required, no plugin, compatible with all CMSs (WordPress, Wix, Squarespace, Shopify, custom sites...). If the domain exists, the test works.

  • External DNS check: no site access required
  • Compatible with all CMS: WordPress, Webflow, Shopify, custom sites
  • Automatically included in every Orilyt audit
  • FIA recommendation generated: Fact, Impact, Action — ready to present to the client

The goal: every Orilyt report automatically includes an "Email & Security" section with SPF and DMARC status, plus a clear recommendation if either is missing or misconfigured.

Email audit: the quick win nobody checks

SPF and DMARC are probably the most overlooked checks in a traditional web audit. They're not visible in the browser, they don't affect the PageSpeed score, yet they have a direct business impact: lost emails, identity spoofing, degraded reputation.

For a freelancer or agency, including these checks in every audit is both a competitive advantage and a genuine service to clients. How many SMBs have non-existent or misconfigured SPF records? The answer would surprise you.

The good news: fixing them takes 10 minutes at the hosting control panel. But first you have to detect them. That's exactly what Orilyt will do automatically in every audit.

Audit any site in 2 minutes
Run an Orilyt audit and get a complete diagnosis — soon with SPF and DMARC verification included.
Launch a free audit
Previous Migration HTTP vers HTTPS en 2026 : il reste encore 15 % de sites non sécurisés Next L'état de la sécurité WordPress en 2026 : enseignements de 10 000 audits