Since February 1, 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 May 5, 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 on October 22 with the domain of a site we look after, and we use it as the example all the way through, including the record that's wrong. We write its name as domain.com.
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 April 29, 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 the emails in our example come from
Two services. Day-to-day mail goes through Google Workspace, while the emails the 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. The one in our example is:
v=spf1 include:_spf.google.com ~all
That authorizes 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.domain.com, 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 that 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 main 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 missing piece
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.domain.com 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 the domain for its DMARC record and it answers _dmarc.domain.com canonical name = dmarc.ionos.it, and the record it points to says only v=DMARC1; p=none;. Nobody wrote it. It's an alias (CNAME) to the default record of IONOS, the domain's 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 that domain tomorrow, nobody would know. And as long as the alias stays, its DMARC policy lives in a record IONOS manages: to add a rua, whoever manages the domain has to replace the CNAME with a TXT record they write themselves.
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.
- Send 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-Signatureheader,d=is the signing domain ands=is the selector. nslookup -type=TXT yourdomain.comfor SPF: there must be exactly one line starting withv=spf1.nslookup -type=TXT selector._domainkey.yourdomain.comfor each DKIM key, using the selector from step 1.nslookup -type=TXT _dmarc.yourdomain.comfor DMARC. If nothing comes back, there's no record. If you see acanonical name, as in our example, 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.