The five DNS records that protect your email

11 June 2026 · 15 min read

Email was designed in an era of trust. The original protocol, SMTP, lets any server on the internet claim to send mail as anyone. There is no built-in check that the server connecting to a recipient is actually allowed to send for the domain in the From address. That gap is why phishing, business email compromise and brand impersonation have stayed profitable for decades, and it is why a small set of DNS records now does the work the protocol never did.

Those records are SPF, DKIM, DMARC, MTA-STS and BIMI. They are not five different products you buy. They are five TXT and CNAME entries you publish in your domain's DNS, each solving one specific part of the problem, and each building on the one before it. Published correctly and in the right order, they turn your domain from something anyone can forge into something receiving servers can verify, enforce and even decorate with your logo.

This article is a tour of all five: what each record looks like, what it actually does, and how they lock together into a single defence. If you want to see where your own domain stands right now, run it through the free DMARC checker before you read on, then come back and work through what each result means.

The problem all five records solve

Picture an email arriving at a recipient's mail server. The message says it is from billing@yourcompany.com. The receiving server needs to answer three questions before it decides whether to deliver it to the inbox, drop it in spam or reject it outright:

1. Did this message come from a server your company actually authorises?
2. Has the message been tampered with in transit, and can the sending domain prove it owns the content?
3. If the answer to either is no, what does your company want the receiver to do about it?

SPF answers the first question. DKIM answers the second. DMARC answers the third, and ties the first two to the address your recipients actually see. MTA-STS and BIMI then build on top: one protects the connection that carries the mail, the other rewards a verified, enforced domain with a logo in the inbox.

Crucially, none of these records changes how your email is sent. They are published instructions that receiving servers read out of DNS. You keep your existing mail provider, your existing sending tools and your existing addresses. For background on the order in which to deploy them, see the enforcement journey.

Record one: SPF, the list of who may send

SPF stands for Sender Policy Framework. It is a single TXT record published at the root of your domain that lists the servers and services permitted to send mail using your domain in the SMTP envelope. A receiving server reads it, looks at the IP address that actually connected, and checks whether that address is on the list.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.20 -all

Reading it left to right:

• v=spf1 declares the record version. Every SPF record starts this way.
• include:_spf.google.com delegates to Google's own SPF record, authorising Google Workspace to send for you.
• include:sendgrid.net does the same for a marketing or transactional provider.
• ip4:198.51.100.20 authorises one specific server by its address, perhaps an on-premise application that sends invoices.
• -all is the all-important closing mechanism. The - means hardfail: anything not matched above is not authorised, full stop. A ~all (softfail) is weaker and says "probably not authorised". For a domain heading towards enforcement, you want -all.

There are two traps with SPF that catch nearly everyone. The first is the ten DNS lookup limit. Every include and a few other mechanisms cost a DNS lookup, and the specification caps you at ten. Exceed it and the whole record returns a PermError, which is treated as no SPF at all. If you have stacked up Google, Microsoft, a CRM, a help desk and a newsletter tool, you can blow through ten lookups easily. We cover the fix in detail in SPF too many DNS lookups, and one durable solution is SPF flattening, explained in how SPF flattening works.

The second trap is publishing two SPF records. The specification permits exactly one TXT record beginning v=spf1 per domain. A second one is also a PermError. People hit this when they add a new provider's record alongside the old one instead of merging the include into the existing record. If you suspect either problem, the SPF checker will count your lookups and flag duplicates, and fix multiple SPF records walks through the cleanup.

SPF's weakness on its own is that it validates the envelope sender (the hidden MAIL FROM address used during transmission), not the From address your recipient sees. A forger can pass SPF for their own throwaway domain while still displaying your brand in the visible From. SPF alone, therefore, does not stop impersonation. It needs DMARC to connect it to the visible address, which we come to shortly.

Record two: DKIM, the cryptographic signature

DKIM stands for DomainKeys Identified Mail. Where SPF checks the connecting server, DKIM proves two things at once: that the message genuinely originated from a domain that holds a private key, and that the important parts of the message have not been altered since they were signed.

