What is email security for a domain?
The email protocol lets any server enter whatever sender address it likes. A fraudster can therefore easily send a message from [email protected] without having anything to do with the company. This spoofing is the basis of many phishing attacks, for example an invoice that looks genuine but carries the wrong bank details.
Your own deliverability suffers too. Without authentication, receiving servers find it hard to tell genuine emails from forged ones. When in doubt, legitimate emails end up in the spam folder as well. Email security at domain level therefore means the records you use to prove which messages really come from you.
Open standards sit behind all three methods: SPF is described in RFC 7208 from April 2014, DKIM in RFC 6376 from September 2011. DMARC was originally defined in RFC 7489 from 2015. In May 2026 the IETF published a revised version in three parts, RFC 9989, 9990 and 9991. For email service providers, Germany's Federal Office for Information Security (BSI) has also issued Technical Guideline TR-03182 on email authentication.
How do SPF, DKIM and DMARC work?
All three methods run through records in your domain's DNS. When a mail server receives a message, it looks up these records. It compares the sender's IP address with the SPF list, verifies the DKIM signature against the published key and then reads the DMARC rule. If the message passes none of the checks in a way that matches the sender domain, the server applies the rule and reports the result to you.
Stricter rules have applied at Gmail since 1 February 2024. All senders need SPF or DKIM, a valid reverse DNS record (PTR) and a TLS connection, and the spam rate should stay below 0.3 percent. Anyone sending more than 5,000 emails a day to Gmail addresses needs SPF, DKIM and DMARC with matching alignment; the policy may be set to none. Marketing emails need one-click unsubscribe. Yahoo introduced similar requirements for bulk senders at the same time, without naming a fixed volume threshold.
The key building blocks
SPF
The Sender Policy Framework is a TXT record that lists the servers and services allowed to send for your domain. At the end, -all stands for hard rejection of all other servers and ~all for a soft marking. Each domain may have only one SPF record. According to RFC 7208, evaluating it may trigger no more than ten DNS lookups.
DKIM
With DomainKeys Identified Mail, your mail server signs every outgoing message with a private key. You publish the public key in DNS under a selector. The recipient uses it to check whether the signature is valid and whether the content was changed in transit. When messages are forwarded, the signature usually stays valid, whereas SPF often fails in that case.
DMARC
DMARC builds on SPF and DKIM. The record under _dmarc sets the policy with p and the address for aggregate reports with rua. With sp you define a separate rule for subdomains. Older tags such as pct are no longer part of the revised version.
Alignment
DMARC requires the checked domain to match the visible sender address in the "From" field. If a newsletter service sends with its own domain and its own key, SPF and DKIM pass, yet DMARC still fails. The fix is a DKIM signature with your own domain, which almost all sending services offer.
Domains that send no email
Typo domains or domains from old projects can also be misused for forged emails. For them, an SPF record "v=spf1 -all", a DMARC rule with p=reject and sp=reject and a null MX record under RFC 7505 are enough. Such domains do not need a DKIM key.
Common mistakes
- Two SPF records for the same domain.
- Too many include entries: above ten DNS lookups, SPF fails completely.
- Forgotten senders such as the website's contact form, the accounting software or a printer.
- DMARC set to reject straight away: your own invoices or newsletters then stop arriving.
- DMARC left on none for good: the domain stays without effective protection against spoofing.
- Newsletters sent without a DKIM signature for your own domain.
- Unused domains without protective records.
How to check
A DNS query shows whether your records are correct. On macOS and Linux you can use dig, for instance dig TXT example.com +short for SPF and dig TXT _dmarc.example.com +short for DMARC. You look up the DKIM record with its selector, for example selector._domainkey.example.com. On Windows, nslookup -type=TXT _dmarc.example.com works.
A real message gives a more precise view. Send yourself an email to a Gmail inbox and open "Show original" there. Gmail displays PASS or FAIL for SPF, DKIM and DMARC.
The DMARC reports sent to the rua address are XML files. They show which servers send in your name and whether SPF and DKIM pass. Let p=none run for a few weeks and evaluate the reports. Move to quarantine, and later to reject, only once no unknown legitimate senders appear any more.
Articles on this topic
Frequently asked questions
In what order should I set up SPF, DKIM and DMARC?
SPF and DKIM first, then DMARC with p=none. After you have evaluated the reports, quarantine follows, and later reject.
Does DMARC work without DKIM?
Technically yes, if SPF passes and matches the sender domain. Because SPF often fails with forwarding, DKIM is still worth having.
Do I need DMARC for a domain that sends no email?
Yes. With "v=spf1 -all" and p=reject you stop fraudsters from using this domain for forged emails.
Do Gmail's rules also apply to small senders?
Yes, in part. SPF or DKIM, a PTR record, TLS and a low spam rate apply to all senders. At Gmail, DMARC becomes mandatory above 5,000 emails per day.
Sources: IETF RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 and RFC 9989, 9990 and 9991 (DMARC), RFC 7505 (null MX); Germany's Federal Office for Information Security (BSI), Technical Guideline TR-03182; Gmail sender requirements; Yahoo sender requirements.