SPF, DKIM and DMARC explained: why your emails land in spam

Email was designed in an era when nobody checked who was sending it, and the basic protocol still lets any server put any address in the From line. SPF, DKIM and DMARC are the three records that fix that: SPF lists the servers allowed to send for your domain, DKIM signs each message so it can be checked on arrival, and DMARC tells receiving servers what to do when those checks fail. Since February 2024 Gmail and Yahoo have required them from anyone who sends in volume, and Outlook.com has since May 2025. Even below those thresholds, a domain without them is the first one to land in spam. This guide explains each record and shows what ours look like on levelui.com, levelui.ro and levelui.de.

Why email needs three records

When a message arrives, the receiving server knows only what the sending server told it. The From address is just text, and nothing in the original email protocol stops a stranger from writing your address there. Spammers and fraudsters rely on exactly that, so mailbox providers have learned to distrust any message whose domain cannot prove it sent it. The proof is published in your domain’s DNS, where only you can change it, and it comes in three parts that each cover a gap the others leave.

This matters for more than newsletters. The invoices you send, the replies to enquiries, the order confirmations from your shop and the notification your website’s contact form sends you are all email from your domain. If the records are missing or wrong, any of those can land in spam or be refused, usually without anyone noticing until a customer says they never got it.

SPF: who is allowed to send

SPF, the Sender Policy Framework, is a single TXT record on your domain that lists the servers allowed to send mail for it. Ours reads v=spf1 include:_spf.mail.hostinger.com ~all: mail for levelui.com may come from the servers our email host lists, and anything else should be treated with suspicion. The ending matters. ~all asks receivers to mark other mail as suspicious, -all asks them to reject it, and with DMARC in place either works.

Every service that sends as your domain has to be in that one record: your mailbox, the newsletter tool, the CRM, the invoicing app and the website if it sends mail itself. Two rules catch people out. A domain may have only one SPF record, so a second one added by a new service breaks both. And SPF allows at most 10 DNS lookups while it is evaluated; every include counts, includes inside includes count too, and past 10 the check fails outright with a permanent error. Ours uses three of the 10: our one include, plus the two relay services Hostinger’s own record includes in turn.

DKIM: a signature that survives the journey

DKIM, DomainKeys Identified Mail, adds a digital signature to every message. The sending server signs the important headers and the body with a private key, and publishes the matching public key in DNS under a name called a selector. The receiving server fetches that key and checks the signature: if it matches, the message really was sent by someone holding your key, and nothing in the signed parts changed on the way.

Unlike SPF, a DKIM signature survives forwarding, because it travels inside the message rather than depending on which server delivered it. Gmail requires keys of at least 1,024 bits for bulk senders; 2,048 is the sensible choice. Ours use the selector hostingermail1 and 2,048-bit keys on all three domains. Each service you send through needs its own DKIM key under your domain. If a newsletter tool signs with its own domain instead, the signature is valid but does not count for you, which is the most common reason DMARC fails.

DMARC: the policy that ties them together

SPF and DKIM can both pass while DMARC fails, because DMARC checks that they passed for the domain in the From line. That requirement is called alignment. A newsletter sent through a provider’s servers and signed with the provider’s domain passes SPF and DKIM for the provider, not for you, so DMARC fails for your domain. At least one of the two has to pass for the same domain the reader sees.

The record then says what to do with mail that fails: p=none means deliver it and only report, p=quarantine means put it in spam, and p=reject means refuse it. The rua address receives daily aggregate reports from the big providers, listing every server that sent mail as your domain and whether it passed. Ours is p=quarantine on all three domains, and the reports for levelui.ro and levelui.de go to an address on levelui.com. Sending reports to another domain only works if that domain agrees, so levelui.com publishes small authorisation records named levelui.ro._report._dmarc.levelui.com and levelui.de._report._dmarc.levelui.com. Without them, the reports for the two country domains would simply not arrive.