DKIM works as a public-key signature. Your mail provider holds a private key and uses it to sign each outgoing message. It adds a header to the email, something like:

DKIM-Signature: v=1; a=rsa-sha256; d=yourcompany.com; s=selector1;
  h=from:to:subject:date; bh=<body hash>; b=<signature>

The matching public key is published in your DNS as a TXT record at a predictable name built from the selector:

selector1._domainkey.yourcompany.com.  TXT  "v=DKIM1; k=rsa; p=<long base64 public key>"

When a message arrives, the receiver reads the d= (the signing domain) and s= (the selector) from the signature header, fetches the public key from DNS, and checks the signature against the message. If it matches, two facts are established: the listed domain signed this mail, and the signed headers and body are intact.

A few practical points worth knowing:

• The selector is just a label that lets you run several keys at once, for example one per sending service, and rotate them without downtime. Different providers use different selector names, which is why DKIM is checked per selector. See DKIM selectors explained.
• Each sending service signs with its own key. Google Workspace, Microsoft 365 and your newsletter tool each publish a separate selector record. You may have three or four DKIM records live at once, and that is normal.
• Key length matters. A 1024-bit key is weak by modern standards; 2048-bit is the sensible default. We compare them in DKIM key length: 1024 vs 2048.
• Keys should be rotated periodically, which the selector system makes painless. See DKIM key rotation.

DKIM's strength is that the signature travels with the message. Even if the email is forwarded, the signature can still validate, because it is attached to the content rather than tied to the connecting IP. That is also DKIM's importance for forwarded mail, where SPF tends to break. To confirm a selector is published and well formed, use the DKIM checker, and for a deeper walk through the setup, read what is DKIM and the DKIM setup doc.

Like SPF, DKIM on its own does not bind the result to the visible From address, and a passing DKIM signature for some unrelated domain does not protect your brand. That binding is the job of the third record.

Record three: DMARC, the policy that ties it together

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is the keystone of the whole arrangement. DMARC does three jobs that nothing else does: it requires alignment, it states a policy, and it asks receivers to send you reports.

A DMARC record is a single TXT entry published at a fixed name, _dmarc.yourcompany.com:

_dmarc.yourcompany.com.  TXT  "v=DMARC1; p=reject; rua=mailto:reports@yourcompany.com; adkim=s; aspf=s"

The key tags:

• v=DMARC1 is the version, always first.
• p= is the policy: what a receiver should do with mail that fails DMARC. The three values are none (take no action, just observe), quarantine (treat as suspicious, usually spam folder) and reject (refuse delivery outright). The progression from none to reject is the heart of a safe rollout, covered in DMARC policy: none, quarantine, reject.
• rua= is where aggregate reports are sent. This is the data feed that makes a safe rollout possible.
• adkim and aspf set alignment strictness, s for strict and r for relaxed.

The concept that makes DMARC powerful is alignment, and it is the piece most people miss. DMARC does not just ask "did SPF pass?" and "did DKIM pass?". It asks whether the domain that passed matches the domain in the visible From address. SPF can pass for the forger's own envelope domain, and DKIM can pass for some unrelated signer, but neither helps an attacker unless they also align with the From address your recipient reads. A message passes DMARC if either SPF passes and aligns, or DKIM passes and aligns. It needs only one of the two to align, but it needs at least one. This is exactly why you sometimes see a message where SPF and DKIM both pass yet DMARC fails: neither passing identity lined up with the From domain. We unpack that confusing case in DMARC fails but SPF and DKIM pass and alignment generally in DMARC alignment explained.

The reporting half of DMARC deserves emphasis because it is what makes enforcement safe rather than reckless. Once you publish a rua address, the world's large mailbox providers start sending you daily XML summaries of every source sending mail that claims to be your domain. You learn which of your own services are correctly authenticated, which are not yet configured, and which are outright impersonators. Only when those reports show that all your legitimate mail is passing do you move the policy up. Raw XML is hard to read, so feed it into the DMARC report analyzer to see sources, pass rates and alignment in plain terms.

