Your emails land in spam: SPF, DKIM and DMARC explained once and for all

A $30,000 quote goes out on a Tuesday morning. The client doesn't reply. Three days later, on the phone, he finds it in his junk folder. Nothing broke, no error came back, your software still shows "sent" with a green check. It's the most expensive failure mode in a small company's infrastructure: silent on both ends.

The cause is almost always the same. The server that received your message asked your domain three questions, and your domain answered at least one of them badly. The answers live in your DNS as three records: SPF, DKIM and DMARC. We covered their existence when setting up an email address on your own domain. This is the deeper version, because this is where it breaks.

What follows is what each record actually does, why most small businesses stop halfway without knowing it, and what you can check yourself this afternoon. The lines to copy and paste are already everywhere on the web, which is precisely the problem.

The short answer, for the busy

SPF, DKIM and DMARC are three DNS records answering three questions from the server receiving your mail: which servers may send for this domain (SPF), was the message altered in transit (DKIM), and what should happen when the answer doesn't match the name shown in the From field (DMARC). The first two don't authenticate the name your client sees. DMARC is what ties them to it, and DMARC is the one almost nobody finishes. Publishing p=none, the starting value, asks the receiving server for nothing; the May 2026 IETF standard (RFC 9989) defines it as the domain owner offering no expression of preference at all. Real protection starts one rung up, at p=quarantine, and ends at p=reject. Since February 1, 2024, Gmail has required every sender to have at least SPF or DKIM, and all three of them above 5,000 messages a day to Gmail accounts.

Three questions, in order

The server receiving your mail doesn't know you. It knows an IP address connecting to it, an SMTP envelope, a From header shown on screen, and your DNS, which it can query. On that basis it decides in milliseconds whether to deliver, junk or refuse.

First question: is this machine allowed to send for this domain? SPF is your published answer, a line of text in your DNS starting with v=spf1 that lists the authorized servers. For a business sending only through Google Workspace, Google publishes the minimal example: v=spf1 include:_spf.google.com ~all. The trailing ~all tells the receiver to mark anything from elsewhere as suspicious, and it's the ending Google recommends.

Second question: is this the message that was originally signed? DKIM is a key pair. The private key stays on your sending server and adds a signature to every message header; the public key is published in your DNS and lets the receiver verify that signature. Change one character in transit and verification fails. Google requires a key of at least 1024 bits to deliver to a personal Gmail account, and recommends 2048 where your DNS provider supports it.

Third question: what if it doesn't line up? DMARC is the only one of the three that lets you answer. Without it, every receiver improvises according to its own rules.

Why SPF and DKIM don't protect your name

Here's the part almost every explanation skips, and it's the decisive one. SPF checks the SMTP envelope address, the one in the MAIL FROM command, invisible to your recipient. DKIM checks the signing domain, carried in the d= tag of the signature. Neither looks at the name in the From field, the only one your client reads.

The standard says so outright: SPF and DKIM provide domain-level authentication but are not directly associated with the domain in the From header. So a fraudster can send a message that authenticates perfectly for his domain while displaying yours on screen. Both checks pass. The message looks clean.

DMARC is what closes that door. It requires alignment: the domain that passed SPF or DKIM must match the one shown in the From field. A domain without DMARC can have flawless SPF and DKIM and still never demand that match, and the fake invoice in your name goes through.

There's a second consequence, less widely known: forwarding breaks SPF, not DKIM. When a client forwards his alumni or association address to his real mailbox, your message arrives from an IP that isn't in your SPF, and SPF fails. The DKIM signature generally survives the relay. The standard draws an explicit rule from this: a domain publishing p=reject must not rely on SPF alone and must sign its messages with DKIM. SPF alone satisfies Gmail's floor, but it won't get you up the ladder.

Staying at p=none forever, the most common mistake

Publishing a DMARC record takes five minutes. That's what makes it popular and useless. Nearly every small business publishes v=DMARC1; p=none, ticks the box, and never touches it again.

