An email from invoice@your-company.com looks trustworthy at first glance. But did it really come from your mail server?
This is exactly where one of email's fundamental problems lies: classic SMTP was never designed to reliably verify that a sender really is who they claim to be. Microsoft explicitly describes this same underlying issue: a normal SMTP message doesn't automatically validate the claimed sender.
That's what makes forged sender addresses possible. Attackers might try sending messages with senders like accounting@company.com, support@company.com, ceo@company.com, or invoice@shop.com — even though the message never went through those domains' actual mail servers.
To let receiving mail servers detect this kind of manipulation, three important mechanisms exist: SPF, DKIM, and DMARC. Together, they now form a core part of modern email authentication. Microsoft explicitly recommends deploying SPF, DKIM, and DMARC together, since the mechanisms build on one another.
In this article, you'll learn what these three abbreviations actually mean, why they matter even for small domains, and how to check your own email security.
What are SPF, DKIM, and DMARC?
In simplified terms, you can remember the three mechanisms like this:
| Mechanism | Job |
|---|---|
| SPF | Which servers are allowed to send email for my domain? |
| DKIM | Was this email actually cryptographically signed, and was it altered in transit? |
| DMARC | Do the visible sender and the authentication line up — and what should happen if they don't? |
Or even simpler: SPF controls the sending path. DKIM controls the signature. DMARC controls how the two work together.
What is SPF?
SPF stands for Sender Policy Framework. With SPF, a domain owner publishes in DNS which systems are allowed to send email for that domain.
The current SPF standard is described in RFC 7208. The receiving mail server can use it to check whether the sending host is authorized for the MAIL FROM domain being used.
A simplified SPF record might look like this:
v=spf1 ip4:203.0.113.10 include:_spf.mailprovider.example -allThis roughly means: the listed IP address and the servers of the included mail provider are allowed to send email for this domain. No other systems are.
Where does the SPF record live?
SPF is published as a TXT record in DNS. On Linux or macOS you can check it with dig:
dig TXT example.comOr alternatively:
host -t TXT example.comOn Windows:
nslookup -type=TXT example.comThe SPF standard requires publication via DNS TXT records. It also doesn't allow an arbitrary number of parallel SPF records for the same domain name; multiple simultaneously matching SPF records result in a permanent SPF error.
What do -all and ~all mean?
At the end of many SPF records you'll find -all or ~all. These have different meanings.
-all – fail: senders not listed are not authorized under the SPF policy.
~all – softfail: senders not listed are probably not authorized, but the statement is less strict.
RFC 7208 distinguishes between pass, fail, softfail, and neutral, among others. A typical mail provider record might look like this:
v=spf1 include:_spf.example.net ~allWhich setting is correct for your domain depends on which systems actually send email on its behalf.
Common SPF mistake: not all senders accounted for
This is exactly where problems tend to creep in at companies. Regular company email might run through Microsoft 365 or Google Workspace. But the website, a newsletter system, a ticketing system, a CRM, a webshop, a monitoring tool, an invoicing application, a server, or a printer or multifunction device may also be sending email under the same domain.
If one of these systems is missing from the SPF setup, legitimate messages can fail the SPF check at the recipient's end. That's why, before making changes, you should first build a complete list of every system that sends email on behalf of the domain.
Watch out for the SPF lookup limit
Another commonly overlooked point is the number of DNS lookups. SPF allows a maximum of 10 DNS-triggering mechanisms or modifiers per evaluation — things like include, a, mx, exists, or redirect. If that limit is exceeded, SPF evaluation must fail with permerror.
A seemingly harmless SPF record like:
v=spf1 include:provider1.example include:provider2.example include:provider3.example -allcan therefore be more problematic than it looks. Each include can trigger further DNS lookups of its own. Domains with many cloud services in particular should check their SPF record regularly.
What is DKIM?
DKIM stands for DomainKeys Identified Mail. While SPF checks where an email comes from, DKIM works with a cryptographic signature.
When sending, the mail server generates a digital signature and adds it to the email header. The private key stays with the sender. The matching public key is published via DNS.
The receiving mail server can retrieve that key and use it to verify whether the DKIM signature is valid. RFC 6376 describes this mechanism, including publishing the public key via DNS.
DKIM explained simply
Imagine sending a letter. SPF checks: was the letter dropped into an approved mailbox? DKIM additionally checks: does the letter carry the right seal, and was its contents altered after sealing? That's exactly why SPF and DKIM complement each other.
What does a DKIM record look like?
A DKIM key might live at a DNS name like this:
selector1._domainkey.example.comThe TXT record might contain, in simplified form:
v=DKIM1; k=rsa; p=MIIBIjANBgkqh...The long value after p= holds the public key.
What is the DKIM selector?
So a domain can use multiple keys and rotate them, DKIM works with so-called selectors. A DKIM header might include s=selector1 and d=example.com, which produces the DNS lookup selector1._domainkey.example.com.
This enables key rotation without having to switch over all mail operations at once. RFC 6376 specifically provides for this selector concept to support different or rotating keys.
Checking DKIM on Linux
If you know the selector:
dig TXT selector1._domainkey.example.comor:
host -t TXT selector1._domainkey.example.comOn Windows:
nslookup -type=TXT selector1._domainkey.example.comImportant: the selector isn't always selector1. Depending on the mail provider, it might be google, default, selector1, selector2, mail, dkim, s1, or s2. You'll normally find the actual selector in your mail provider's configuration, or in the DKIM-Signature header of a message you've sent.
What is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. DMARC ties SPF and DKIM to the domain the recipient actually sees in the visible From: field of the email.
This detail matters a lot. A message could technically pass a valid SPF check — but for a completely different domain than the one shown to the user as the sender. That's why DMARC introduces what's called domain alignment.
The current DMARC standard has been RFC 9989 since May 2026. It replaces, among other documents, the previously well-known RFC 7489.
What does DMARC alignment mean?
Say a message shows From: invoice@example.com. But DKIM signs with d=some-mail-service.example, and SPF also only authenticates a different domain.
SPF or DKIM can technically succeed — yet that doesn't automatically produce a successful DMARC check. DMARC requires that at least one successfully authenticated identity be aligned with the visible sender domain.
RFC 9989 distinguishes between relaxed alignment and strict alignment. Under relaxed alignment, the same organizational domain is often enough, while strict alignment requires an identical domain.
What does a DMARC record look like?
A simple DMARC record might read:
v=DMARC1; p=none; rua=mailto:dmarc@example.comIt's published at _dmarc.example.com. On Linux, you can check it with:
dig TXT _dmarc.example.comor:
host -t TXT _dmarc.example.comOn Windows:
nslookup -type=TXT _dmarc.example.comWhat do p=none, p=quarantine, and p=reject mean?
The most important part of a DMARC setup is the policy.
p=none (v=DMARC1; p=none): DMARC is evaluated, but the domain doesn't request any special handling of failing messages. This setting is best for the analysis phase.
p=quarantine (v=DMARC1; p=quarantine): if a DMARC check fails, the domain signals to the recipient that the message should be treated as suspicious — for example, routed to spam or quarantine.
p=reject (v=DMARC1; p=reject): this signals the strictest policy for messages that fail DMARC.
Important, though: a DMARC policy is just one part of the receiving system's decision-making. The current RFC explicitly notes that mail receivers may also weigh additional information and local scoring.
Why shouldn't you jump straight to p=reject?
Because you might have forgotten a legitimate sender. For example: website → external SMTP service → email with your domain. Or: CRM → cloud mail provider → customer.
If SPF, DKIM, or alignment is misconfigured for such a service, a stricter DMARC policy could affect legitimate email. Google likewise recommends getting SPF and DKIM working correctly first, before enabling or tightening DMARC.
A sensible path looks like this: configure SPF and DKIM → set DMARC to p=none → watch the reports → fix errors → move to p=quarantine → keep watching → eventually p=reject if appropriate.
What is rua in DMARC?
A DMARC record might include rua=mailto:dmarc@example.com. rua defines the address or URI for aggregate DMARC reports. RFC 9989 explicitly defines rua as the destination for Aggregate Feedback Reports.
These reports help you see which systems use your domain, which IP addresses are sending mail, whether SPF, DKIM, and DMARC are passing, and whether unknown systems are using your domain. This reporting mechanism is exactly what makes DMARC so useful for administrators.
SPF + DKIM + DMARC explained together
Here's the simplified overall flow: an email is sent → the recipient checks SPF (is the sending server allowed?) → the recipient checks DKIM (is the signature valid?) → the recipient checks DMARC (does SPF or DKIM align with the visible From domain?) → DMARC pass/fail → spam filtering, reputation, and other security checks.
SPF, DKIM, and DMARC are important building blocks — but they're not a replacement for spam filters, malware protection, or other security mechanisms. Microsoft, for instance, also uses reputation, sender history, recipient history, and behavioral analysis to evaluate incoming messages.
Checking SPF, DKIM, and DMARC directly in an email
A test with an actually sent message is especially reliable. Send an email from your domain to an external mailbox, then view the full header.
You'll often find a section like this:
Authentication-Results:
spf=pass
dkim=pass
dmarc=passThat would be a very good result. Problematic examples would be spf=fail, dkim=none, dmarc=fail, or spf=permerror. Microsoft also documents SPF, DKIM, and DMARC evaluation via the Authentication-Results header.
For a correctly configured domain, you ideally want to see something like: SPF: PASS, DKIM: PASS, DMARC: PASS. That already gives you a very solid foundation for your email authentication.
Why SPF alone isn't enough
A common misconception is: "I have an SPF record, so my domain is protected." That's not quite true.
SPF mainly checks the MAIL FROM (envelope) domain used during SMTP delivery. The From: address visible to the user is a different part of the email. That's exactly why DMARC is needed. Microsoft also points out that SPF alone isn't enough to reliably prevent spoofing of the visible sender domain.
Why DKIM alone isn't enough
A valid DKIM signature initially only means that a particular domain took responsibility for the signature, and that the signed parts weren't tampered with, undetected, after signing. The DKIM signature doesn't have to match the visible sender domain automatically. Only DMARC establishes the link between the authenticated domain and the From domain the user actually sees.
Google, Yahoo, and Microsoft are raising the bar
SPF, DKIM, and DMARC are no longer just a topic for particularly security-conscious admins. Large mail providers have been tightening their requirements for several years.
Google requires at least SPF or DKIM for senders to personal Gmail addresses. For bulk senders with more than 5,000 messages a day, additional requirements apply: SPF, DKIM, and DMARC must all be set up.
Yahoo likewise requires at least SPF or DKIM for all senders, with stronger authentication — including SPF, DKIM, and DMARC — for larger senders.
Microsoft also enforces stricter rules for high-volume senders to its consumer mail services. Starting at 5,000 messages under the same From domain, Microsoft expects SPF and DKIM as well as a published DMARC record and successful DMARC alignment.
The takeaway is clear: in 2026, email authentication is no longer just an optional security nicety. For any professional domain, it's part of the technical baseline.
Common mistakes with SPF, DKIM, and DMARC
Mistake 1: multiple SPF records
For example v=spf1 include:provider1.example -all alongside v=spf1 include:provider2.example -all. That's not a sensible way to configure multiple providers. Under the SPF standard, multiple simultaneously matching SPF records result in permerror. The sending sources you need must be merged into a single valid SPF setup.
Mistake 2: forgetting the newsletter provider
Regular email runs through Microsoft 365, but the newsletter comes from an external provider. If that service isn't authenticated correctly, SPF, DKIM, or DMARC problems follow.
Mistake 3: the website sends mail directly
Many web servers send form or shop emails directly via PHP, local mail services, or external SMTP relays. These systems need to be accounted for too.
Mistake 4: DMARC stays on p=none forever
p=none is great for observation. Once you've identified your legitimate senders and fixed all the errors, you should check whether a stronger policy makes sense. Otherwise you get reports, but you never realize DMARC's full protective potential.
Mistake 5: DMARC without reporting
A record like v=DMARC1; p=none works on its own. But adding a reporting target like rua=mailto:dmarc@example.com gives the domain owner far more insight into how the domain is actually being used.
A practical email security check
If you want to check your domain, this order works well.
1. Check SPF
dig TXT example.comQuestions to ask: does SPF exist? Are all legitimate mail servers included? Is there only one valid SPF record? Is the DNS lookup limit respected?
2. Check DKIM
First, send a test email. Look in the header for a DKIM-Signature: entry, and note the selector and domain. Then run:
dig TXT selector._domainkey.example.com3. Check DMARC
dig TXT _dmarc.example.comAt minimum, you should find a valid record, e.g. v=DMARC1; p=none; rua=mailto:dmarc@example.com.
4. Send a test email
Then check the header for spf=pass, dkim=pass, dmarc=pass.
5. Review DMARC reports
Check known senders, unknown sending servers, SPF errors, DKIM errors, alignment problems, and possible spoofing attempts. These DNS lookups can also be bundled neatly into a reusable diagnostic script, which ChatGPT can build for you on request. Write Shell Scripts with ChatGPT (Read article)
Matching product · German-language edition
Cyberangriffe mit KI abwehren
A 576-page security package with cheat sheets on phishing, cloud security, and email-based attacks — useful for embedding email authentication into a broader security strategy.
Can SPF, DKIM, and DMARC prevent phishing entirely?
No. These mechanisms mainly reduce the success rate of abusing your domain as a forged sender. An attacker could still register a similar-looking domain. yourcompany.com could, for example, become a deceptively similar look-alike domain.
That's why a comprehensive email security strategy also needs spam and phishing filters, malware protection, secure user accounts, multi-factor authentication, employee training, domain monitoring, strong passwords or passkeys, and regular security updates.
SPF, DKIM, and DMARC form an important technical layer of protection, but they don't replace a complete email security strategy. Modern mail providers likewise combine authentication data with many other security signals.
Do small businesses need DMARC too?
Yes. The question shouldn't be "Do we send enough email to bother with DMARC?" It should be: "Is our domain important enough that no one should be able to use it to send forged email?"
A small accounting firm, a trade business, or an online shop might send only a few hundred emails a month. A forged message like "Please transfer the invoice to our new account" can still cause serious damage. Email authentication isn't just useful for large corporations and newsletter senders.
If a forged payment request like that actually gets delivered, or a mailbox is compromised, what matters most is how quickly and how methodically you respond. The Cyber Notfall Reaction Plan (View product) includes prepared immediate-response steps for compromised Microsoft 365 accounts, among other scenarios.
Matching product · German-language edition
Cyber Notfall Reaction Plan
A 7-day incident response plan with immediate-action steps and checklists for compromised Microsoft 365 accounts, invoice fraud, and other email-based security incidents.
Conclusion: SPF, DKIM, and DMARC belong on every professional domain
SPF, DKIM, and DMARC sound like complicated admin plumbing at first. But the underlying idea is simple: SPF says who's allowed to send. DKIM cryptographically proves a message was signed correctly. DMARC checks whether the authenticated identity matches the visible sender domain, and publishes a policy for what to do when checks fail.
If you use your own domain for email, you should at minimum check that all three mechanisms are set up correctly. The target result is: SPF: PASS, DKIM: PASS, DMARC: PASS.
Precisely because Google, Yahoo, and Microsoft have tightened their requirements for authenticated email, clean email authentication in 2026 matters both for IT security and for reliable mail delivery. If you use ChatGPT more broadly to work through diagnostic commands and logs, you'll find more examples in How I Use ChatGPT for Linux Administration (Read article).
Frequently asked questions about SPF, DKIM, and DMARC
What's more important: SPF, DKIM, or DMARC?
The three mechanisms serve different purposes and should be used together. SPF authorizes sending sources, DKIM signs messages, and DMARC checks the alignment with the visible sender domain.
Where are SPF, DKIM, and DMARC stored?
This information is published through DNS. SPF and DMARC use TXT records; DKIM also typically publishes its public key via DNS.
Can I check SPF with nslookup?
Yes. On Windows, for example, with nslookup -type=TXT example.com. For DMARC, use nslookup -type=TXT _dmarc.example.com.
How do I know if DKIM is working?
Send a test email and inspect the full email header. A result like dkim=pass indicates a successful DKIM check.
What does a DMARC pass mean?
DMARC passes when a matching authenticated identity exists and the required domain alignment with the visible sender domain is met.
Should I switch to p=reject right away?
Not without prior analysis. SPF and DKIM should be working correctly first, and all legitimate sending sources should be known. DMARC can then be tightened step by step.
Is DMARC mandatory in 2026?
That depends on the recipient and sending volume. Google requires SPF, DKIM, and DMARC for bulk senders sending more than 5,000 messages a day to personal Gmail accounts. Microsoft has comparable requirements for high-volume senders to its consumer mail services, and Yahoo has similar requirements for bulk senders.
What is the current DMARC standard?
Since May 2026, RFC 9989 has been the current DMARC standard. It replaces, among others, RFC 7489.
Sources and technical references
The technical claims in this article draw on current specifications and documentation from IETF, Google Workspace, Microsoft, and Yahoo Sender Hub. The current DMARC standard, RFC 9989, was published in May 2026 and replaces RFC 7489; SPF is based on RFC 7208 and DKIM on RFC 6376. Fact-checked as of: August 21, 2026.