TLDR
SPF, DKIM, and DMARC are the three email authentication standards that verify whether an email actually came from the domain it claims to be from. When all three pass, the email was sent by an authorized server. When any fails, the email may be spoofed. Microsoft's January 2026 research revealed that attackers exploit complex email routing and misconfigured authentication to send convincing fakes that pass some checks while failing others. ScamVerify™ checks all three authentication records when you forward a suspicious email to scan@scamverify.ai, cross-referencing the results against 8 million+ threat records to determine whether the email is legitimate.
What Email Authentication Actually Does
Email was invented in the 1970s without any built-in way to verify the sender. Anyone could (and still can) put any address in the "From" field. SPF, DKIM, and DMARC were added decades later to patch this fundamental design flaw.
Think of it this way:
| Authentication | Real-World Analogy | What It Verifies |
|---|---|---|
| SPF | A list of approved mailroom workers | Which servers are allowed to send email for this domain |
| DKIM | A wax seal on a letter | The email content was not altered in transit |
| DMARC | Company policy for handling suspicious mail | What to do when SPF or DKIM fails, and where to report violations |
Together, these three standards answer one question: Did this email actually come from who it claims to be from?
SPF: Sender Policy Framework
How SPF Works
SPF is a DNS record that lists every IP address and server authorized to send email on behalf of a domain. When your email provider receives a message claiming to be from example.com, it checks the SPF record for example.com to see whether the sending server's IP address is on the approved list.
SPF pass: The server that sent the email is on the approved list. The email was sent by someone authorized to use the domain.
SPF fail: The server is not on the approved list. The email may be spoofed.
SPF softfail (~): The server is not approved, but the domain owner has not set a strict policy. Many domains use softfail as a cautious setting, which means SPF failure alone may not cause rejection.
How to Check SPF
To see a domain's SPF record, you can look up the DNS TXT record. The record looks something like:
v=spf1 include:_spf.google.com include:sendgrid.net -all
This tells receiving servers: "Only Google and SendGrid are authorized to send email for this domain. Reject everything else (-all)."
The key settings at the end of an SPF record:
| SPF Qualifier | Meaning | Security Level |
|---|---|---|
| -all | Reject unauthorized senders | Strong (recommended) |
| ~all | Softfail unauthorized senders | Moderate (allows through with marking) |
| ?all | Neutral (no policy) | Weak (no protection) |
| +all | Accept all senders | None (do not use, effectively no SPF) |
SPF Limitations
SPF only checks the "envelope from" address (the technical sending address), not the "header from" address (what you see in your inbox). An attacker can pass SPF with their own domain while displaying a spoofed address in the visible "From" field. This is why SPF alone is not sufficient. DKIM and DMARC address this gap.
DKIM: DomainKeys Identified Mail
How DKIM Works
DKIM adds a digital signature to outgoing emails. The sending server signs the email with a private key, and the receiving server verifies the signature using a public key published in the domain's DNS records.
DKIM pass: The signature is valid. The email content (headers, body) was not modified after the authorized server sent it.
DKIM fail: The signature does not match. The email was either modified in transit or was never signed by the claimed sender.
What DKIM Protects Against
| Threat | DKIM Prevention |
|---|---|
| Content modification | Detects any change to the email body or signed headers |
| Sender forgery | Signature ties the email to a specific domain's private key |
| Replay attacks | Timestamps and message IDs prevent resending old signed emails |
DKIM Limitations
DKIM verifies that the email was not tampered with and was signed by the claimed domain. However, it does not tell the receiving server what to do if verification fails. That is DMARC's job.
DMARC: Domain-based Message Authentication, Reporting, and Conformance
How DMARC Works
DMARC is the policy layer that ties SPF and DKIM together. It tells receiving servers:
- Alignment check: The domain in the visible "From" header must match the domain verified by SPF or DKIM. This closes the gap where SPF passes on one domain but the displayed sender is different.
- Policy enforcement: What to do when alignment fails.
- Reporting: Where to send reports about authentication failures.
DMARC Policies
| DMARC Policy | Action on Failure | Security Level |
|---|---|---|
| p=none | Monitor only, deliver anyway | None (reporting only) |
| p=quarantine | Send to spam folder | Moderate |
| p=reject | Block the email entirely | Strong (recommended) |
Why DMARC Matters
Without DMARC, an attacker can register their own domain, set up proper SPF and DKIM for it, but set the visible "From" address to ceo@your-company.com. The email passes SPF and DKIM for the attacker's domain, but the recipient sees your company's name. DMARC's alignment requirement catches this because the "From" domain (your-company.com) does not match the authenticated domain (attacker-domain.com).
Microsoft's 2026 Research: Where Authentication Breaks Down
Microsoft published research in January 2026 identifying specific scenarios where email authentication fails to protect recipients:
Complex Routing Chains
When email passes through multiple servers (forwarding services, mailing lists, security gateways), SPF can break because the final sending server is not the original sender's server. DKIM signatures can also break if any intermediate server modifies the email headers or body.
| Routing Scenario | SPF Impact | DKIM Impact | DMARC Impact |
|---|---|---|---|
| Direct delivery | Works correctly | Works correctly | Works correctly |
| Email forwarding | Breaks (new server IP) | Usually survives | May fail alignment |
| Mailing list | Breaks | Often breaks (headers modified) | Fails |
| Security gateway | Breaks | May break (content scanning) | May fail |
Misconfigured Authentication
Microsoft found that many organizations have authentication records that create a false sense of security:
- SPF with ?all or ~all: These permissive settings mean SPF failure does not result in blocking. Attackers routinely send spoofed emails that softfail but still arrive in the inbox.
- DKIM without DMARC: DKIM signature verification alone does not tell the server what to do on failure. Without DMARC, a failed DKIM check may be ignored.
- DMARC with p=none: This monitoring-only policy means no emails are blocked regardless of authentication results. It provides visibility but zero protection.
The Exploitation Pattern
Attackers specifically target organizations with weak authentication configurations. They check a domain's SPF, DKIM, and DMARC records before launching a spoofing campaign. If the records are permissive, the attack proceeds. If the records are strict, the attacker moves to a different technique (lookalike domains, compromised accounts).
How to Check Email Authentication Yourself
Method 1: Forward to ScamVerify
The simplest approach. Forward the suspicious email to scan@scamverify.ai. ScamVerify reads the raw email headers, checks SPF, DKIM, and DMARC results, and includes the findings in the risk assessment reply. This is especially useful because ScamVerify also cross-references the results against 8 million+ threat records, providing context that raw authentication results alone cannot offer.
Method 2: View Email Headers
In most email clients, you can view the full email headers:
| Email Client | How to Access Headers |
|---|---|
| Gmail | Open email, click three dots, "Show original" |
| Outlook | Open email, File menu, Properties, "Internet Headers" |
| Apple Mail | View menu, Message, "All Headers" |
| Yahoo Mail | Open email, click three dots, "View raw message" |
In the headers, look for these lines:
Authentication-Results:shows the SPF, DKIM, and DMARC verdict from your email providerReceived-SPF:shows the SPF check resultDKIM-Signature:shows the DKIM signing domain
A healthy result looks like:
spf=pass dkim=pass dmarc=pass
Any "fail" or "softfail" warrants further investigation.
For a detailed walkthrough of reading email headers, see our guide on how to read email headers to detect spoofing.
Method 3: Check Domain Records Directly
You can look up any domain's SPF, DKIM, and DMARC records using free DNS lookup tools (MXToolbox, dmarcian, or command-line dig commands). This tells you the domain's configuration but not whether a specific email passed or failed.
What to Do With the Results
| Result | What It Means | Recommended Action |
|---|---|---|
| All three pass | Email was sent by an authorized server and was not modified | Still verify the content. Compromised accounts pass authentication. |
| SPF fails, DKIM passes | Email may have been forwarded or sent through an unexpected server | Check whether forwarding explains it. If not, treat as suspicious. |
| DKIM fails | Email content was modified after sending, or was never properly signed | Treat as highly suspicious. Forward to scan@scamverify.ai for analysis. |
| DMARC fails | The visible sender domain does not match the authenticated domain | Almost certainly spoofed. Do not trust the email. |
| All three fail | No authentication passed | Very likely malicious. Delete without interacting. |
Important caveat: Passing all three checks does not guarantee the email is safe. If an attacker compromises a legitimate email account, the emails they send from that account will pass SPF, DKIM, and DMARC because the account is authorized. This is why ScamVerify's analysis goes beyond authentication to check content, links, and sender reputation against threat intelligence databases.
ScamVerify's Authentication Analysis
When you forward an email to scan@scamverify.ai or use the email checker, ScamVerify performs a comprehensive authentication analysis:
- Extracts SPF, DKIM, and DMARC results from the email headers
- Checks the sending domain's configuration for known weak settings (softfail, p=none)
- Cross-references the sender against 684,045 FTC impersonation complaints
- Analyzes all links against 74,032 URLhaus malicious domains
- Evaluates content patterns against known phishing templates
- Synthesizes everything into a plain-English risk assessment
The authentication check is one layer of a multi-layer analysis. A suspicious email with perfect authentication still gets flagged if the links, content, or sender patterns match known threats.
Check a suspicious email
Paste email content below, or forward it to scan@scamverify.ai for instant analysis.
FAQ
If an email passes SPF, DKIM, and DMARC, is it definitely safe?
No. Authentication verifies that the email was sent by an authorized server for the claimed domain. It does not verify that the account holder is who they say they are, or that the email content is benign. A compromised email account sends emails that pass all three checks. A legitimate DocuSign account abused by an attacker sends authenticated emails. Always evaluate the content and context regardless of authentication results.
My company has DMARC set to p=none. Is that a problem?
Yes. DMARC with p=none means your domain's email authentication is in monitoring mode only. Emails that fail SPF and DKIM alignment are still delivered. This gives you visibility into who is sending email as your domain, but provides zero protection against spoofing. Upgrade to p=quarantine (sends failures to spam) or ideally p=reject (blocks failures entirely) once you have verified that your legitimate email sources are properly authenticated.
Can I set up SPF, DKIM, and DMARC for my personal email?
If you use a custom domain for email, yes. Your domain registrar or email hosting provider will have instructions for configuring these DNS records. If you use a free email provider (Gmail, Outlook, Yahoo), these are already configured by the provider. You benefit from their authentication when receiving emails but cannot change their settings.
Why does my forwarded email sometimes show SPF failure?
When you forward an email, the forwarding process changes the sending server. The recipient's mail server sees your email server's IP address, not the original sender's. Since your server is not on the original sender's SPF record, SPF fails. This is a known limitation of SPF with email forwarding. DKIM usually survives forwarding (the signature is on the content, not the server), and ARC (Authenticated Received Chain) was designed to preserve authentication across forwards.
How does ScamVerify check authentication when I forward an email?
When you forward to scan@scamverify.ai, ScamVerify reads the original authentication results preserved in the email headers. Even though the forward itself changes the delivery path, the original SPF, DKIM, and DMARC results from the recipient's first mail server are recorded in the Authentication-Results header. ScamVerify extracts these original results along with the DKIM signature on the forwarded content.
Not sure if an email is legitimate? Forward it to scan@scamverify.ai for a complete authentication and threat analysis, or paste it at the ScamVerify email checker.
