All articles

SPF, DKIM and DMARC: How to make sure business emails arrive

Published · 10 min read

Listen to the article · read by an AI voice

An invoice, an offer or a reply to a customer is only useful if it arrives. Receiving mail servers have learned not to trust a message just because it names a sender. Three DNS records of your domain, called SPF, DKIM and DMARC, are how you prove that a mail really comes from you.

The topic matters for every business with its own domain. Google and Yahoo have enforced rules for senders since February 2024. Without these records, your mail risks landing in the spam folder or being rejected. This article explains what each record does, what the large providers require, and how to introduce the records in an order that does not endanger your regular mail.

Why emails land in spam: a sender without proof

Imagine you send an invoice from info@your-company.ge. The receiving server sees only the claim: this mail is from your-company.ge. Anyone can write that address into the From: field, and that is exactly what fraudsters do. The receiver cannot verify the claim. It is like a letter with a company letterhead but no signature and no postmark.

A server that cannot verify a sender has to guess, and it guesses cautiously. The invoice goes to the spam folder or is refused. The three records answer three different questions:

  • SPF: Did the mail come from a server that is allowed to send for this domain?
  • DKIM: Was the mail signed by the domain and left unchanged on its way?
  • DMARC: What should the receiver do if the checks fail, and where should it report back?

SPF: which servers may send for the domain

SPF (Sender Policy Framework) is a TXT record of your domain that starts with v=spf1. It lists the servers that may send mail for the domain. The receiver compares the server that delivered the mail with this list.

The SPF record of esn.ge reads exactly:

v=spf1 mx include:_spf.webhosting.systems include:_spf.protonmail.ch -all

The parts mean:

  • v=spf1 marks the record as SPF.
  • mx allows the servers named in the MX records of the domain, which are the servers that receive its mail.
  • include: adds the allowed servers of another domain. Here there are two such entries.
  • -all says that all other servers fail the check.

There is one technical limit you should know. According to RFC 7208, section 4.6.4, the evaluation of an SPF policy may not exceed 10 terms that need a DNS lookup. The query for the SPF record itself does not count. The limit applies to the whole evaluation, so every include: and every mx uses up part of this budget. If you keep adding services, check the total after every change.

DKIM: the signature of every email

DKIM (DomainKeys Identified Mail) works like a seal. The sending server signs each mail with a private key that never leaves the server. It adds the signature in a DKIM-Signature header. That header names the signing domain (d=) and a selector (s=). The selector is a label that allows a domain to use several keys side by side.

The receiving server uses these two values to find the matching public key in the DNS. It reads a TXT record whose name is made of the selector, ._domainkey. and the domain, and checks the signature with it. If the check succeeds, the mail was signed by the domain and was not altered on the way.

The record has this form. The names are placeholders for illustration only, and the dots stand for the key:

mail._domainkey.your-company.ge   TXT   "v=DKIM1; k=rsa; p=…"

Here mail is an example selector, k=rsa names the key type and p= is followed by the public key. Your mail provider generates the key pair and tells you the record to publish.

Key length matters. Google states: “Sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer.” If your mail provider created an older, shorter key, ask for a new one.

DMARC: what happens to mails without valid proof, and the reports about it

SPF and DKIM each deliver a result, but neither says what a receiver should do with a failure. DMARC adds that rule. It is a TXT record at _dmarc. in front of the domain, for example _dmarc.your-company.ge.

A mail passes DMARC when SPF or DKIM passes and the domain checked is aligned with the domain in the From: header. Alignment closes a gap: without it, a fraudster could pass SPF with their own domain while showing your address in the From: field. The tags aspf=r and adkim=r select relaxed alignment for SPF and DKIM.

The policy p= has three values:

  • p=none only collects reports. Failing mail is treated as before.
  • p=quarantine asks receivers to treat failing mail as suspicious, for example by moving it to the spam folder.
  • p=reject asks receivers to refuse failing mail.

DMARC also sends reports back, and these are its practical benefit. The tag rua names where aggregate reports go. They show which servers sent mail in the name of your domain and how it fared. The tag ruf names where failure reports go, and fo=1 asks for such a report whenever any of the checks fails.

The specification has changed recently. The new DMARC specification, known in the community as DMARCbis, was published in May 2026 as three RFCs: RFC 9989 (the core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). RFC 9989 was published on May 19, 2026 and obsoletes RFC 7489 from 2015 and the experimental RFC 9091. DMARC has moved from Informational status to a Proposed Standard on the IETF Standards Track. Records still start with v=DMARC1, so existing records keep working. One source notes that most production deployments need nothing immediate.

What Google and Yahoo require from senders