But p=none protects nothing, and that isn't an interpretation. RFC 9989, promoted in May 2026 from an informational specification to an IETF standard, defines the three values plainly: none means the domain owner offers no expression of preference, quarantine that the owner considers such mail suspicious, reject that the owner sees a clearly invalid use of the name. You don't have three severity levels. You have two, preceded by an observation mode.

That observation mode has a real purpose, but a temporary one. At none, with a rua tag pointing at a dedicated mailbox, you get daily reports listing everything sending under your domain, including the services you'd forgotten. Google recommends a week of reading those reports before moving to quarantine on a small percentage. The standard is more cautious for a domain whose staff post to mailing lists: a month at none, then a month at quarantine, comparing results before going further.

One detail if you're following an older tutorial: the pct tag, which applied the policy to only a percentage of messages, was retired by RFC 9989 and moved to historic status. Google still documents and recommends it during rollout. Both positions currently coexist, and receivers that implement it still honour it, but it's a disappearing part and not something to build a strategy on.

The real obstacle: everything that sends in your name

If you're stuck at none, it's almost never laziness. It's that moving up a rung would drop legitimate mail, and nobody knows exactly which.

Take the inventory: your email suite, your site's contact form, your invoicing software, your booking system, your newsletter platform, your CRM, your e-signature tool, your online store. Each one sends showing your domain. Each one therefore has to be authorized in your SPF and sign with DKIM under your domain, or it fails DMARC and gets quarantined the day you raise the policy.

Two limits break that inventory silently. A domain can have only one applicable SPF record; find two and the check returns a permanent error, taking both configurations down together. And an SPF record can't trigger more than ten DNS lookups during evaluation. The include, a, mx, ptr, exists and redirect terms all count, including the ones nested inside your vendors' records, whose contents you never see. Go over: permanent error, the whole SPF is dead. You connect a seventh tool, your interface reports nothing, and your mail starts falling.

Which is why order matters. You don't raise the DMARC policy first. You read the reports, authorize each legitimate sender one at a time, confirm nothing unexplained is left, and only then tighten.

What DMARC will not do for you

A p=reject policy protects your exact domain name. It does not protect your brand, and the standard is candid about it: display-name attacks and visually similar domain names are out of scope.

In practice, a fraudster who registers your-company.net instead of your-company.ca, or who simply puts "Your Company Accounting" as the display name in front of some anonymous Gmail address, sails past your DMARC without touching it. You've closed one door, the most used one. Others remain, and they belong to lookalike-domain monitoring and staff training, not to DNS.

Checking it yourself, in ten minutes

You don't need to buy anything to find out where you stand. Google's Admin Toolbox Check MX takes a domain name and reports critical problems, missing DKIM or DMARC, and the IP ranges your SPF actually authorizes with the include terms resolved. One trap worth knowing: to check DKIM it needs your selector, the record prefix, which is google by default on Workspace. Without it, the tool reports no DKIM on a domain that has one.

Then send a message to a Gmail address you control and open the original. The Authentication-Results line gives you all three verdicts at once.

Finally, if your DMARC has no rua tag, add one today pointing at a dedicated mailbox. The reports arrive as compressed XML, unreadable by eye, and several free services render them in plain language. It's the only way to know who is sending in your name right now, and you almost always find at least one tool nobody in the company knew was still active.

What to take away

The three records are not three checkboxes of equal weight. SPF and DKIM are technical prerequisites: they authenticate a machine and a message, not your name. DMARC is the only one protecting the identity your clients see, and it protects nothing until it reaches quarantine.

The work isn't publishing the records, that's an afternoon. The work is knowing every tool that sends in your name, authorizing them properly, then raising the policy while watching the reports. It's the same quiet maintenance as your site's security: nothing blinks when it's missing, until the day a quote doesn't arrive.

→ Have your email setup checked in an audit