The single most important and most misunderstood fact about DMARC is this: p=none provides no protection. It tells receivers to do nothing. It is a listening mode, useful and necessary as the first step, but a domain that sits at p=none for years is still wide open to forgery. The whole point is to graduate to p=reject. The reason this matters so much, and why so many domains stall, is laid out in the false security of p=none. The careful, no-outage path from observation to enforcement is in getting from none to reject safely and the broader enforcement journey.

To check your current DMARC record and its policy, the DMARC checker parses every tag and flags weak settings. For the foundational explanation, see what is DMARC and the DMARC record explained.

With SPF, DKIM and DMARC in place and enforced, your domain is protected against forgery of the From address. The final two records protect a different layer and add a visible reward.

Record four: MTA-STS, securing the connection itself

The first three records prove who sent a message. MTA-STS protects how it travels between servers. It stands for Mail Transfer Agent Strict Transport Security, and it closes a gap that has nothing to do with content forgery and everything to do with eavesdropping.

When one mail server delivers to another, it normally tries to upgrade the connection to TLS encryption using a command called STARTTLS. The problem is that STARTTLS is opportunistic: if an attacker positioned between the servers strips the STARTTLS offer out of the conversation, both servers silently fall back to plain, unencrypted text. This is a downgrade attack, and the receiving server never knows it happened. MTA-STS lets you say: for my domain, encryption is mandatory, and if it cannot be negotiated, do not deliver at all.

MTA-STS is unusual among the five because it is published in two places. First, a small TXT record advertises that a policy exists:

_mta-sts.yourcompany.com.  TXT  "v=STSv1; id=20260601000000"

The id is just a version stamp you change whenever you update the policy. Second, the policy itself is served over HTTPS from a fixed URL on a subdomain, https://mta-sts.yourcompany.com/.well-known/mta-sts.txt, and looks like this:

version: STSv1
mode: enforce
mx: mail.yourcompany.com
mx: *.yourcompany.com
max_age: 604800

The mode is the part that matters. testing reports problems without blocking mail, and enforce requires valid TLS to your listed MX hosts or the message is not delivered. As with DMARC, you start in testing, watch for issues, then move to enforce.

MTA-STS has a companion record, TLS-RPT, which asks receivers to report TLS negotiation failures back to you so you can see downgrade attempts and misconfigurations:

_smtp._tls.yourcompany.com.  TXT  "v=TLSRPTv1; rua=mailto:tlsreports@yourcompany.com"

To confirm your policy is reachable and in the right mode, use the MTA-STS checker, and check the reporting endpoint with the TLS-RPT checker. The most common deployment error, a policy file that returns the wrong status or cannot be fetched, is covered in fix MTA-STS policy not found. For step-by-step setup, see the MTA-STS setup doc.

MTA-STS does not authenticate the sender; SPF, DKIM and DMARC already do that. It guarantees that the mail you do send and receive cannot be quietly read or altered by someone sitting on the wire between mail servers.

Record five: BIMI, the logo that rewards enforcement

BIMI stands for Brand Indicators for Message Identification, and it is the only one of the five your customers ever see. Where the others work silently, BIMI puts your verified company logo next to your messages in supporting inboxes such as Gmail, Apple Mail and Yahoo. It is the visible payoff for doing the rest correctly.

BIMI is a TXT record published at a dedicated name:

default._bimi.yourcompany.com.  TXT  "v=BIMI1; l=https://yourcompany.com/logo.svg; a=https://yourcompany.com/vmc.pem"

The two tags:

• l= points to your logo, which must be a specific, tightly constrained form of SVG: SVG Tiny Portable/Secure, square, with a solid background. Ordinary SVGs exported from design tools almost never qualify, which is the most common reason a logo fails to appear.
• a= points to a Verified Mark Certificate (VMC) or, more recently, a Common Mark Certificate. This is a digital certificate from an approved authority confirming that you legitimately own the trademark on the logo. Some inboxes, notably Gmail, require it; some will show a logo without one. We cover the cases in BIMI without a VMC.