DMARC was revised in May 2026 as RFC 9989. The revision drops the pct tag, which applied a policy to only a percentage of mail, and adds a t tag for testing. Our records still carry pct=100, which asked for the full policy anyway, so nothing changes for them.

What Gmail, Yahoo and Outlook now require

The second table above sums it up. Every sender to Gmail or Yahoo needs at least SPF or DKIM, and anyone sending 5,000 or more messages a day to personal accounts needs SPF, DKIM and a DMARC record, with the From domain aligned and a one-click unsubscribe on marketing mail. Outlook.com set the same bar for high-volume senders from 5 May 2025 and refuses failing mail with error 550 5.7.515. Gmail began tightening enforcement on non-compliant mail in November 2025.

A small business sending a few hundred messages a day is below the bulk threshold, but that is not a reason to skip any of the three. The filters that read these records run on every message, and a domain without DMARC is also the easiest one for someone else to impersonate. Setting all three up takes an hour and costs nothing.

How to set them up, in order

Start with an inventory: every service that sends email with your domain in the From line, including the website, the shop, the CRM, the newsletter tool and the invoicing software. Then publish one SPF record that includes all of them, and turn on DKIM in each service, which usually means adding one or two DNS records the service gives you. Check both with a test message: in Gmail, Show original lists the SPF, DKIM and DMARC result for any message you receive.

Publish DMARC at p=none first, read the reports for two to four weeks, and only then tighten it. The reports will show services you forgot, such as an old contact form or a booking tool, still sending as your domain. Fix each one, then move to p=quarantine, and to p=reject once the reports are clean. Jumping straight to reject on day one is how businesses discover a forgotten sender by losing its mail.

Why your emails can still land in spam

Authentication proves who sent a message; it does not make anyone want it. With all three records passing, mail can still land in spam if recipients mark it as spam, if the domain is new and has no sending history, if the message links to domains with a bad reputation, or if the server it comes from is on a block list. Gmail’s Postmaster Tools shows your domain’s spam rate and reputation for free once you verify the domain.

Website mail is a frequent culprit. Contact forms on shared hosting often send through the web server itself rather than through your mailbox, from a server your SPF record does not list and without your DKIM signature. Sending form mail through your real mail account over SMTP fixes it. If you are choosing a domain for a new business, our guide on how to choose a domain name is worth reading first, and if the site runs on shared hosting, VPS vs shared hosting explains what that account can and cannot do.

A last step: your logo in the inbox

Once DMARC is at quarantine or reject, a fourth record called BIMI can point to your logo, and some mailbox providers show it next to your messages. Ours is live on all three domains. Yahoo and AOL show it from the record alone; Gmail and Apple Mail show a logo only with a paid certificate on top. It is not needed for delivery, but it is a small, visible reward for having the other three right.

Sources

Requirements from each mailbox provider’s own pages, and record formats from the published standards, checked on 28 October 2026. Our own records were read from public DNS the same day.

• Google Workspace Admin Help — Email sender guidelines ↗

  Requirements for all senders and for senders of 5,000+ messages a day; DKIM keys of at least 1,024 bits; spam rate below 0.3%; error 5.7.26.

• Google Workspace Admin Help — Email sender guidelines FAQ ↗

  Gmail ramps up enforcement on non-compliant traffic from November 2025.

• Yahoo Sender Hub — Sender best practices ↗

  Requirements for all senders and bulk senders from February 2024; unsubscribes honoured within 2 days.

• Microsoft Support — Fix NDR error 550 5.7.515 in Outlook.com ↗

  The requirements for senders of 5,000+ messages a day to Microsoft consumer mail.

• RFC 7208 — Sender Policy Framework (SPF) ↗

  Section 4.6.4: at most 10 DNS-querying terms, otherwise a permanent error.

• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures ↗

  How the signature and the selector record work.

• RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) ↗

  Published May 2026 on the Standards Track; obsoletes RFC 7489 and removes the pct tag.

• RFC 7489 — DMARC, section 7.1 ↗

  The original definition of the authorisation record for reports sent to another domain.