Why does a domain that never sends email still need SPF and DMARC?

Because an attacker does not care what you use the domain for. The From field of an email is free text, so phishing in your domain's name is always possible. Receiving mail servers check the DNS records of the sender domain; if there are none, there is no basis to refuse the forgery and it often lands straight in the inbox.

Which DNS records lock down a domain that sends no email?

Three records: an SPF record "v=spf1 -all" (nobody may send on behalf of this domain), a null MX record "0 ." per RFC 7505 (this domain receives no email) and a DMARC record "v=DMARC1; p=reject; sp=reject" (reject everything that fails the checks, including on subdomains). Optionally, an empty wildcard DKIM record completes the set.

What is the difference between SPF, DKIM and DMARC?

SPF is a list of servers allowed to send on behalf of your domain. DKIM is a cryptographic signature that lets the receiver verify the message really came from your domain and was not altered in transit. DMARC ties both to the visible sender address and tells the receiver what to do when the checks fail: deliver, send to spam or reject. On top of that, DMARC delivers reports on who is sending as your domain.

What do p=none, p=quarantine and p=reject mean in a DMARC record?

That is the policy you give receiving mail servers for messages that fail the checks. p=none means report only, block nothing: a good starting point. p=quarantine sends failing mail to the spam folder. p=reject refuses it entirely and is the end goal. A DMARC record left on p=none for years protects nobody in practice.

What is a null MX record?

An MX record with priority 0 and a single dot as its value: "0 .". It is the standardised way (RFC 7505) to state that a domain receives no email. Sending servers see that immediately and abort the attempt at once, instead of retrying for days against a domain where no mail server will ever answer.

Should I also set up MTA-STS, DANE or BIMI?

Only after SPF, DKIM and DMARC are in order. MTA-STS and DANE secure the transport between mail servers with enforced TLS; the Dutch government encourages DANE through its comply-or-explain list and internet.nl tests for it. BIMI shows your logo next to authenticated mail and requires DMARC at p=quarantine or p=reject; it is the cherry on top, not a security control in itself.

How do I check whether my mail records are set up correctly?

With the free test at internet.nl, a service run by the Dutch government, you can check SPF, DKIM, DMARC, STARTTLS, DANE and DNSSEC per domain. Do this for every domain you have registered, not just your main one. If you want the records watched continuously rather than tested once, monitoring such as Exposentry can do that.

Back to knowledge base

SPF, DKIM and DMARC explained: why domains that never send email need these records too

Published on July 17, 2026

Sending a phishing email that appears to come from your domain costs an attacker nothing. The From field of an email is a free text field, just like the sender on an envelope: anyone can put anything there. The email protocol SMTP dates from 1982 and verifies nothing by itself. Everything that makes email reasonably trustworthy today was bolted on later, and it lives in your DNS: SPF, DKIM and DMARC.

This article explains those three records with concrete examples, plus the blind spot that almost every explainer skips: domains that do not send any email at all. Those are exactly the ones attackers like to abuse, and exactly the ones you can lock down completely with three small records.

How a receiving mail server decides

When a mail server receives a message claiming to come from yourdomain.com, it looks up in that domain's DNS what the owner has published about it. Is this sending server allowed to do this? Does the signature check out? And what does the owner want me to do if it does not? The three core records answer precisely those three questions. If the records are missing, the receiver has no basis to refuse anything, and a forgery lands in the inbox surprisingly often.

SPF: who may send on behalf of your domain

An SPF record (Sender Policy Framework) is a TXT record on the domain itself, containing the list of servers allowed to send on its behalf:

yourdomain.com.  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.10 -all"

include: points to the SPF list of a service that sends for you, such as Google Workspace or Microsoft 365.
ip4: (or ip6:) allows a specific IP address, for example your own mail server or an application that emails invoices.
-all at the end says: everything else is not allowed. The softer variant ~all ("softfail") merely marks violators as suspicious; use -all where you can.

