SPF, DKIM, DMARC: why your emails end up in spam

A quote that never arrives makes no noise: the client does not reply, and you assume they are hesitating. Very often the message is sitting in their spam folder, because it could not prove that it really came from you. Three records, SPF, DKIM and DMARC, provide that proof. Here is what they do, how to put them in place without breaking anything, and how to check that they work.

By Tony Alastrue 10 min read

7 chapters2 animated mock-ups

Key points
  • Email does not prove the sender: SPF, DKIM and DMARC, published in your DNS, give mail providers that proof.
  • Since February 2024, Gmail and Yahoo require SPF or DKIM from every sender, and all three from bulk senders.
  • Start with DMARC in monitoring mode with reports, read them, then tighten the policy: never the other way round.

An email does not prove who sent it

Email was designed at a time when networks trusted one another. Nothing in the way it originally works prevents anyone from writing "From:" followed by your address: it is as easy as writing a false return address on the back of an envelope. Lacking proof, Gmail, Outlook and Yahoo judge every message on clues: who is really sending it, from which server, with what reputation. When the clues are missing, caution wins, and your quote joins the spam folder.

The symptom is always the same, and it is misleading. A client tells you they never received your invoice; a reminder also vanishes into thin air. Nothing tells you that anything failed: the message did leave, your software shows it in your sent items, and no bounce notice comes back. It is this silence that costs the most, because you search everywhere else for a long time before looking at your domain name.

Three records, published in the DNS of your domain name, address this problem: SPF, DKIM and DMARC. The DNS is the public directory of the internet, the one that says which server your website and your mailbox belong to; here, you add lines of text to it that any mail provider can read. These records do not guarantee that a message reaches the inbox, but their absence is, more and more often, enough to keep it out. They cost nothing, are set up once, and above all require you to know who sends what in your name.

Three mechanisms, three questions

Each of the three answers a different question, and one does not replace another. SPF asks: was this server allowed to send for this domain? DKIM: was this message signed by this domain, and left unaltered on the way? DMARC: does what SPF and DKIM checked match the address the reader sees, and what happens if not? Three successive gates, in short, each stamping its seal on the envelope.

Fig. 1 Three records published in your domain's DNS. The receiving mail service checks them one after the other before choosing between the inbox and spam.

SPF: the list of authorised servers

SPF (Sender Policy Framework, defined by RFC 7208) is a line of text that begins with v=spf1 and lists the servers allowed to send for your domain: your mailbox, your newsletter tool, your invoicing software if it sends on its own. It ends with an instruction for everything else: ~all, the soft fail, which asks receivers to treat a server missing from the list with suspicion, or -all, the hard fail, which asks them to reject it. The receiving provider looks at which machine the message came from and checks that it appears on the list. One detail matters: SPF checks the technical return address, the one to which undelivered messages come back, and not the address shown in "From:".

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail, RFC 6376) works like a seal. Your sending server signs every message with a private key, which it keeps secret; the matching public key is published in your DNS, under a name called a selector (for example default._domainkey followed by your domain). The receiving provider checks the signature against this public key. If it matches, two things are proven: the message comes from a server that holds your domain's key, and its content was not altered on the way. A 2048-bit key is the usual recommendation today.

DMARC: the rules of the game, and the report

DMARC (RFC 7489) links the other two to what the reader sees. It requires at least one of the two checks to pass and to be "aligned", meaning that it concerns the same domain as the address shown in "From:". It then tells mail providers what to do on failure: p=none (change nothing, observe), p=quarantine (file it as spam) or p=reject (refuse the message). Finally, through the rua= address, it lets you receive aggregate reports: regular summaries, sent by mail providers, that say which servers sent in your name and with what result. It is the only reliable way to discover the senders you had forgotten.

What Gmail, Yahoo and Outlook now require

For a long time, these records were a matter of good practice. Since February 2024, Gmail and Yahoo have made them a requirement: a sender who does not authenticate sees their messages filtered, delayed or refused. The rules are aimed first at bulk sending, but they also set a floor for everyone.

  • For every sender: SPF or DKIM in place on the sending domain. This is the minimum, and a business that sends its quotes from its own domain is affected.
  • For those who send more than 5,000 messages a day to Gmail: SPF, DKIM and DMARC together, with a domain aligned with the address shown.
  • For the marketing messages of these bulk senders: one-click unsubscribe, in addition to a clearly visible unsubscribe link in the message.
  • A low complaint rate: Google recommends staying below 0.1% of messages reported as spam, and never reaching 0.3%.

In 2025, Microsoft announced comparable requirements for high-volume senders to its consumer mail services, including Outlook.com. A small business does not reach these volumes, but it does not escape them either: its messages are judged with the same tools, and a domain that proves nothing starts at a disadvantage, even for a single quote. It is therefore better to set up all three records once and for all than to wonder every year whether the threshold applies to you.

Setting it up, step by step

