SPF, DKIM and DMARC: Email Security for Your Domain

The problem: forged senders

The email protocol lets any server enter any sender address it likes. A fraudster can easily send a message from "[email protected]" even though they have nothing to do with your company. This spoofing is the basis of many phishing attacks: your customers receive what looks like a genuine invoice with false bank details.

Your own deliverability suffers at the same time. Without authentication, receiving servers find it hard to tell real emails from forged ones. When in doubt, your legitimate emails end up in the spam folder as well. SPF, DKIM and DMARC solve both problems together.

SPF: which servers may send for your domain?

The Sender Policy Framework (SPF, RFC 7208 from April 2014) is a TXT record in your domain's DNS. It lists the servers and services that are allowed to send emails on behalf of your domain. The receiving server compares the sender's IP address with this list.

example.com.  IN  TXT  "v=spf1 mx include:_spf.mailanbieter.example ip4:203.0.113.10 -all"

This record allows your own mail servers (mx), all servers of an email provider (include) and a single IP address. The -all at the end means that every other server is not authorised. With ~all (softfail), recipients only mark such emails as suspicious.

Two rules matter here. Each domain may have only one SPF record. In addition, RFC 7208 says that evaluating it may trigger no more than ten DNS lookups; every include, a and mx counts towards that limit. If you connect many services, such as a newsletter tool, a shop and a ticket system, you quickly hit this limit, and then SPF fails completely.

DKIM: a digital signature for every email

DomainKeys Identified Mail (DKIM, RFC 6376 from September 2011) relies on cryptography. Your mail server signs every outgoing message with a private key. You publish the matching public key in DNS. The recipient's server uses it to check whether the signature is correct and whether the content was changed on the way.

mail2026._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

"mail2026" is the selector, a name you choose freely. This lets one domain have several DKIM keys, for example one for the mailbox and one for the newsletter service. You usually do not generate the key yourself: your email provider shows you the record in its customer area, and you copy it into DNS. One big advantage of DKIM is that the signature usually stays valid when a message is forwarded, while SPF often fails in that case.

DMARC: rules and reports

Domain-based Message Authentication, Reporting and Conformance (DMARC) builds on SPF and DKIM. The record tells the recipient what to do with emails that fail both checks and where to send reports.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

p is the policy, and rua is the address for aggregate reports. With sp you can set a separate policy for subdomains.

Alignment: the domains have to match

DMARC checks more than SPF and DKIM do on their own. It requires the checked domain to match the visible sender address in the "From" field. This is called alignment. An example: your newsletter service sends in the background with its own domain and signs with its own DKIM key. SPF and DKIM pass, yet only for the service's domain, which is not example.com. DMARC therefore fails. The fix is a DKIM signature with your own domain, which almost all sending services offer. It is enough if either SPF or DKIM passes and matches the sender domain.

Roll it out in stages: none, quarantine, reject

• p=none: the recipient does not change how mail is delivered, but sends you reports. Leave this stage running for a few weeks.
• Analyse the reports: the rua reports are XML files. They show which servers send in your name and whether SPF and DKIM pass. Forgotten senders often turn up here, such as the website's contact form, the accounting software or a printer.
• p=quarantine: once all legitimate senders are properly authenticated, emails that fail land in the spam folder.
• p=reject: the recipient refuses such emails entirely. Only this stage protects your domain effectively against spoofing.

Moving to reject too quickly puts your own invoices or newsletters at risk of no longer arriving. So only go one stage further when the reports are clean.

What Gmail and Yahoo have required since February 2024

Stricter rules have applied at Gmail since 1 February 2024. All senders need SPF or DKIM, a valid reverse DNS record (PTR) for the sending server and a TLS connection. The spam rate should stay below 0.3 percent. Anyone sending more than 5,000 emails a day to Gmail addresses also needs SPF, DKIM and DMARC. The DMARC policy may be set to none, but the alignment has to be correct. Marketing emails also need one-click unsubscribe.

Yahoo introduced similar requirements for bulk senders at the same time, also with DMARC at least on p=none. It does not state a fixed volume threshold. For your newsletter, this means that without proper email authentication it reaches these providers less reliably or not at all. How newsletters fit into content planning is covered in the article Content marketing strategy.

Protecting domains that send no email

Many companies own several domains, such as typo variants or domains for old projects. Fraudsters can forge emails through these as well. For a domain that never sends email, these records are enough:

example.com.         IN  TXT  "v=spf1 -all" _dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject" example.com.         IN  MX   0 .

The SPF record permits no server at all. DMARC rejects everything, including for subdomains. The so-called null MX record under RFC 7505 shows that the domain does not receive email either. You do not need a DKIM key for a domain like this.

The standards behind SPF, DKIM and DMARC

• SPF: RFC 7208, April 2014
• DKIM: RFC 6376, September 2011, Internet Standard STD 76
• DMARC: originally RFC 7489 from 2015. In May 2026 the IETF published a revised version in three parts: RFC 9989 (the protocol itself), RFC 9990 (aggregate reports) and RFC 9991 (failure reports). They replace RFC 7489.

For existing records with v=DMARC1, p and rua, the revision changes little in everyday use. Older tags such as pct are no longer part of it. For providers of email services, Germany's Federal Office for Information Security (BSI) has also published Technical Guideline TR-03182 on email authentication.

Checking SPF, DKIM and DMARC

A DNS query shows you whether your records are correct. On macOS and Linux you can use dig:

dig TXT example.com +short dig TXT _dmarc.example.com +short dig TXT mail2026._domainkey.example.com +short

On Windows, nslookup works:

nslookup -type=TXT _dmarc.example.com

Looking at a real email gives you an even more precise picture. Send yourself a message to a Gmail mailbox and open "Show original" there. Gmail displays PASS or FAIL for each of SPF, DKIM and DMARC. The email records are also part of a full check, as we describe in the article Check website security. If you are working on your domain right now, the security headers are the next step.

Summary

SPF names the permitted servers, DKIM signs the messages, and DMARC ties both together with a rule and delivers reports. Set up SPF and DKIM first, start DMARC with p=none and tighten the policy as soon as the reports no longer show unknown senders. Remember the domains that send no email as well. You will find more on the subject on our topic page Email Security.

Sources: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 and RFC 9989, 9990 and 9991 (DMARC, May 2026), RFC 7505 (Null MX); Google, Email sender guidelines (in effect from 1 February 2024); Yahoo Sender Hub, requirements for bulk senders (2024); BSI TR-03182; RFC Editor, metadata for RFC 7489 (replaced by RFC 9989–9991).