Your quotes land in spam — and it is almost never your mail provider's fault

A customer asks for a quote. You send it. Two days later they say they never got it — or they call the
price "the one in the spam folder".

It is rarely a mystery, and rarely the provider's fault: the message was almost certainly delivered — into
a spam folder, or into a rejection with a bounce nobody reads. Your domain failed one of three checks, and
the provider is not the party that was supposed to finish them.

Here is what is happening — and how to check your own domain in ten minutes.

Three records, three different jobs

SPF is a DNS TXT record listing who may send mail using your domain. The part people miss: SPF
authenticates the envelope sender — the RFC 7208 "MAIL FROM" identity that carries routing and bounces —
not the friendly From: header your customer sees (RFC 7208 §2.4). If your website form, booking tool or
CRM sends through its own infrastructure, its envelope domain is often its own, not yours — SPF passes,
your domain gets no credit.

SPF also has a hard ceiling: implementations MUST limit evaluation to 10 DNS-lookup-causing terms and
return permerror past that (RFC 7208 §4.6.4). Every include: counts. One integration too many and a
record that worked for years starts failing for everyone at once.

DKIM is a signature. Your mail system signs each message with a private key; the matching public key
sits in DNS at <selector>._domainkey.yourdomain.com. If the signature verifies, the receiver knows the
message came from a domain holding that key. Two failure modes: the key was never generated (or its record
was never published), or the signature dies in transit — DKIM's own spec notes that "some mail systems
modify email in transit, potentially invalidating a signature" (RFC 6376 §3.4). Check the crypto too:
rsa-sha1 is banned and keys must be at least 1024 bits, 2048 recommended (RFC 8301).

DMARC is the policy that ties the other two together: what receivers do with mail claiming to be from
your domain that fails SPF and DKIM, and where to send reports. DMARC runs on alignment — "when the
domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier
Alignment" (RFC 7489 §3.1). An SPF pass for your booking tool that does not align with the domain in your
visible From: is not a DMARC pass. That is why a domain with "SPF and DKIM already set up" still gets
filtered.

Most domains I look at publish DMARC at p=none. That is monitoring mode — the spec says a p=none
policy should not change how receivers handle the mail (RFC 7489 §6.7). It is a fine first stage: if you
send more than 5,000 messages a day to Gmail, a DMARC record (policy may be p=none) has been a Google
requirement since 1 February 2024, alongside SPF and DKIM (Google Workspace Admin: Email sender
guidelines) — but it does not stop a spoofed invoice arriving as your domain.

Check your own domain now

Use your provider's DKIM selector — google for Workspace, selector1 for Microsoft 365, or whatever
your ESP gave you.

# SPF — expect exactly one v=spf1 record
dig +short TXT yourdomain.com

# DMARC — expect v=DMARC1; p=...; rua=...
dig +short TXT _dmarc.yourdomain.com

# DKIM — the key must actually resolve for the selector you use
dig +short TXT google._domainkey.yourdomain.com

No dig? On Windows use nslookup -type=TXT _dmarc.yourdomain.com 8.8.8.8, or open
https://dns.google/resolve?name=_dmarc.yourdomain.com&type=TXT in a browser tab.

Reading the results:

• SPF: exactly one v=spf1 record, with the lookup-causing terms (include, a, mx, ptr, exists) counted — headroom under 10, not exactly 10.
• DKIM: a key resolving for the selector your provider signs with, carrying v=DKIM1 and a long p= (2048-bit RSA). A selector that does not resolve is the classic silent failure: mail flows, signatures never happen.
• DMARC: p=none is a start, p=quarantine or p=reject is the finish line, and rua= gets you aggregate reports, so you can see who really sends as you before you tighten the policy.

When ten minutes are not enough

Those checks tell you what is published. They do not tell you which systems send as your domain, which
record to change first, or how to tighten DMARC without breaking the invoices that arrive today — paste in
a new SPF record that replaces the old one and your office mail starts failing.

Those three checks tell you what is published — not which systems actually send as your domain, which record to change first, or how to tighten DMARC without breaking the invoices that arrive today. Paste in a new SPF record that replaces the old one and your office mail starts failing. The order that has not burned me yet: read the rua= aggregate reports for a couple of weeks, align SPF and DKIM for every sender that shows up there, then move p= from none to quarantine or reject. Nothing published gets changed before you know who sends as you.

What it is not: a deliverability guarantee, a compliance certification, or a security audit of your
mailboxes.

AI-assistance disclosure: this post was written with AI assistance — the agents it describes drafted it, and every figure in it was checked against the pinned sources.