Google distinguishes two groups. For all senders who send mail to Gmail accounts, the requirements apply from February 1, 2024:

  • Set up SPF or DKIM for the sending domains.
  • Keep the spam rate reported in Postmaster Tools below 0.3%. The monitoring section of the same page advises staying below 0.10% and never reaching 0.30% or higher.
  • Use a DKIM key of 1024 bits or longer when sending to personal Gmail accounts.

Senders who send more than 5,000 messages per day to Gmail accounts must meet a second, stricter set of requirements, also from February 1, 2024:

  • Set up SPF and DKIM for the domain.
  • Set up DMARC. Google says the policy “can be set to none”.
  • For direct email, the domain in the From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment.
  • Marketing and subscribed messages must support one-click unsubscribe and show a clearly visible unsubscribe link in the body. One-click unsubscribe works with the headers List-Unsubscribe-Post: List-Unsubscribe=One-Click and List-Unsubscribe (RFC 2369, RFC 8058).

Yahoo started enforcing its sender requirements in February 2024. According to Yahoo, enforcement was rolled out gradually while it monitored compliance through the first half of the year. The minimum is: “Implement SPF or DKIM at a minimum.”

Most small businesses are far below 5,000 messages a day. Even so, a sensible aim is to set up all three records. SPF or DKIM is only the lowest bar, and DMARC gives you the reports that show what happens to your mail.

Introduce it step by step: from p=none over p=quarantine to p=reject

DMARC with a strict policy can block your own legitimate mail if a sender has been forgotten, for example the newsletter tool or the web form. That is why the policy is raised in steps:

  1. p=none: Publish the record and collect reports. Read them and check which servers send in the name of your domain. Fix SPF and DKIM for every legitimate sender.
  2. p=quarantine: When the reports show only legitimate mail passing, ask receivers to treat failing mail as suspicious.
  3. p=reject: When quarantine causes no more surprises, ask receivers to refuse failing mail.

The DMARC record of esn.ge is at the middle step and reads exactly:

v=DMARC1;p=quarantine;sp=quarantine;pct=100;rua=mailto:dmarc@reports.epicsoft.email;ruf=mailto:dmarc@reports.epicsoft.email;ri=86400;aspf=r;adkim=r;fo=1;rf=afrf;

The tags are separated by semicolons without spaces. Each part means:

  • v=DMARC1 marks the record as DMARC.
  • p=quarantine is the policy for the domain, and sp=quarantine applies the same policy to its subdomains.
  • pct=100 applies the policy to all mail.
  • rua=mailto:… and ruf=mailto:… send aggregate and failure reports to a reporting address under epicsoft.email.
  • ri=86400 (the reporting interval) and rf=afrf (the report format) come from the old specification.
  • aspf=r and adkim=r select relaxed alignment.
  • fo=1 asks for a failure report when any check fails.

Three tags of this record, pct, ri and rf, are removed in RFC 9989. We list them only because the record still contains them; a new record does not need them.

RFC 9989 also changes the following:

  • The tag t (testing mode) replaces pct. It knows only all (100%) or nothing (0%).
  • The tag np sets the policy for subdomains that do not exist. If it is omitted, the sp policy is used.
  • The tag psd (public suffix domain) is new.
  • The organizational domain is found by a DNS Tree Walk instead of the Public Suffix List.

If mail from web applications is part of your traffic, make sure it leaves through the mail server your records cover. The open-source smarthost of epicsoft (Postfix on Alpine) does this for containers. Applications hand their mail to it, and it delivers the mail to the company’s mail server with authentication and TLS. Its option SMARTHOST_FORCE_FROM rewrites only the visible From: header, not the envelope sender.

In addition: MTA-STS for transport encryption

SPF, DKIM and DMARC protect the sender. MTA-STS protects the route. With it, a domain declares that mail to it must be delivered only over TLS with a valid certificate (RFC 8461). Two parts are needed:

  • A TXT record at _mta-sts. in front of the domain, for example _mta-sts.your-company.ge, that holds v=STSv1 and an id. The id changes whenever the policy changes.
  • The policy itself: the file /.well-known/mta-sts.txt, served over HTTPS on the subdomain mta-sts of the domain, with the mode enforce, testing or none.

For esn.ge, _mta-sts.esn.ge is a CNAME to _mta-sts.epicsoft.email. The TXT record there reads exactly:

v=STSv1;id=20261012084000

So esn.ge takes its MTA-STS record from the mail domain epicsoft.email.

How epicsoft sets this up

With the email service of epicsoft networks, the mailboxes and the MX, SPF, DKIM and DMARC records of your domain are created as part of the setup. You can keep your domain: either the records are set up at your DNS provider together with you, or epicsoft manages the DNS. The mail is stored on epicsoft’s own mail servers in Finland and Germany. More services are listed under all services.

Sources

More articles

Ready for the next step?

There has never been a better time to start. Tell us about your project.

Get in touch