Emails going to spam: SPF, DKIM and DMARC without the jargon

Since 1 February 2024 Google has required anyone sending to Gmail to authenticate the domain they send from, and since November 2025 messages that don't comply can be rejected, temporarily or permanently. Microsoft did the same for Outlook.com, Hotmail and Live from 5 May 2025. If a customer finds your quote in their spam folder, check the DNS of the domain you sent it from before you start rewriting the subject line.

We did that with ours on 22 October and we use it as the example all the way through, including the record that's wrong.

What Gmail and Outlook require

Google asks everyone who sends to Gmail for SPF or DKIM, forward and reverse DNS records (PTR) for the sending servers, an encrypted connection and a spam complaint rate under 0.3% in Postmaster Tools. Above 5,000 messages a day you need SPF and DKIM together, a DMARC record (p=none is enough), a sender domain that aligns and, for newsletters, one-click unsubscribe.

Microsoft asks for the same things from anyone over 5,000 messages a day. It first announced that non-compliant mail would go to the junk folder, then in the update of 29 April 2025 decided to reject it instead, with the error 550 5.7.515.

A company sending a few dozen emails a day is under both thresholds, and for Gmail SPF or DKIM is enough. It still needs DMARC, to find out whether someone else is sending in its name.

Where our emails come from

Two services. Day-to-day mail goes through Google Workspace, while the emails our website sends (contact form notifications, reports from the free tools and newsletter confirmations) go out through Resend.

Make the same list for your own domain. It usually comes out longer than expected: the mailbox, the software that sends your invoices, the website, the newsletter. When email lands in spam, the first suspect is a service sending in your name without authentication, like a WordPress contact form that sends from the hosting server with no signature.

SPF: who can send in your name

SPF (RFC 7208) is the list of servers allowed to send for a domain, published in a TXT record. Ours is:

v=spf1 include:_spf.google.com ~all

That authorises Google and nobody else. Resend isn't there because SPF checks the address bounces go back to, and Resend uses one on a subdomain: send.msworks.it, which has its own SPF (v=spf1 include:amazonses.com ~all) and an MX pointing to feedback-smtp.eu-west-1.amazonses.com. Bounces go to Resend, which runs on Amazon SES, and the main domain's SPF stays one line long.

Keeping it short also keeps you away from the 10 DNS lookup limit. Past that number the check fails for every email from the domain, not just for the service you added last. Domains get there by piling up an include for every service they tried over the years and never removed. The other common mistake is two SPF records on the same domain, which also makes the check fail: merge them into one.

DKIM: the signature

DKIM (RFC 6376) signs every email with a private key. The receiving server checks it against the public key in your DNS: if it matches, the message comes from the domain it claims and nobody changed it. The key lives under a name the service picks, called the selector, and our domain has two: google._domainkey for Workspace, at 2048 bits, and resend._domainkey for Resend, at 1024. The standard requires at least 1024 bits and recommends 2048, so Resend's key is valid but sits at the minimum. Both sign with the msworks.it domain, which means the website's emails are aligned for DMARC too.

In Workspace you generate the key in the admin console, publish it in the DNS and then switch it on with «Start authentication»; Google warns it can take up to 48 hours. People forget that last step and end up with a published record and a signature that never starts.

DMARC: the piece we're missing

DMARC tells providers what to do with an email that has your domain in the sender but fails the checks, and where to send reports. It passes if SPF or DKIM passes with a domain aligned with the sender's, and under relaxed alignment, the default, a subdomain like send.msworks.it counts. The policy p= can be none (the provider decides), quarantine (the email is suspicious and usually goes to spam) or reject (it should be refused). The rua tag says where to send aggregate reports: who sent in your name and with what result.

Ask our domain for its DMARC record and it answers _dmarc.msworks.it canonical name = dmarc.ionos.it, and the record it points to says only v=DMARC1; p=none;. We didn't write it. It's an alias (CNAME) to the default record of IONOS, our domain registrar, with policy none and no rua. It meets Gmail's and Outlook's rules, but it sends reports to nobody, and if someone started sending email as msworks.it tomorrow we wouldn't know. And as long as the alias stays, our domain's DMARC policy lives in a record IONOS manages: to add a rua we have to replace the CNAME with a TXT record of our own.

Out of 1.8 million of the world's most visited domains, EasyDMARC counted that 52.2% have no DMARC record at all and only 7.7% have a reject policy.

If your record still uses the pct tag, drop it: RFC 9989, published in May 2026 to replace the old RFC 7489, removed it.

From none to reject without losing email

Start at p=none with a rua address and read the reports for a few weeks. Once all your legitimate email passes, move to quarantine and then to reject, the gradual path Microsoft recommends as well. The typical casualty of skipping the reports and going straight to reject is invoicing software that sends with your address but from its own servers, without a DKIM signature: from that day on, the invoices stop arriving.

How to read your domain's DNS

You need a Gmail inbox and the nslookup command, which ships with Windows, macOS and Linux.

1. 01Send an email from each service to a Gmail address, open it and choose «Show original». At the top you'll see SPF, DKIM and DMARC, each marked PASS or FAIL; in the DKIM-Signature header, d= is the signing domain and s= is the selector.
2. 02nslookup -type=TXT yourdomain.com for SPF: there must be exactly one line starting with v=spf1.
3. 03nslookup -type=TXT selector._domainkey.yourdomain.com for each DKIM key, using the selector from step 1.
4. 04nslookup -type=TXT _dmarc.yourdomain.com for DMARC. If nothing comes back, there's no record. If you see a canonical name, as we do, someone else manages it.

If your emails are going to spam and these checks don't add up, write to us. We'll read your domain's DNS and the originals of the emails you send, and tell you which service is sending without authentication and which one to fix first.