What are SPF, DKIM and DMARC, and why do your emails land in spam?

One day, without anyone touching anything, the quotes you send start landing in your clients’ spam folders. Or a client forwards you an email “from you” asking them to change the bank account for a payment, which you never wrote. Both problems share a root cause: email was designed with no way of checking who sends what.

The protocol email travels over (SMTP) lets any server write whatever sender it likes, in the same way nothing stops you from writing a false return address on an envelope. SPF, DKIM and DMARC are three layers added over the years to close that gap. All three live in your domain’s DNS, and the servers that receive your mail look them up before deciding whether to deliver it, file it as spam or reject it.

SPF: the list of who may send

SPF (Sender Policy Framework) is a TXT record at the root of the domain that lists the servers allowed to send mail on its behalf. It looks like this:

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

It reads from left to right: mail leaving Google Workspace servers is authorised, mail leaving SendGrid is too, and everything else is handled according to the closing term. That closing term matters more than it seems:

• -all: anything not on the list is rejected.
• ~all: anything not on the list is accepted but flagged as suspicious. The most common setting.
• ?all: neutral. In practice it protects nothing.
• +all: authorises everyone. Worse than having no SPF, because it also looks as if there is one.

A detail few people know: SPF does not check the address the recipient sees in the “From” field, but the envelope address (the Return-Path), which is where bounces go. Many sending platforms put their own domain in that envelope, so your SPF can be perfect and still play no part in those messages. That is what DMARC is for, but first comes the signature.

DKIM: the signature that proves nothing was altered

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message. The sending server signs with a private key only it holds, and the public key is published in DNS under a name of the form selector._domainkey.yourdomain.com. The receiver fetches that key, checks the signature and learns two things: that the message was signed by someone with authority over the domain, and that nobody changed it on the way.

The selector is what lets a single domain carry several signatures at once: one for the office mailboxes, another for the newsletter tool, another for the invoicing platform. Each provider picks its own name, which is why there is no way to “list” every DKIM record of a domain from outside: you need to know which selector to look for.

As for key size, 2048 bits is the current recommendation.

DMARC: what to do when something does not add up

SPF and DKIM say whether a message passes or fails a check, but not what to do with it. DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy that decides, and it lives in a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

The p tag sets what happens to mail that fails:

Policy	What happens to failing mail	What it is for
p=none	Delivered anyway	Monitoring and receiving reports
p=quarantine	Sent to spam	Intermediate step
p=reject	Rejected	Full protection

The rua tag is the other half of DMARC’s value: the address to which the large mailbox providers send regular reports listing everything that arrived in your domain’s name, from which servers, and whether it passed. Without rua you see nothing.

The sensible path is to start at none with reports, read them for a few weeks until you have found every legitimate service sending on your behalf (the CRM, the invoicing software, the website’s contact form), set those up properly, then move to quarantine and finally to reject. Jumping straight to reject without that inventory is a quick way to stop your own invoices arriving.

Alignment: the piece that ties the other two together

This is the part that confuses people most, and the one that matters most. DMARC is not satisfied by SPF or DKIM simply passing: it requires them to pass for the same domain the recipient sees in the “From” field. That is alignment.

An example. You send a newsletter from a marketing platform with hello@yourdomain.com as the sender. The platform uses its own domain in the envelope and signs with its own DKIM key. SPF passes (for the platform’s domain) and DKIM passes (also for the platform’s domain), but neither is aligned with yourdomain.com, so DMARC fails. With p=reject, that newsletter never arrives.

The fix is nearly always in the provider’s dashboard: an option called something like “authenticate your domain” or “custom sending domain” that gives you DKIM records, and sometimes a CNAME for the envelope, to publish in your DNS. It is enough for one of the two, SPF or DKIM, to pass and be aligned. Alignment is relaxed by default (aspf=r and adkim=r), so a subdomain such as mail.yourdomain.com counts as aligned with yourdomain.com.

What Gmail and Yahoo have required since 2024

In 2024 Gmail and Yahoo began enforcing requirements that turned these records from good practice into a condition of delivery. Every sender needs SPF or DKIM. Bulk senders (Google puts the threshold at around 5,000 messages a day to Gmail accounts) need considerably more:

• Both SPF and DKIM in place.
• A published DMARC record, even if it is only p=none.
• The “From” domain aligned with SPF or DKIM.
• One-click unsubscribe on marketing mail, and a low rate of spam complaints.

Microsoft announced similar requirements for Outlook in 2025. Even if your business does not send thousands of emails a day, the direction is clear: receivers trust a domain without these three records less and less.

The most common mistakes

Two SPF records. When a new service is added, someone creates a second v=spf1 TXT record instead of editing the existing one. The standard allows only one: with two, the result is an error, which amounts to having none. They need merging into a single record.

Going over ten lookups. Every include, a, mx or redirect in the SPF makes the receiver run a DNS lookup, and providers’ include targets often contain further includes. The limit is ten. Past it, SPF returns a permanent error even though the record looks fine. It happens a lot in businesses that have kept adding tools without removing the ones they stopped using.

DMARC left at none forever. Publishing it was the first step and nobody took the second. While it stays at none, mail spoofing your domain is still delivered.

Forgetting domains that do not send. A domain that never sends email should publish v=spf1 -all and a DMARC record at reject. That way nobody can use it to impersonate you.

Checking yours

The SPF, DKIM and DMARC checker reads the MX, SPF and DMARC records of any domain straight from public DNS, counts the lookups needed to evaluate the SPF against the limit of ten, and explains each finding along with what to do about it. For DKIM you need your provider’s selector; if it recognises who receives the domain’s mail, it suggests which one to try first.

If you have just changed a record and still see the old value, that is DNS caching doing its job. The DNS propagation checker tells you whether the public resolvers already have the new version.

---

Getting these three records right is an afternoon’s work between your DNS dashboard and those of your sending providers. In return, your emails reach the inbox and your domain stops being available to anyone who wants to pass themselves off as you.