Two things that commonly go wrong. First, an SPF check may cost at most 10 DNS lookups; if you stack too many include entries (every SaaS service wants in), you cross that limit and SPF fails silently. Second, SPF checks the envelope sender address, not the From address the recipient actually sees. An attacker can therefore pass SPF on a domain of their own while the visible From field shows yours. Only DMARC closes that gap.

DKIM: the cryptographic signature

DKIM (DomainKeys Identified Mail) has the sending server sign every message with a private key. The matching public key is published in DNS, under a so-called selector:

selector1._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."

The receiver fetches the public key and verifies the signature over the most important headers and the message body. If it checks out, the message provably went through an authorised server and was not altered in transit. Unlike SPF, DKIM also survives mail forwarding, because the signature travels inside the message itself.

The selector (here selector1) is set by your mail provider; every service that sends on your behalf gets its own selector and key pair. In practice, setting up DKIM usually means copying the records your provider has prepared for you.

DMARC: policy, reporting and the link to the From address

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the capstone. It lives as a TXT record on the _dmarc subdomain:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-reports@yourdomain.com"

DMARC does three things that SPF and DKIM do not do on their own.

It ties the checks to the visible sender address. A message only passes DMARC if SPF or DKIM passes and the verified domain matches the domain in the From field. This is called alignment. It takes the trick described above (passing SPF on a different domain) off the table.

It gives the receiver a policy. The p= field has three settings, deliberately designed as a growth path:

p=none: report only, block nothing. The right starting point to first see who is actually sending on behalf of your domain.
p=quarantine: failing messages go to the spam folder.
p=reject: failing messages are refused. This is the end goal.

A record that sits on p=none for years is a measuring instrument, not a lock. Plan the move to quarantine and then reject as soon as the reports show your legitimate mail flows are in order.

It delivers reporting. Via rua= you receive daily aggregate XML reports from the large mail providers: which servers sent on behalf of your domain, and how the checks turned out. Those reports are essential for growing safely towards reject, and far easier to read through one of the many (also free) DMARC reporting tools than by hand.

Two deeper points that most explainer pages skip. The sp= field sets the policy for subdomains; without sp=, subdomains inherit the p= policy. Setting sp=reject explicitly also closes off invoice.yourdomain.com and every other invented subdomain, a favourite route for phishers. And with adkim=s and aspf=s you set alignment to strict: the domain must then match exactly, rather than a subdomain also counting. Strict is safer, but check your reports first to make sure no legitimate flow breaks.

The blind spot: domains that never send mail

Now for the part most organisations never think about. Almost every organisation owns domains that send no email: defensive registrations of the brand name under other extensions, the domain of an old campaign or a discontinued product line, the holding company, the domain once registered for a project. The reasoning quickly becomes: no mail, so no mail records needed.

That reasoning is wrong, because the attacker does not ask your domain for permission. Phishing in the name of oldcampaign.com works technically just as well as phishing in the name of your main domain, and the brand behind it is the same. In fact, the domain without records is the more attractive target, because the receiving server then has nothing to refuse the forgery on. Your main domain with a tight DMARC policy is closed; the forgotten sibling next to it is wide open.

Fortunately, a domain that never sends mail is also the easiest to secure. Three records, set once, done:

1. An SPF record that authorises nobody:

yourdomain.com.  TXT  "v=spf1 -all"

No server whatsoever may send on behalf of this domain. Every attempt hard-fails the SPF check.

2. A null MX record (RFC 7505):

yourdomain.com.  MX  0 .

An MX record with priority 0 and a single dot as its destination is the standardised way of saying: this domain receives no email. Sending servers abort immediately instead of knocking for days, and the domain becomes instantly implausible as a reply address in phishing.

3. A DMARC record that rejects everything, subdomains included:

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

Since no legitimate mail exists, there is no need for a growth path here: straight to reject, strict, subdomains included. The rua= address may point to a mailbox on your main domain and is useful even here: every incoming report line is by definition an abuse attempt, and you want to know about it.

To make it complete, add an empty wildcard DKIM record (*._domainkey.yourdomain.com. TXT "v=DKIM1; p="), which explicitly invalidates every conceivable DKIM selector.