Here is the part that makes BIMI matter for this whole article: BIMI does nothing until DMARC is at enforcement. Inboxes will not display a BIMI logo unless your domain is published at p=quarantine or p=reject. This is deliberate. The logo is a trust signal, so it is only granted to domains that have already proven they cannot be forged. BIMI is, in effect, a visible certificate that you completed the first three records properly. It is the reason many organisations finally push from p=none through to p=reject: there is now a marketing-visible reward at the end.

To validate your BIMI record and check that your logo and certificate are accepted, use the BIMI checker. If the logo is correct but not appearing in Gmail, the diagnosis is almost always DMARC enforcement or VMC, covered in fix BIMI logo not showing in Gmail. For the wider question of whether it is worth the certificate cost, see do you need BIMI and the BIMI setup doc.

How the five fit together

Step back and the structure is clean. Each record handles one job, and the chain only works in order:

1. SPF lists which servers may send for your domain, checked against the connecting IP.
2. DKIM cryptographically signs each message, proving origin and integrity, and survives forwarding.
3. DMARC binds SPF and DKIM to the visible From address through alignment, sets the enforcement policy, and feeds you reports so you can reach p=reject without breaking legitimate mail.
4. MTA-STS forces the connections carrying that mail to be encrypted, closing downgrade attacks, with TLS-RPT reporting failures.
5. BIMI rewards a fully enforced domain with your verified logo in the inbox, which is impossible without the first three at enforcement.

The dependency that ties them is alignment and enforcement. SPF and DKIM are necessary but not sufficient on their own: an attacker can pass both for identities that have nothing to do with your brand. DMARC is what turns "this mail authenticated for some domain" into "this mail authenticated for your domain", and its policy is what actually blocks the forgeries. MTA-STS and BIMI then sit either side of that core, one hardening transport, the other surfacing the result to humans.

A complete, healthy domain therefore publishes, at minimum:

• one SPF TXT record at the root, ending -all, under ten lookups;
• one or more DKIM TXT records, one per sending service, at selector._domainkey;
• one DMARC TXT record at _dmarc, ideally at p=reject with a rua address;
• an MTA-STS TXT record at _mta-sts plus the HTTPS policy file, in enforce, with a TLS-RPT record;
• a BIMI TXT record at default._bimi, once DMARC is enforced.

For the exact syntax of every tag in one place, keep the DNS record reference handy, and the glossary explains any term above in isolation. If you are publishing into a specific provider's dashboard, the publish DNS records by provider guide shows where each record goes.

Where most domains actually are, and what to do next

In practice, most domains have a partial setup. SPF is usually present, often with too many lookups or a ~all that should be -all. DKIM is frequently configured for the main mailbox provider but missing for the newsletter tool that sends half the volume. DMARC, where it exists at all, is stuck at p=none, which means it is watching and reporting but blocking nothing. MTA-STS and BIMI are absent. That is a domain that looks protected in a quick glance and is, in reality, still forgeable.

The fix is not to publish all five records in a panic on the same afternoon. It is to go in order, using the reports to confirm each step before the next. Get SPF clean and under the lookup limit. Get DKIM signing every legitimate source. Publish DMARC at p=none, read the reports until every real sender is passing and aligned, then move through quarantine to reject. Only then layer on MTA-STS for transport security and BIMI for the visible logo.

If you would rather not hand-edit DNS and watch XML reports for weeks, that sequencing is exactly what DMARC Engine automates. It takes a domain from p=none to p=reject safely, with no email outage, hosting each of these records for you and emailing you monitoring as the reports come in. You can see the per-record products at /products/spf, /products/dkim, /products/dmarc, /products/mta-sts and /products/bimi, and review the platform requirements at /requirements.

Whichever route you take, start by measuring. Run your domain through the DMARC checker, the SPF checker and the DKIM checker, and you will know within a minute which of the five records you have, which are wrong, and which are missing. From there, the order of work is the order of this article.