The technical part fits in a few lines; the difficult part is the inventory, because it is almost never only the tools you think of that send in your name. Here is the order we follow, which avoids blocking a legitimate sender while trying to protect the others. Allow a few weeks between the first and the last step: that is the time needed to read the reports, not to type the lines.

  1. Take stock

    List everything that sends with your domain name: mailbox, newsletter, invoicing software, website form, booking tool, online shop. Each of them will have to appear in SPF or sign with DKIM.

  2. Publish a single SPF

    Gather all these services into one single v=spf1 record, using the include: entries that each of them gives in its documentation. End with ~all until the inventory has been confirmed.

  3. Turn on DKIM everywhere

    In each service, look for the domain authentication page: it gives you the public key and the selector to publish. Do it for your mailbox as well as your newsletter, otherwise only some of your messages will be signed.

  4. Publish DMARC in monitoring mode

    Add, under _dmarc followed by your domain, a line such as v=DMARC1; p=none; rua=mailto: followed by an address you will actually read. Nothing changes for your messages yet, but the reports start to arrive.

  5. Read the reports

    For a few weeks, spot the servers that send in your name and fail: it is often a tool missed during the inventory. Fix them, until the only failures left are senders you do not recognise.

  6. Tighten the policy

    Move to p=quarantine, keep observing, then to p=reject if everything is in order. At that point, a fraudster who spoofs your address sees their messages turned away.

Aggregate reports arrive as technical files, usually daily, and hard to read with the naked eye; specialised services format them and flag the failures. What matters is having an address that receives them and someone who looks at them. A report nobody reads protects nothing.

The pitfalls that undo everything

These records are short, and that is what makes them fragile: a one-character error is enough to make them useless, without the slightest warning. Here are the mistakes we come across most often when we take over a domain. All of them can be checked in a few minutes, provided you know where to look.

  • Two SPF records. A domain may only have one; when a new tool adds a second one instead of extending the first, the check fails, whichever server is sending.
  • More than ten lookups in SPF. Each include: triggers DNS lookups, and the standard caps them at ten: beyond that, SPF fails outright, for all your mail.
  • A DMARC record with no report address. p=none without rua= protects nothing and tells you nothing. We experienced it on our own domain: the record was there, valid, and perfectly useless.
  • A website that cannot send. Some hosting providers block, as an anti-spam measure, connections from a website to mail ports. The error message tells you at which stage sending failed: a timeout points to the network, an authentication refusal points to the credentials.

Checking, end to end

The simplest check is free and done from your own mailbox. Send a message to a Gmail address you own, open it, then choose "Show original" from the message menu. At the top of the page, Gmail shows the result for SPF, DKIM and DMARC: each one should read PASS. Repeat the test for every sending tool, because each of them takes its own route.

Fig. 2 Fictional example: the same quote, sent twice. Without authentication, nothing proves it comes from you; with the three records, the mail service can verify it.

But a PASS does not tell the whole story. In our own case, a message left, arrived and passed the checks, while a missing header damaged the link it contained: the recipient clicked on a link that led nowhere. An email that arrives does not prove that it arrives correctly.

For larger volumes, Google Postmaster Tools gives an overview: domain reputation, complaint rate, authentication results on the messages received by Gmail. The tool asks you to prove that you own the domain, and only shows data above a certain sending volume. A small business can do without it at no cost; one that sends a newsletter to a large list would do well to open it every month.

Beyond authentication

SPF, DKIM and DMARC prove who you are; they say nothing about what you send. A mail provider also judges behaviour: complaints, addresses that no longer exist, the interest recipients show in your messages. A perfectly authenticated domain can therefore still end up in spam if it writes to people who are not expecting it.

  • Send from your own domain, never from a free email address: it is your domain that carries the records, and therefore your reputation.
  • Keep a stable sender name, the same from one mailing to the next, so that your clients recognise it at a glance. It is part of your identity just as much as your logo, as we explain in our article on identity systems.
  • Include a visible unsubscribe link in every marketing message. A reader who cannot find how to leave clicks "Report spam", and it is your reputation that pays.
  • Never buy an address list. These lists mix dead addresses, spam traps and people who never asked for anything: a few mailings can be enough to damage a domain's reputation.
  • Clean out addresses that bounce. An address that returns a permanent error should leave the list: writing endlessly to dead addresses is a signal that mail providers watch.

This work is invisible, and that is why it gets neglected. It is part of what we put in place for every house in our email discipline, before the first campaign and before the first quote; the form on your website is just as concerned, because a well-built website sends its messages from your domain, signed. A carefully written message that never arrives is worth nothing; an authenticated message finally starts working for you.

Before a message can be read, it has to be believed.

This week

What you can do this week

Tick as you go: nothing is saved, it is simply a reminder.

The author Tony Alastrue Founder and director

Founder and director of Digital Air Media, a digital creation house opened in Paris in 2017. He writes here what the house applies to its own pages before offering it to others.

空

Start with a complimentary audit

Leave us your website and a word about your project. A director studies it and replies to you personally within twenty-four hours: what holds your visitors back, what we would do, and whether your house can join us. It is the first door of admission, and it commits you to nothing.

Book a 15-minute call

Would you rather present everything in detail? Open the admission file