This checklist applies to every registered domain, not just the ones you look at daily. In practice, the inventory is the real work: which domains does the organisation actually own? Forgotten registrations are a classic piece of shadow IT in your external attack surface, and what you have no view of, you cannot lock down either.

Modern additions: transport, logo and certificates

SPF, DKIM and DMARC govern who may send. A second generation of standards secures the transport and the presentation. To be honest about priorities: as long as the three core records are not in order, these additions add little. After that, they are genuinely worthwhile.

MTA-STS and TLS-RPT: enforcing TLS between mail servers. Mail between servers is usually encrypted (STARTTLS), but that encryption is opportunistic by default: an attacker who can tamper with the traffic can strip out the upgrade to TLS. MTA-STS lets you publish that your domain only accepts mail over verified TLS. It consists of a TXT record plus a policy file at a fixed HTTPS address:

_mta-sts.yourdomain.com.  TXT  "v=STSv1; id=20260717000000"

with a file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt containing, among other things, mode: enforce and your mail servers. The companion reporting standard TLS-RPT notifies you when delivery could not meet that requirement:

_smtp._tls.yourdomain.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

DANE: TLS anchored in DNSSEC. DANE achieves the same goal as MTA-STS, but through a TLSA record in DNS itself, cryptographically protected by DNSSEC rather than by an HTTPS file. An example for a mail server:

_25._tcp.mail.yourdomain.com.  TLSA  3 1 1 8bd1c...

DANE requires working DNSSEC on the domain, which makes it the more robust but more demanding variant. In the Netherlands this is no exotic standard: STARTTLS and DANE are, alongside SPF, DKIM, DMARC and DNSSEC, on the comply-or-explain list of the Dutch Standardisation Forum for government bodies, and internet.nl tests for it by default. Major Dutch mail receivers have supported it for years.

BIMI: your logo next to authenticated mail. BIMI displays your brand logo next to your messages in Gmail, Yahoo and Apple Mail, among others (Outlook does not participate). It requires DMARC at enforcement level (p=quarantine with pct=100, or p=reject), a logo in the SVG Tiny PS format and, for most providers, a certificate: a VMC (based on a registered trademark) or, more recently, a CMC (based on demonstrable long-term logo use). BIMI is the cherry on top: it rewards good authentication with visibility, but secures nothing by itself.

CAA: which authorities may issue certificates. Not a mail record, but the same principle of declaring who may act on behalf of your domain:

yourdomain.com.  CAA  0 issue "letsencrypt.org"

With this, only the named certificate authority may issue certificates for your domain, reducing the risk of wrongly issued certificates.

DNSSEC as the foundation. All the records above live in DNS, and without DNSSEC, DNS answers can be forged. DNSSEC signs your DNS zone, so a receiver knows for certain that the SPF or TLSA record it fetches really came from you. For DANE it is a hard requirement, for everything else a sensible foundation. At most registrars it is a checkbox.

Check it yourself, then keep watching

You do not have to take any of this on authority: internet.nl, a free service run by the Dutch government, tests your domain on nearly everything in this article, from SPF and DMARC to STARTTLS, DANE and DNSSEC. Run that test for every domain you have registered, not just the main one. Why that free check and continuous monitoring complement each other is covered in internet.nl is free, so when do you need Exposentry.

Bear in mind that these records are visible to an attacker too: DNS is public, and missing mail records show up painfully clearly in any reconnaissance of your domain. What else is visible from the outside is described in what does an attacker see of your domain.

Exposentry's scans check these records as part of the job: if SPF, DKIM or DMARC is missing on a domain, it appears as a finding in your report, with a reference to this article. The actual setup is done by you (or your IT partner) at your DNS provider, and it is one-time work. The value of monitoring lies in keeping watch: records that quietly break during a DNS migration, a new domain going live without records, a DMARC policy left stuck on p=none. Exactly the kind of silent decay a monthly report does catch and a one-off check does not.

Written by Edward Hasekamp, founder of Exposentry and core maintainer of the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.